Ros / ARGoS Sync

[tylerferrara]

There are two problems at hand:

1. Synchronization between the argos simulation time and ros time
   • Some modules have their own clocks, which need to all be incremented via argos time
2. Odometer scaling
   • Robot pose isn't correctly estimated, causing mapping inconsistencies
   • this could be from some custom odometry math may be incorrect
   • Khephera measures (header file) may be incorrect or measured in different units
   • Proof: Encoder values for teleop control are not consistent between argos and ros
   • AKA: The argos robot thinks its moving at one rate, while the ros robot is in a different measure
   • Also, if the scale of our map is incorrect, we are not correctly estimating how the robot moves in its environment

Within Branch: SM_add_merge_service

[nikopoulospet]

To elaborate more on this. The root cause of the concern is the inability of robots to correctly build a map from Gmapping in rviz. This could be caused by a number of issues that Tyler mentioned above.

Find all the current Argos bridge info in the latest branch of SM_add_merge_service.

The issue:

Some issue with the robot odometry transform is causing this problem.

Potential reasons:

• The clocks are bad. The image below shows a warning that we are losing odom tf data because the tf publisher is not using the correct header time. To sync ros with argos we are publishing time updates using a loop function and configured ros with the parameter 'use_sim_time'. Together this should alleviate the clock issues but time sync errors remain.

• The odometry calculation is wrong. Within the khepheriav ros controller, we calculate the forward kinematics of the robot given odometry measurements by the Argos sensors. There is a chance that either the math or the measurements here are incorrect which would mean that the odometry transform is simply publishing incorrect data. You can find were these calculations are done in khepheriav_ros.cpp

• other issues I'm not aware of. These are just my current guesses but I'm sure something else could also be causing bugs.

[tylerferrara]

Currently taking a look at how we approach time synchronization. As mentioned in the ROS Wiki on Clocks, programs which use a computer's wall time will fall out of sync with the rest of the system. Specifically, failure to synchronize wall clocks causes discrepancies in temporal calculations used in tf.

In order for a ROS node to use simulation time according to the /clock topic, the /use_sim_time parameter must be set to true before the node is initialized. This can be done in a launchfile or from the command line.

We must also control this /clock topic. ROS docs call this a "Clock Server".

Clock Server is any node that publishes to the /clock topic, and there should never be more than one running in a single ROS network.

[nikopoulospet]

clock server is handled by an argos loop function. /use sim time is set in the roslaunch file named "test_argos.launch"

[nikopoulospet]

See the most recent work on Argos bridge, fixes odometer estimates, currently testing a single robot explore stack in Argos.

I am still concerned about the clock server method, seems like this is a hacky fix which won't work in the long run, a more long term solution is to let Argos run in sync with ros.

[tylerferrara]

Two Options:

• Use a run-time clock in ARGoS, which might require a small change in the simulator codebase
• Let Argos run, keep track of time between iterations within ROS