Test differences between Linux and Android versions of move_base

[jubeira]

A rosbag can be recorded using Linux stack, and then feed the input streams to a move_base node running on Android. The differences in the results shall be analyzed.

[jubeira]

Based on the update in #43 , a proposed test to check these differences is to replay a rosbag containing a cmd_vel topic recorded by a Linux stack with the Android device driving the robot.

[adamantivm]

Today we did some tests and got to the conclusion that the source of the difference is not in the base controller implementation.

We tested replaying a given trajectory from a rosbag to two different set-ups, one running base controller on Android (running tangobot without navigation and Tango nodes) and one running on Linux (turtlebot_bringup turtlebot_minimal.launch).

For the record, the rosbag was a recording of the navigation stack running on Linux, from which we replayed the /mobile_base/commands/velocity topic (in the case of the Android base controller, this was remapped to /cmd_vel)

[adamantivm]

Today we did additional tests. We couldn't find a single, whole culprit for the behavior difference, but we did find some incremental differences between the Linux and Android set-ups that could add-up to the observed difference in behavior:

1. Linux is using a velocity smoother (yocs_velocity_smoother) as part of the base_controller nodelet manager. This seems to improve the navigation output behavior to a visible extent. Recommendation: incorporate a velocity smoother in the Android configuration as well
2. When running components in different hardware components (TF publishers on a desktop computer, odom publisher on Android), there are noticeable missed TF warnings by the planner. Recommendation: run all the core components (especially TF) inside a single device.
3. It is worth noting that the "best behaved" Liinux config is using the base_contoller to publish odom. Using Tango for odometry may require additional planner fine tuning.

For the record, the environment for bisection testing included:

• A laptop running the Turtlebot set-up with a modified kobuki_node params (publish_tf = false), running turtlebot_minimal.launch
• A Tango device on top of the Turtlebot laptop, running a version of tangobot that has move_base and the move_base params commented out.
• A desktop computer running ROS core and a modified version of navigation_setup tangobot_navigation_bringup.launch by removing the remapper python script. Also turtlebot_navigation move_base.launch was manually changed to remap from cmd_vel to mobile_base/commands/velocity, to navigation_velocity_smoother/raw_cmd_vel or to not remap depending on the desired scenario.

Scenarios run include:
a) Android version: laptop is not used. Yellowstone device connected to Kobuki base, running base_controller and tango_ros. Desktop running ROS core and tangobot_navigation_bringup.launch with cmd_vel not remapped.
b) Linux base controller: laptop connected to kobuki. Yellowstone NOT connected to Kobuki, only running tango_ros node. Desktop running ROS core and tangobot_navigation_bringup.launch remapped to mobile_base/commands/velocity.
c) Linux base controller with smoothing: Sames as b) but remapping to navigation_velocity_smoother/raw_cmd_vel

Results where that a) and b) work roughly equally badly and c) works better - although this is not 100% repeatable.

[jubeira]

Update: #63 adds the remaining transformations published to tf from device, without needing to use external scripts (recommendation 2)

[jubeira]

Update: the robot doesn't get stuck when turning around when using Phab 2 Pro with its printed mount attached properly to the robot as shown in the tutorial about hardware setup; it's navigation performance is quite smooth 👍 .
The suggestion for Tango tablets is to adjust the extrinsics a bit more. This affects the navigation stack especially when performing pure rotations (if there are errors in the pose of the device wrt the base footprint, the robot will think it's translating and rotating when it's only rotating, and this could affect the navigation stack performance).

@juergensturm @PerrineAguiar @smits FYI, this was the main issue regarding navigation performance we talked about so many times in the meetings.