When ROSifying a real robot, how accurate has the URDF to be?

asked 2020-07-16 22:26:44 -0500

kidargueta
23 ●4 ●7 ●12

I have read this question https://answers.ros.org/question/2700... and other articles and I have a decent idea about how to go about ROSifyign my robot. I am about to start the process of creating the URDF, I have taken some tutorials and have a basic understanding of what to do. The question now is, in order to take full advantage of ROS with the real robot, how accurate this URDF model should be? More specifically, is it a must to use meshes and shapes that are exactly like the real robot? How accurate the pose of elements (base, joints, sensors), inertias, and other values have to be? Can it be similar but not exact or should I go and carefully measure every piece of my robot to have the most precise values within the URDF? I ask because I essentially got a bunch of parts and components from MakeBlock and I am building my own robot with my own design and specs. This is not a hobby or toy project, I am practicing to implement a serious commercial project and I need to make full use of ROS capabilities (ROS Control, Navigation, etc).

Thanks,

edit retag flag offensive close merge delete

add a comment

answered 2020-07-17 10:10:19 -0500

achille
464 ●13 ●34 ●25 http://achille.fyi

While we can give you guidance, this question is really something for you to answer yourself. This strongly depends on what kind of robot you have and what you're trying to make it do. 'serious commercial project' isn't very helpful here. There are plenty of commercial robots that have varying levels of accuracy on the URDF depending on their type and purpose.

A URDF is typically used for visualization, collision detection and avoidance, and ROS control. For visualization, it doesn't have to be all that accurate in most cases. For collision detection, it strongly depends on your application. Can you afford to have the pose be off by a few centimeter? Typically companies will just start off with the poses through the CAD model (e.g. solidworks converter) and then possibly improve it through calibration, which may be manual adjustment. Similar with the level of detail. Do you need all nuts and bolts and holes modeled in your URDF? Probably not, as it makes it slower to do collision detection and to visualize. URDF also allows you to specify collision shapes/meshes which are typically conservative and convex shapes larger than the actual links so that any errors are offset. For ROS control, it helps to think about the extreme case: if my URDF is off by some large value, then how does that affect control? If it's joint control, it doesn't matter, but if you're trying to control the end-effector or a mobile base and it's off by a lot, it'll make odometry less accurate.

edit flag offensive delete link

Comments

Thanks a lot @achille for your fantastic and prompt answer. Sorry I was unable to follow up earlier. I agree that the question is not specific enough, I just wasn't so sure how to properly ask it.

To be more specific, I am prototyping a Robot Vending Machine. Think of it as a standard vending machine (snacks or drinks) on wheels. I am currently working on the mobile base. The robot is to be used outdoors in parks or sidewalks in neighborhoods. It should navigate autonomously in predefined areas, for instance, the roads of a park or particular sidewalks of a neighborhood. Everything is predefined to reduce complexity, the robot should never exit the areas it has been trained to recognize and navigate. As it moves, it should avoid unexpected obstacles and pedestrians. I am imagining then that the URDF should be precise enough to have accurate levels of ...(more)

kidargueta ( 2020-07-18 22:33:32 -0500 )edit

If by collision detection you mean collision for 2D navigation, the URDF doesn't matter much. This term is typically reserved for motion planning for manipulators. If you'll be using ROS control (which is optional), the URDF can be used to know how far the wheels are from the center etc which determines angular velocities sent to the wheels and read velocities converted to robot velocities. If your URDF specifies the locations of your wheels wrong, say off by 3cm, then for a differential drive the angular velocity of the robot is going to be off by a factor of that. That will affect odometry and will make it so that your localization solution will have to 'work harder' to correct the erroneous readings. If the error is small, then localization will correct the estimate just fine and there will be little to no effect on navigation. On the ...(more)

achille ( 2020-07-19 16:18:20 -0500 )edit

You'll typically use a lidar or depth sensor to sense the environment, and that also affects collision avoidance. If you're navigating tight spaces, then an offset of a few centimeter on that sensor compared to where it actually is might cause the robot to bump into an obstacle. It will also make localization harder, since now your odometry isn't agreeing with the correction that your sensor is providing (given you're using the same sensor to do planning and localization). For your case, I'd say you don't need that high a level of accuracy. If it's easy to get to sub centimeter accuracy, then that's obviously better, but if you care about not hitting things by a wide margin and there's plenty of space to navigate around, you'll end up inflating your obstacles more. As a final recommendation, put a bumper ...(more)

achille ( 2020-07-19 16:25:14 -0500 )edit

Fantastic answer and your blog post about the Mars rover is pure gold. I am understanding everything much better now. Just one doubt from your answer, you said ROS control is optional, what are the alternatives? Thanks!

kidargueta ( 2020-07-20 08:58:10 -0500 )edit

Glad you like it! ROS control's intention is to standardize control interfaces and provides some out-of-the-box controllers for common setups. To (over)simplify it, it maps trajectories (for robot arms) or Twist commands (mobile bases) to low-level control outputs and vice versa (including odometry for mobile bases) for most types of robots. If it's already set up for some mobile base you're using or if you have a clear idea how to use it, go for it, but for those new to ROS my personal opinion is that it is hard to understand and set up and the modularity and extensibility also makes it a bit bloated.

achille ( 2020-07-20 09:06:16 -0500 )edit

So an alternative for beginners would be something like this: https://thenextweb.com/syndication/20... ?

kidargueta ( 2020-07-20 22:09:30 -0500 )edit

I'd say that's overcomplicating things. All you need is a way to convert a Twist message to wheel angular velocities and vice versa. That mapping depends on the robot. I would look at how it's done for the turtlebot (if you're proficient in c++) or for ackermann steering with the Mars Rover.

achille ( 2020-07-20 23:00:53 -0500 )edit

C++ is ok. But it means I will have to do PID and all those other things by myself I guess.

kidargueta ( 2020-07-22 08:15:49 -0500 )edit

add a comment

When ROSifying a real robot, how accurate has the URDF to be?

1 Answer

Comments

Question Tools

Stats

Related questions

When ROSifying a real robot, how accurate has the URDF to be? edit

1 Answer

Comments

Question Tools

Stats

Related questions

When ROSifying a real robot, how accurate has the URDF to be?