Model Submission for CTU-CRAS-NORLAB Lily hexapod robot, sensor configs 1 and 2

[xpetresx]

This is our planned sensory payload configuration for the Lily hexapod walking robot.

• The base platform is the HEBI robotics Lily hexapod kit
• The sensory bundle comprises
  • Ouster OS0-128 Lidar
  • An omnivision setup of 5 Basler Ace2 (a2A1920-51gcPRO) cameras with C125-0418-5M-P Basler Lens
  • Xsens MTi-30 AHRS
  • LED spotlights pointing in the same direction as the cameras
• The model includes the default SubT gas sensor
• Weight: Approx. 33 kg
• Sensor config 2 carries 6 comms breadcrumbs in addition to the above.

[peci1]

I downgraded model.sdf to SDF version 1.6 as requested for all our models.

[acschang]

The initial assessment of the the model is complete however there are some issues to resolve before this model can be merged and utilized in a competitive setting:

• Please confirm the robot mass and make sure the mass in specifications.md and model.sdf agree.
• Please add intrinsic values for all camera sensors.
• Please update the Ouster range resolution and stddev values to match the standard in the SubT repository (0.01 for both).
• Please update the endurance to meet the value specified in the specifications.md. This can be done by adjusting the power_load parameter in common.rb to 9.9 as opposed to 4.95.
• Please provide validation data as it is necessary to complete the evaluation. If not provided, the model's maximum velocity will be limited to 1m/s and battery life set to 60min. When the model validation data can be provided later, please submit a PR updating the model.

Please address the issues noted above in this pull request. Once the above issues are fixed, your submission will move onto the next review stage!

[caguero]

Minor detail but this is how I see Lily in simulation. Should the body have any texture or is it supposed to look solid black like it's shown in the next picture?

[caguero]

I confirm that I can control the robot in velocity and visualize all sensor information. I got a few transformation errors when loading the robot model in RViz and using X1 as the reference frame.

[peci1]

The missing TFs are from URDF links without inertia which do not get converted to SDF. It could be resolved by running a robot state publisher which would publish just the static transforms, as was done in Absolem before 1ae9358 . I think the state publisher was removed because it was creating topic /nonexistent, which is where I diverted /tf from the state publisher so that it only publishes the static transforms. I know this isn't ideal, but publishing also the dynamic tfs could make mess in the TF system, as Ignition Gazebo is publishing them, too. With static transforms, this is not such a problem - at maximum, some static TFs would be published twice, but they should be exactly the same (although one comes from URDF/robot_state_publisher and the other comes from SDF/ros_ign_bridge). I offered a fix adding the robot_state_publisher back to Absolem in #543, but nobody has picked it up for 7 months, so I still don't know if this robot_state_publisher-based solution is valid for SubT or not.

[caguero]

The missing TFs are from URDF links without inertia which do not get converted to SDF.
[...]

Thanks for the explanation. Out of curiosity, why not adding the inertia to these links?

[peci1]

