Implement proper tracked motion model

[peci1]

This PR fixes issue #365 . It adds proper support for tracked motion to Absolem and MARV robots (it could be extended to other tracked robots, too).

Depends on gazebo-forks/dart#22, gazebosim/gz-physics#267 and gazebosim/gz-sim#869.

[peci1]

Videos of the implementation (they only work in Chrome, I don't know why).

ign-tracked1.mp4.mp4

ign-tracked2.mp4.mp4

ign-tracked3.mp4.mp4

ign-tracked4.mp4.mp4

[peci1]

All the required upstream releases have been finished. I'll have a look at updating this PR next week.

Should I also give a try at updating other teams' tracked robots? (at least CSIRO DTR and HD2 robots off the top of my head).

[peci1]

Is master the correct target branch for this PR?

[azeey]

Is master the correct target branch for this PR?

Yes, that's the correct branch.

[peci1]

I think this PR is ready to be reviewed.

Do not get confused by moving the <enable_orientation>0</enable_orientation> tag of IMU to the end of the <imu> tag - that's just to synchronize the SDFs to the output generated by ign sdf.

[peci1]

To test this PR:

ign launch src/subt/submitted_models/ctu_cras_norlab_absolem_sensor_config_1/launch/example.ign robotName:=X1 ros:=true

# in another console:

# raise the front flippers
rostopic pub -1 /X1/flippers_cmd_pos/front_right std_msgs/Float64 "data: -0.5" &
rostopic pub -1 /X1/flippers_cmd_pos/front_left std_msgs/Float64 "data: -0.5" &

# drive forward over the pallet
rostopic pub -1 /X1/cmd_vel geometry_msgs/Twist "linear:
  x: 0.5
  y: 0.0
  z: 0.0
angular:
  x: 0.0
  y: 0.0
  z: 0.0"

# or you can test using a gamepad (deadman + D-pad for flippers)

# see how smoothly the robot climbs up the pallet (no bumping or getting stuck caused by fake wheels)

[azeey]

I tested both Absolum and MARV robots on the create. Absolum was able to climb over it without anye issues, but MARV got stuck with half of the robot on the crate and half on the ground. Is that expected?

I also noticed that the battery doesn't start draining when either of the robots are commanded to move. Currently only the LinearBattery system monitors the JointVelocityCmd and JointForceCmd components to detect when the battery should start draining. https://github.com/ignitionrobotics/ign-gazebo/blob/acac5b50f75f672d9a335471966cd3681ce7926c/src/systems/battery_plugin/LinearBatteryPlugin.cc#L399. Since the TrackedVehicle system doesn't make use of these components, LinearBattery is unable to start draining the battery. One thought is to create a component that gets attached to a model and triggers LinearBattery to drain. This would in addition to the current trigger components LinearBattery monitors. Then TrackedVehicle can attach this component on the model when it receives a motion command.

[peci1]

If MARV got stuck with its belly, it's expected. This happens also with the real robot. You need to help the robot with rear flippers to climb up the pallet. (I was suggesting a belly belt when designing the robot, but it was considered too silly :) ).

[peci1]

Regarding the battery plugin and new gazebo component - what about adding component BatteryDrainControl which would be the alternative way of enabling / disabling battery discharge? This would also require changing the LinearBatteryPlugin.

Another alternative (or just a temporary solution until next gazebo release) is copy-pasting the LinearBatteryPlugin in subt repo and adjusting it to cooperate with the tracked vehicle plugin.

Yet another alternative - the battery plugin could get a list of topics to subscribe to and it could start draining as soon as any message is received on any of these topics. In this particular case, it should receive the list of cmd_vel topics of the track controllers (4 topics on MARV, 6 topics on Absolem).

Last, the battery plugin could check pose of the model and start draining when it moves more than a specified amount (this should account for the initial little falls models can do when they are inserted into the simulation).

[peci1]

Or maybe the best option would be adding start_draining/stop_draining topics or services to the battery plugin?

[peci1]

What about this hotfix for the battery issue, which could be upstreamed? peci1#2

[azeey]

I like the idea of the battery plugin monitoring a list of topics. We'll need to make it message type agnostic though. I'm okay with the hotfix for expediency. @nkoenig can you confirm?

[peci1]

I've changed the battery draining topics to generic raw subscription. You can track and comment changes related to the battery hotfix in peci1#2 .

[peci1]

I've started implementing the better track model also for other robots: peci1#3

[nkoenig]

Here is a PR that adds topic support to the battery plugin in gazebo: gazebosim/gz-sim#1255.

[peci1]

I've updated this PR and peci1#3 to integrate with gazebosim/gz-sim#1255 . So the battery drain should be fixed now for all the tracked vehicles.

[azeey]

Works great! Thanks for your patience @peci1.

[peci1]

Thanks! I've submitted peci1#3 as #1048 .

[peci1]

@azeey Can I ask for upload of these models to Fuel?

[nkoenig]

Sure thing @peci1. I'll start looking into an update tomorrow.

[nkoenig]

The models on Fuel have been updated.

[peci1]

Thanks for the upload, @nkoenig , and for merging #1048, @azeey ! Would you please also find time for looking at #1047 and #1045?