Model submission for Absolem sensor configuration 1 by CTU-CRAS-Norlab

[peci1]

CTU_CRAS_NORLAB_ABSOLEM_SENSOR_CONFIG_2 only differs by breadcrumbs.

This is my first model submission here and I didn't have all the time I needed to fine-tune the simulation. But it should basically work. Later, I might try to add a positional controller for flippers and a better controller for the lidar rotation.

[peci1]

This model uses an opposite direction of model XML generation - there is the "source" Xacro, which can generate valid URDF and almost valid SDF (that one needs to be processed by scripts/update_robot_sdf).

Also, the 3D collision model differs a bit in RViz and in Gazebo - the RViz model is meant for laser filtering, so it contains big_collision_box, which is a box covering all stuff on top of the robot. Also, flippers are a bit inflated in RViz. The Gazebo model is 1:1 with the real robot.

[peci1]

I'm also not sure if I chose the best approach to model the flipper/laser controlled joints. If I looked correctly, there are no motors directly in iGazebo. Should I use ros_control to model the motors, or is the current approach with velocity controller enough? It seems the velocity controller respects joint stops, but doesn't respect velocity and effort limits set in <limit>.

In ODE/Gazebo, I model the flippers by directly setting the ODE joint's "vel" property, which activates a hidden joint motor. Is there anything similar in dartsim?

[caguero]

I'm also not sure if I chose the best approach to model the flipper/laser controlled joints. If I looked correctly, there are no motors directly in iGazebo. Should I use ros_control to model the motors, or is the current approach with velocity controller enough? It seems the velocity controller respects joint stops, but doesn't respect velocity and effort limits set in <limit>.

In ODE/Gazebo, I model the flippers by directly setting the ODE joint's "vel" property, which activates a hidden joint motor. Is there anything similar in dartsim?

Hi @peci1 , would you prefer to use position control or velocity control for the flippers?

[peci1]

The real robot offers both interfaces. We use much more often the positional control mode.

[caguero]

The real robot offers both interfaces. We use much more often the positional control mode.

Sound good, we can enable position control for the flippers then. Let me take a look...

[caguero]

I tested your submission and looks reasonable to me.

• I can control the robot in velocity.
• I can control the flippers in velocity.
• I was able to visualize sensor data in rviz.

I got this error on my side when launching with ign launch -v 4 cave_circuit.ign robotName1:=x1 robotConfig1:=CTU_CRAS_NORLAB_ABSOLEM_SENSOR_CONFIG_1 localModel:=true:

[ERROR] [1596490807.681635843]: Could not find parameter robot_description on parameter server

Do you see it on your end?

[caguero]

About controlling the flippers in position, you should be able to do it applying the following changes:

1. vehicle_topics.launch: In the ros_ign_bridge section associated with the flipper control replace .../cmd_vel with .../cmd_pos. E.g.:

<node
      pkg="ros_ign_bridge"
      type="parameter_bridge"
      name="ros_ign_bridge_front_left_flipper"
      args="/model/$(arg name)/joint/front_left_flipper_j/cmd_pos@std_msgs/Float64]ignition.msgs.Double">
      <remap from="/model/$(arg name)/joint/front_left_flipper_j/cmd_pos" to="flippers_cmd_pos/front_left"/>
    </node>

2. In your model.sdf, replace the JointController system with a JointPositionController system. E.g.:

<plugin filename="libignition-gazebo-joint-position-controller-system.so"
        name="ignition::gazebo::systems::JointPositionController">
      <joint_name>front_left_flipper_j</joint_name>
      <p_gain>30.0</p_gain>
      <i_gain>0.1</i_gain>
      <d_gain>0.01</d_gain>
      <i_max>10</i_max>
      <i_min>-10</i_min>
      <cmd_max>100</cmd_max>
      <cmd_min>-100</cmd_min>
    </plugin>

Note that you don't need the <use_force_commands> parameter anymore. I haven't tried this approach as it might need to tweak all the gains but it should work.

Also, I don't recommend to enable both interfaces (position and velocity) at the same time. Choose one, otherwise both controllers will fight each other.

[caguero]

I have an error finding the robot_description on the parameter server, otherwise a few minor comment in case you want to change the flipper control

[peci1]

Thanks for the comments.

The robot_description is something I wanted to look into. The problem is simple - I'm running a robot_state_publisher to get all the static TFs published into ROS, and it is launched too early - before description.launch finishes. If I could include description.launch into vehicle_topics.launch, roslaunch would wait for the parameter to be computed before launching any nodes. Is there any reason why I shouldn't include description.launch into vehicle_topics.launch or merge them into a single file?

About the positional control of the flippers - I've already tried the positional controller you suggested. But you can't limit the maximum speed the error correction uses to get to the setpoint. And modelling this speed more or less accurately is IMO important. I've played a bit with the PID parameters, but I always ended up either with a "dead" flipper or with a too quick or oscillating one. The robot's interface allows me to set a limit on effort, set the positional setpoint and choose the velocity that should be used to reach the setpoint. I have a simple custom proportional controller that uses velocity commands to mimick this behavior. I'm now in the process of trying to port it to Ignition Gazebo.

[caguero]

... It seems the velocity controller respects joint stops, but doesn't respect velocity and effort limits set in <limit>.

The effort limits should be enforced since this pull request was merged. We'll need to make a new Ignition Physics release 1.x to have the fix.

[acschang]

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

• Please adjust the model's IMU noise parameters in the model.sdf file to meet the standard SubT specification as in the X1C6 model.
• The front and rear flippers are not adhering to the specified maximum velocity limits for negative and positive commands respectively. We will continue to work with you to resolve issues with the flippers.
• Please check and verify the accuracy of vehicle collision when flipped. Currently the vehicle balances on a single point when flipped upside down.
• Please add meshes for each light source and affix each light source to the platform.
• Please verify or adjust the camera resolution for the Pointgrey Ladybug LB-3 omnidirectional camera as the present resolution (1616x1232) differs from the datasheet (1600x1200).

Please address the issues noted above and add commits to this pull request as soon as possible. The submissions are expected to be incorporated into the SubT Virtual Testbed pending a successful review.

[peci1]

I fixed the IMU, collisions and the reported problem with robot_description.

@acschang What do you mean by adding meshes to lights? All of our lights are LED strips glued to the base link.

The camera resolution is set according to the real data we get from it. The datasheet apparently rounded the numbers a bit.

[peci1]

I also added a plugin that handles rotation of the lidar (it reverses the rotation direction every time the lidar reaches a given angular limit).

[caguero]

Here's my view from Ignition Gazebo and rviz. Maybe the mesh that @acschang refers is the depth camera and its support. See image below:

[peci1]

The depth camera support was removed from SDF because it occluded the camera views (in our Gazebo 9 simulation this doesn't happen, so there's probably some imperfection in the transfer to Ignition, and I just thought this is a reasonable quick solution).

The LED strips are present in the texture - they're the grayish strips near the top of the blue body.

[peci1]

I've commited an attempt for the flipper control plugin ported from our Gazebo 9 implementation. It is still WIP, but I wanted to share it so that you can comment on the approach. I'm now leaving for a 2 day vacation when I won't be able to respond.

Basically, the plugin provides both the positional and velocity controller APIs, but handles them together so that they don't interfere. Whether positional or velocity control is used depends on which topic has received the last command.

There's also a TODO function which should allow changing the maximum allowed effort ("torque") on the fly, so that you can control the compliance of the flippers (this is also a feature the physical robot has).

[peci1]

Does anybody know how could I programatically read the value of <joint><limit velocity> and effort? It'd be nicer to use these values than passing them via a plugin parameter.

[caguero]

Does anybody know how could I programatically read the value of <joint><limit velocity> and effort? It'd be nicer to use these values than passing them via a plugin parameter.

I don't think it's possible right now. We'd need to create a Gazebo component for reading joint max velocity and max effort respectively.

[acschang]

Ahh, the lights are the white strips in the texture. My apologies for overlooking that while looking for a discrete object for illumination. The modifications to the IMU parameters and resolution of the collision when flipped resolve those outstanding issues. The verification on the exact camera resolution is sufficient.

The only outstanding aforementioned issue is flipper control.

[caguero]

The only outstanding aforementioned issue is flipper control.

The only flipper with position control enabled is the front left. You probably forgot to add the other ones to vehicle_topics.launch.

If I send a velocity command, and then, a position command, the latter is ignored. If I send a velocity command, then a 0 velocity command, and then, a position command, the position command is executed. Is this expected?

[acschang]

We will adjust the RGBD resolution to 640x480 to match other robots in the repository that are also modeling the RealSense D435. No action is needed on your part.

[acschang]

Here's my view from Ignition Gazebo and rviz. Maybe the mesh that @acschang refers is the depth camera and its support. See image below:

This missing mesh for the RGBD camera will also need to be resolved. It may be an in correct reference in the model.sdf given that the RobotModel representation in RViz does not appear to have this issue.

[nkoenig]

Thanks for the submission @peci1 . I've moved these models to #528 and will close this PR.