I think that these links are more "frames" than "links", i.e. denoting endpoints of feet (or endpoints of flippers on Absolem). We could probably add some inertia to these links, but it would have to be the "infinitesimal" intertia of e.g. 5 grams or so (it can't be too small to not risk NaNs from physics).

[caguero]

I think that these links are more "frames" than "links", i.e. denoting endpoints of feet (or endpoints of flippers on Absolem). We could probably add some inertia to these links, but it would have to be the "infinitesimal" intertia of e.g. 5 grams or so (it can't be too small to not risk NaNs from physics).

👍 Nothing required to do on that end from my side.

[peci1]

+1 Nothing required to do on that end from my side.

And is it okay to add the robot_state_publisher to fix these transforms? It can actually be useful to have them. On the other hand, the robot_state_publisher can be added in the solution container by the participants as well (this is what we do now with Absolem). So the question is whether it is desired to have the transforms ok "by default" (handled by bridge) or "when needed" (handled by solution container).

[caguero]

+1 Nothing required to do on that end from my side.

And is it okay to add the robot_state_publisher to fix these transforms? It can actually be useful to have them. On the other hand, the robot_state_publisher can be added in the solution container by the participants as well (this is what we do now with Absolem). So the question is whether it is desired to have the transforms ok "by default" (handled by bridge) or "when needed" (handled by solution container).

It's OK, feel free to add the robot_state_publisher if you want to.

[peci1]

Minor detail but this is how I see Lily in simulation. Should the body have any texture or is it supposed to look solid black like it's shown in the next picture?

Yes, solid black is correct.

[peci1]

I resolved all of the mentioned issues:

• Please confirm the robot mass and make sure the mass in specifications.md and model.sdf agree.
  • Mass in SDF is not 32.7 kg. I needed to adjust the foot friction parameters a bit. It's not yet fully fine-tuned, we might come with better values shortly.
• Please add intrinsic values for all camera sensors.
• Please update the Ouster range resolution and stddev values to match the standard in the SubT repository (0.01 for both).
• Please update the endurance to meet the value specified in the specifications.md. This can be done by adjusting the power_load parameter in common.rb to 7.92 as opposed to 4.95.
  • As we can't make the validation data now, I've set 9.9 to correspond to 60 minutes.
• Please provide validation data as it is necessary to complete the evaluation. If not provided, the model's maximum velocity will be limited to 1m/s and battery life set to 60min. When the model validation data can be provided later, please submit a PR updating the model.

I also added the robot_state_publisher. TFs look okay now in rviz.

[peci1]

@xpetresx please, have a look at the foot friction parameters

[caguero]

I also added the robot_state_publisher. TFs look okay now in rviz.

Confirmed that it looks good on RViz on my side now.

[caguero]

Just one more thing: When I run your robot following the example included in your documentation, the controller controls the robot (and I can move it with the velocity control interface).

LC_ALL=C ign launch -v 4 ~/subt_ws/src/subt/submitted_models/ctu_cras_norlab_lily_sensor_config_1/launch/example.ign robotName:=X1

However, when I run it following our model submission guide it loads but the controller doesn't seem to run because the legs are not moving at all:

ign launch -v 1 competition.ign worldName:=finals_practice_01 circuit:=finals robotName1:=X1 robotConfig1:=CTU_CRAS_NORLAB_ABSOLEM_SENSOR_CONFIG_1 localModel:=true

I wonder if there's something else you need to add to your spawner.rb file.

[peci1]

when I run it following our model submission guide

That's by design. In specifications.md we state:

To be able to control this robot model using velocity commands you need an additional package. Please clone the repository ctu_cras_norlab_hexapod_controller and follow the instructions specified in its README.

There is no way to launch this package from the bridge container as it won't contain the dependency package. So it is responsibility of the users to launch the support package in their solution containers. The example.ign is just a testing and prototyping convenience, so we added the support package there as the developer can usually add the package in the development environment.

[peci1]

It's the same design Anymal uses.

[caguero]

when I run it following our model submission guide

That's by design. In specifications.md we state:

To be able to control this robot model using velocity commands you need an additional package. Please clone the repository ctu_cras_norlab_hexapod_controller and follow the instructions specified in its README.

There is no way to launch this package from the bridge container as it won't contain the dependency package. So it is responsibility of the users to launch the support package in their solution containers. The example.ign is just a testing and prototyping convenience, so we added the support package there as the developer can usually add the package in the development environment.

Thanks for the clarification!

[caguero]

It looks good to me from a functional point of view.

[peci1]

Thanks for the review. Could you please still wait a bit for better PID regulator gains so that the robot is not so jumpy?

[caguero]

Sure, are you planning to commit validation data in this PR?

[peci1]

Unfortunately not, the robot has still been manufactured. We should receive it in May.

[caguero]

Unfortunately not, the robot has still been manufactured. We should receive it in May.

Please. let us know when you're happy with the code and we'll merge it, then.

[nkoenig]

Can you remove the use of ROS from your plugins?

[peci1]

Can you remove the use of ROS from your plugins?

I don't understand the question. There is just one plugin - logical-contact-system, and it doesn't use ROS. The other two CPP files are just ROS-Ign bridges.

[nkoenig]

Can you remove the use of ROS from your plugins?

I don't understand the question. There is just one plugin - logical-contact-system, and it doesn't use ROS. The other two CPP files are just ROS-Ign bridges.

That's my mistake. Thanks for the clarification.

[nkoenig]

SIZE[1.78814 1.82685 0.368861]