Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 11 commits into from
Apr 19, 2021

Conversation

xpetresx
Copy link
Contributor

@xpetresx xpetresx commented Apr 1, 2021

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.

petr added 2 commits April 1, 2021 03:51

Verified

This commit was signed with the committer’s verified signature.
@peci1
Copy link
Collaborator

peci1 commented Apr 5, 2021

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

@acschang
Copy link
Contributor

acschang commented Apr 7, 2021

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!

Sorry, something went wrong.

@caguero
Copy link
Contributor

caguero commented Apr 8, 2021

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?

lily

@caguero
Copy link
Contributor

caguero commented Apr 8, 2021

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.

lily_rviz

@peci1
Copy link
Collaborator

peci1 commented Apr 8, 2021

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
Copy link
Contributor

caguero commented Apr 8, 2021

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
Copy link
Collaborator

peci1 commented Apr 8, 2021

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
Copy link
Contributor

caguero commented Apr 8, 2021

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
Copy link
Collaborator

peci1 commented Apr 8, 2021

+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
Copy link
Contributor

caguero commented Apr 8, 2021

+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
Copy link
Collaborator

peci1 commented Apr 10, 2021

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
Copy link
Collaborator

peci1 commented Apr 10, 2021

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.

Sorry, something went wrong.

@peci1
Copy link
Collaborator

peci1 commented Apr 10, 2021

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

@caguero
Copy link
Contributor

caguero commented Apr 12, 2021

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
Copy link
Contributor

caguero commented Apr 12, 2021

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
Copy link
Collaborator

peci1 commented Apr 12, 2021

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
Copy link
Collaborator

peci1 commented Apr 12, 2021

It's the same design Anymal uses.

@caguero
Copy link
Contributor

caguero commented Apr 12, 2021

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!

Copy link
Contributor

@caguero caguero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@peci1
Copy link
Collaborator

peci1 commented Apr 12, 2021

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
Copy link
Contributor

caguero commented Apr 12, 2021

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

@peci1
Copy link
Collaborator

peci1 commented Apr 12, 2021

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

@caguero
Copy link
Contributor

caguero commented Apr 12, 2021

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
Copy link
Contributor

nkoenig commented Apr 13, 2021

Can you remove the use of ROS from your plugins?

@peci1
Copy link
Collaborator

peci1 commented Apr 13, 2021

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
Copy link
Contributor

nkoenig commented Apr 19, 2021

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 nkoenig merged commit 94abceb into osrf:master Apr 19, 2021
@nkoenig
Copy link
Contributor

nkoenig commented Apr 19, 2021

SIZE[1.78814 1.82685 0.368861]

