[BUG] Non-motorized wheels of fetch are 'fused' with base_link.dae

[alters-mit]

Describe the bug The four non-motorized wheels of fetch are part of base_link.dae and aren't included in the URDF description as separate objects. base_link_collision.STL doesn't include these wheels, meaning that they don't exist at all in a physics simulation.

To Reproduce

• Open base_link.dae in Blender to see that the wheels are attached to the base link cylinder.
• Import fetch.urdf into Unity using the URDF importer. This bug probably appears in ROS as well.

Expected behavior The four non-motorized wheels are imported as separate objects, have separate colliders, and are set up as free-moving joints.

Screenshots

[mikeferguson]

If you take a little closer look at the URDF, that is only the "visualization" mesh - the "collision" mesh is even more simplified (there are no casters, the bottom is just flat with a big rounded edge all the way around. In Gazebo, this base is given a low friction coefficient and then the drive wheels just stick out the bottom (at least when I originally created the simulation, modeling all the casters would have made the simulation fail to run in realtime on a modest computer).

[alters-mit]

In Gazebo, this base is given a low friction coefficient and then the drive wheels just stick out the bottom

In that case, what prevents the robot from tipping over in Gazebo if the wheels essentially don't exist?

[mikeferguson]

In that case, what prevents the robot from tipping over in Gazebo if the wheels essentially don't exist?

The entire base, except the rounded edge, is touching the ground (I like to visualize this as "a friction-less bathtub with wheels") - you can visualize it here on github: https://github.com/fetchrobotics/fetch_ros/blob/melodic-devel/fetch_description/meshes/base_link_collision.STL

[alters-mit]

Got it. Thanks!