ZauBot - Align topic names between simulation and real

[miguelriemoliveira]

Hi @JorgeFernandes-Git , @sergiodmlteixeira and @rarrais ,

I noticed some things about the real ZauBot bagfile I have some suggestions:

The simulation be as close to the real robotic system as possible. In particular, the topic names and link names should match between the simulation and the real robot.

In the simulation we have the following topics (from here):

  camera:
    link: "camera_rgb_optical_frame"
    parent_link: "camera_link"
    child_link: "camera_rgb_frame"
    topic_name: "/camera/rgb/image_raw"
    throttle: 10
    modality: "rgb"

  camera_mb:
    link: "camera_mb_rgb_optical_frame"
    parent_link: "camera_mb_link"
    child_link: "camera_mb_rgb_frame"
    topic_name: "/camera_mb/rgb/image_raw"
    throttle: 10
    modality: rgb

  velodyne:
    link: "velodyne"
    parent_link: "base_link_mb"
    child_link: "velodyne_base_link"      
    topic_name: "/velodyne_points"
    modality: "lidar3d"

# ATOM will calibrate the extrinsic parameters of your links.
# In this section you should discriminate the additional transformations that will be part of the calibrations.
# NOTE: Delete the "" after additional_tfs to prevent the error 'All mapping items must start at the same column YAML'
additional_tfs:
  base_link_mb_to_base_link:
    parent_link: "base_link_mb"
    child_link: "base_link"

and in the bagfile we have:

➜  zaubot rostopic list 
/camera/color/camera_info
/camera/color/image_raw/compressed
/clicked_point
/clock
/initialpose
/joint_states
/move_base_simple/goal
/rosout
/rosout_agg
/tf
/tf_static

and I suspect that the tf link names are also not consistent.

We should work to make all of topic names and link names consistent between the real and the simulation. Only later we can take a bagfile and calibrate using the same calibration.yaml.

It is possible to just forget about standardizing names and create two different calibration packages for tsimulation and the real, but that's not ideal as we will never have the same robotic system.

Those would not be digital twins ... at most digital distant cousins :).

Do you think its possible to work on this? Not sure, but given that the simulation already has many results the best would be to change the zaubot drivers (BTW, where is the zaubot repo to bringup the system?) to match the simulation, instead of the opposite.

What do you think?

[JorgeFernandes-Git]

This is the tf tree of the Zau real robotic system collected from the recorded bag file:

---

It seems okay, however I notice some problems:

• The camera we mounted on the AGV is not well positioned, as can be seen on the image. The Z axis should be pointing forward and not to the right.

---

• The same can be seen on the camera on the manipulator.

---

• On the other hand, the summary generated by ATOM show that the tfs are dynamic and should be static.

It is word mentioning that the Zau tf tree was fragmented and was joined using an external node that generated those tfs. I think we can use this approach, but we have to correct the XYZ RPY and change the joint type to fixed.

[JorgeFernandes-Git]

I want to check if the zau's real system odometry is viable, @miguelriemoliveira can you help me?

This was obtain by playing the recorded bag file and running:

rostopic echo /zau/odom

---
header: 
  seq: 49929
  stamp: 
    secs: 1682697450
    nsecs: 252284759
  frame_id: "zau/odom"
child_frame_id: "zau/base_footprint"
pose: 
  pose: 
    position: 
      x: 1.2719564273588877
      y: -1.2212079224169756
      z: 0.0
    orientation: 
      x: 0.0
      y: 0.0
      z: -0.7330362102558662
      w: 0.680189616543591
  covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
twist: 
  twist: 
    linear: 
      x: 0.0
      y: 0.0
      z: 0.0
    angular: 
      x: 0.0
      y: 0.0
      z: 0.0
  covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
---

What do you think?

Here is the bag file if you prefer: https://wetransfer.com/downloads/63670cbd4582c0c0468e3df9825bf2b720230428160625/b8596cbc60644264ba990376fa85c2b320230428160645/a594e0?trk=TRN_TDL_01&utm_campaign=TRN_TDL_01&utm_medium=email&utm_source=sendgrid

[miguelriemoliveira]

Hi @JorgeFernandes-Git ,

going through your messages. Some comments:

This is the tf tree of the Zau real robotic system collected from the recorded bag file:

it is better to also add a link to a pdf of the tf tree. Tried to download the image to zoom but do not have enough resolution.

The camera we mounted on the AGV is not well positioned, as can be seen on the image. The Z axis should be pointing forward and not to the right. The same can be seen on the camera on the manipulator.

This is because the xacro is not well written right? Is it not just a matter of changing the xacro to have the correct angles?

On the other hand, the summary generated by ATOM show that the tfs are dynamic and should be static

That's strange. Opened lardemua/atom#571 for that.

It is word mentioning that the Zau tf tree was fragmented and was joined using an external node that generated those tfs. I think we can use this approach, but we have to correct the XYZ RPY and change the joint type to fixed.

It is not so simple. I mean, how are you configuring zaubot. Are you using tfs or the xacro?

Because if you are using the xacro version than all transformations must be in the xacro.

"using an external node that generated those tfs" is almost always not the best way ... why not include these in the xacro?

[miguelriemoliveira]

I want to check if the zau's real system odometry is viable, @miguelriemoliveira can you help me?

Sure, I can try. Not sure what you mean by "viable" though ... I tried configuring the calibration package using this new bag

rosrun zau_eye_on_hand_calibration configure

but get this error:

Topic /camera/color/image_raw (from sensor camera) does not exist in the bag file.

I guess the topic names are still not well aligned?

Now the cameras are called cam_1 and cam_2 ... if you changed the names, then why not robot_camera and hand_camera? It would be better than _1 and _2 ...

[miguelriemoliveira]

About the odometry.

I launched rviz and tried to visualize the odom message. It shows movement of the robot, so seems ok.

Of course the important part about the odometry is how accurate it is, and that is very hard to gauge. Only calibrating and seeing how good are the reprojection errors ...

[miguelriemoliveira]

I am having a problem configuring the calibration package. Check https://github.com/lardemua/atom/issues/572

[JorgeFernandes-Git]

I am having a problem configuring the calibration package. Check lardemua/atom#572

I @miguelriemoliveira.

The config file you are using is the config file for the eye-on-hand calibration, that is why it is different.

The config file for the full calibration (2 cameras and the additional tf) is this one:

https://github.com/JorgeFernandes-Git/zau_bot/blob/Zau_INESCTEC/Zau_INESCTEC/zau_full_calibration/calibration/config.yml

I can configure this file running:

rosrun atom_calibration configure_calibration_pkg -n zau_full_calibration -utf

[miguelriemoliveira]

Ok, thanks @JorgeFernandes-Git ,

but the topic names between real and the simulation and all experiments should be the same.