nkoenig added a commit that referenced this pull request May 18, 2021
…Norlab (#860)

* Absolem: Added sensor configs 6, 7 and 8.

* remove ros from the x500 plugin (#891)

Signed-off-by: Nate Koenig <nate@openrobotics.org>

Co-authored-by: Nate Koenig <nate@openrobotics.org>

* Model Submission for Emesent Hovermap (#892)

* Model submission for Hovermap sensor config 1 from Emesent

Signed-off-by: Rowan Ramamurthy <rowan.ramamurthy@emesent.io>

* updated specifications for the Emesent Hovermap

Signed-off-by: Rowan Ramamurthy <rowan.ramamurthy@emesent.io>

* Updated gimbal controller - fixed issue with battery usage

Signed-off-by: Rowan Ramamurthy <rowan.ramamurthy@emesent.io>

* Specifications updated for emesent hovermap sensor config 1

Signed-off-by: Rowan Ramamurthy <rowan.ramamurthy@emesent.io>

* Update specifications.md

Signed-off-by: Rowan Ramamurthy <rowan.ramamurthy@emesent.io>

* Update submitted_models/emesent_hovermap_sensor_config_1/CMakeLists.txt

Co-authored-by: Nate Koenig <nkoenig@users.noreply.github.com>

* Added details in the model.config

* Updated the min and max angle for the gpu lidar for the hovermap

* Updating min range and resolution for lidar

* Removing visualisation for lidar

* Added the number of horizontal samples for the gpu to 900

* Updated camera resolution, and also updated the weight in the specifications file to match the sdf values

* Updated noise parameters for the gimbal stabilising imu

* Added /sensor prefix to magnetometer output

* Added sensor prefixes for other sensor outputs

* Updated the imu with the new noise model

* Adding imu topic and specifications as per validation data

* Update submitted_models/emesent_hovermap_sensor_config_1/launch/spawner.rb

Co-authored-by: Nate Koenig <nkoenig@users.noreply.github.com>

* Renamed node with repeated name

* Updating the battery plugin to support a 21.6min flight time

* Updated specifications.md to align with provided validation data and spawner.rb accelerations.

* Adjusted limits on gimbals to align with observed behavior in validation data.

Co-authored-by: Rowan Ramamurthy <rowan.ramamurthy@emesent.io>
Co-authored-by: Peter <PeterQFR@users.noreply.github.com>
Co-authored-by: Nate Koenig <nkoenig@users.noreply.github.com>
Co-authored-by: Peter Milani <peter@emesent.io>

* Model Submission for CTU-CRAS-NORLAB MARV (#886)

* Added CTU_CRAS_NORLAB_MARV_SENSOR_CONFIG_1 (and other sensor configs).

* MARV: prefix links in URDF with robot name.

* MARV: Update RViz config.

* Removed debug prints

* MARV: Added mapping server relay.

* MARV: Downgraded model.sdf to SDF 1.6.

* MARV: Fixed IMU topic.

* MARV: Fixed cliff sensors ROS bridge.

* MARV: Fixed odom rate.

* MARV: Fixed flickering of lights.

* MARV: Update IMU parameters.

* MARV: Added camera intrinsics.

* MARV: Fixed lower bound of temperature for Boson camera.

* MARV: Changed Ouster precision and stddev to 0.01 to follow other SubT sensors.

* Added experimental validation of camera FoV to the specifications.

* Reduced battery life to 60 minutes until validation is complete.  The current maximum velocity and acceleration are set to the default limits for models without validation data.

* Added endurance adjustment to the specifications.md file.

Co-authored-by: Martin Pecka <peckama2@fel.cvut.cz>

* Model submission for BOSDYN_SPOT and two sensor configs of CTU-CRAS-Norlab (#841)

* Spot: First version, has actuators, but no control.

* Spot walking.

* Spot: improved modularity and made CCN_SPOT_SC1 compatible with BOSDYN_SPOT again.

The interface between BOSDYN_SPOT and sensor configs can be considered more or less stable now.

* Spot: Added cameras.

* Spot: Fixed a bug in handling leg collisions.

* Spot: specifications.md

* Spot: Fixed xacro utils to be compatible with MARV.

* Spot: Mono camera now also relays set_rate requests.

* Spot: Fixed IMU bridge.

* Spot: Added payload to CCN_SPOT_SC1.

* CCN_SPOT_SC1: Removed the total_mass_* helper link from URDF to avoid RViz displaying an error.

* Spot: Added CTU_CRAS_NORLAB_SPOT_SENSOR_CONFIG_2.

* CCN_SPOT_SC1: Added specifications.md.

* Spot: Added thumbnails.

* CCN_SPOT_SC1: Added thumbnails.

* Spot: Added mapping server bridge.

* Spot: Downgraded model.sdf to SDF 1.6.

* Spot: update IMU params.

* Spot: Add camera intrinsics.

Body depth camera is still just estimated.

* Spot: Fixed specifications.md part about contact system.

* Spot: Fixed mass by adding battery and tuned the PIDs a bit.

* Spot: Battery life set to 60 minutes.

* CCN_SPOT: Changed Ouster resolution and stddev to 0.01.

* Spot: removed unintentional change.

Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>

* Spot: Improvements of specifications.md.

* Spot: Adjusted battery life to 60 minutes.

* Spot: Resolved relative references to Fuel parts.

* added feedforward to bridge, controller msgs are now printed only once (#895)

* Set the state properly when recording is complete (#894)

Signed-off-by: Nate Koenig <nate@openrobotics.org>

Co-authored-by: Nate Koenig <nate@openrobotics.org>

* Absolem: Remove debug visuals [SDF 1.6] (#878)

* Absolem: Sync Xacro: Change IMU and friction parameters in Xacro to correspond to the desired values in SDF.

* Absolem: Sync Xacro: Re-generate model.sdf using libsdformat 8.9.1 .

This commit makes no real change to the geometry of the model, it just represents some numbers and rotations differently.

* Absolem: Removed empty link visuals as they obstructed the omnicam and were not good for anything else.

* Add missing robot platform types (#890)

* Add missing robot platform types

Signed-off-by: Nate Koenig <nate@openrobotics.org>

* Added hovermap and marv

Signed-off-by: Nate Koenig <nate@openrobotics.org>

* Added spot and fix dependency

Signed-off-by: Nate Koenig <nate@openrobotics.org>

Co-authored-by: Nate Koenig <nate@openrobotics.org>

* Fix CMakeLists (#897)

* Model Submission for CTU-CRAS-NORLAB Lily hexapod robot, sensor configs 1 and 2 (#867)

* added ctu_cras_norlab_lily ign simulation models

* changed thumbnails

* Fixed links in specifications.md .

* Downgraded model.sdf to SDF 1.6.

* Lily: Corrected mass.

* Lily: Added camera intrinsics.

* Lily: Changed ouster resolution and stddev to 0.01.

* Lily: Changed battery endurance to 60 minutes.

* Lily: Added robot_state_publisher to fill in missing static TFs.

* Lily: Edited Basler cam FOV to match in all places and correspond to intrinsics.

Co-authored-by: petr <petr.cizek@fel.cvut.cz>
Co-authored-by: Martin Pecka <peckama2@fel.cvut.cz>

* Spot: Disable nodelets because of spurious broken bonds. (#898)

* Model Submission for Coordinated Robotics' Crystal UAV Sensor Config 1 (#866)

* Coordinated Robotics Crystal UAV Sensor Config 1

* Updates based on reviews of other robots

* Camera precedent update, change colors to floats

* Adjust lighting to match camera change

* Update xacro

* Correct down lidar position, set top_scan to zero

Co-authored-by: Kevin <ak619@lafn.org>

* Model Submission for Coordinated Robotics Rocky Sensor Configs 1, 2 and 3 (#862)

* Coordinated Robotics Rocky

* Updates based on reviews of other robots

* Remove wheel slip plugin from Ackermann type steering vehicle

* Fixed camera name, changed color to floats

* Update cameras to match precedent

Co-authored-by: Kevin <ak619@lafn.org>

* Model Submission Coordinated Robotics Mike (#845)

* Add Coordinated Robotics Mike

* Updates based on reviews of other robots

* Add thermal camera to sensor list, fix wheel plugin wheel diameter, change to floating point colors, increase wheel joint speed

Co-authored-by: Kevin <ak619@lafn.org>

* Move battery plugin to the end of plugin list (#901)

Signed-off-by: Michael Carroll <michael@openrobotics.org>

* fixed pose of rs_up, rs_down rgbd cameras (#903)

* Update robot classes and marsupial pairs (#900)

* Adding lily to include

Signed-off-by: Nate Koenig <nate@openrobotics.org>

* Added CRYSTAL, MIKE, and ROCKY

Signed-off-by: Nate Koenig <nate@openrobotics.org>

* Added crystal as marsupial child

Signed-off-by: Nate Koenig <nate@openrobotics.org>

* Added new Coordinated marsupial pairs, adjusted Karen's collisions, and tweaked a few spawner z-offsets

Signed-off-by: Nate Koenig <nate@openrobotics.org>

* Remove debug statement

Signed-off-by: Nate Koenig <nate@openrobotics.org>

Co-authored-by: Nate Koenig <nate@openrobotics.org>

* Update to use the lattest fog emitter code (#896)

* Update to use the lastest fog emitter code

Signed-off-by: Nate Koenig <nate@openrobotics.org>

* Merged with master

Signed-off-by: Nate Koenig <nate@openrobotics.org>

* Adjust pose based on latest emitter model

Signed-off-by: Nate Koenig <nate@openrobotics.org>

Co-authored-by: Nate Koenig <nate@openrobotics.org>

* fixed fx, fy focal length of front camera to be consistent with hfov (#907)

* add set_rate service to X500 UAV (#906)

* added feedforward to bridge, controller msgs are now printed only once

* added set_rate services to laser, rgb, rgbd sensors

* dot_generator tweaks for tunnels (#884)

* Unified comms parameters across circuits.

Signed-off-by: Carlos Agüero <caguero@openrobotics.org>

* Absolem: Changed lidar and thermocam parameters, fixed RViz model.

* Absolem: Added Basler cameras intrinsics.

Co-authored-by: Nate Koenig <nkoenig@users.noreply.github.com>
Co-authored-by: Nate Koenig <nate@openrobotics.org>
Co-authored-by: acschang <61025344+acschang@users.noreply.github.com>
Co-authored-by: Rowan Ramamurthy <rowan.ramamurthy@emesent.io>
Co-authored-by: Peter <PeterQFR@users.noreply.github.com>
Co-authored-by: Peter Milani <peter@emesent.io>
Co-authored-by: Matej Petrlik <petrlmat@fel.cvut.cz>
Co-authored-by: Petr Cizek <cizekpet@gmail.com>
Co-authored-by: petr <petr.cizek@fel.cvut.cz>
Co-authored-by: knoedler <knoedler@dslextreme.com>
Co-authored-by: Kevin <ak619@lafn.org>
Co-authored-by: Michael Carroll <michael@openrobotics.org>
Co-authored-by: Carlos Agüero <caguero@osrfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants