AMiRo robot model for Gazebo ROS

• Author: Timo Korthals tkorthals@cit-ec.uni-bielefeld.de
• License: GNU General Public License, version 3 (GPL-3.0)

The AMiRo robot model (tested with Ubuntu 16.04, ROS Kinetic, Gazebo 7.8)

Quick Start

Preparation

• Build this package (e.g. catkin_make)
• Export <amiro_robot path>/amiro_gazebo/models/ to your GAZEBO_MODEL_PATH environment variable

Rviz (standalone visualization):

roslaunch amiro_description amiro_rviz.launch

Gazebo:

roslaunch amiro_gazebo amiro_simple_world.launch

Project for line following:

roslaunch amiro_gazebo amiro_assembly_line_project.launch

Example of Moving the Robot:

rostopic pub -r 10 /amiro1/cmd_vel geometry_msgs/Twist  '{linear:  {x: 0.1, y: 0.0, z: 0.0}, angular: {x: 0.0,y: 0.0,z: 0.0}}'

Example of teleoperation using ros-kinetic-turtlebot-teleop:

rosrun turtlebot_teleop turtlebot_teleop_key _scale_linear:=0.1 _scale_angular:=0.2 turtlebot_teleop/cmd_vel:=amiro1/cmd_vel

Available AMiRo Models

All models can be loaded by including and parameterizing amiro.launch.
Have a look on amiro_world.launch, amiro_simple_world.launch, or others.

• amiro.xacro: Common implementation. No sensors, but differential kinematic. All other models are derived from this model.
• amiro_basic.xacro: Full implementation of RFID and proximity sensors
• amiro_hokuyo.xacro: AMiRo with Hokuyo URG 04-LX LiDAR
• amiro_camera.xacro: AMiRo with common embedded RGB camera
• amiro_astra.xacro: AMiRo Astra RGBD camera
• amiro_hokuyo_cam.xacro: AMiRo with Hokuyo URG 04-LX LiDAR and embedded camera

Sensor Mockup for Basic Version

The AMiRo uses special embedded sensors which are not included in Gazebo an therefore simulated by cameras or other sensors.
All sensor mockups start within the common amiro.launch.
Make sure that in your world cast_shadows and shadows are false (compare amiro_gazebo/worlds/assembly_line.world).

Advertised Topics

• /amiro<robot_id>/proximity_ring/values: Eight ring sensors, s.t. VCNL4020 proximity sensor values, of type amiro_msgs::UInt16MultiArrayStamped
• /amiro<robot_id>/proximity_floor/values: Four floor sensors, s.t. VCNL4020 proximity sensor values, of type amiro_msgs::UInt16MultiArrayStamped
• /amiro<robot_id>/rfid_tag_list: RFID tags in range
• /amiro<robot_id>/odom: Ground truth odometry message

Debugging

• It might happen that some proximity sensor fail in the simulator which causes the mockups not to send anything.
  • Check if all four floor sensors are available: rostopic hz /amiro<robot_id>/proximity_floor_{0,1,2,3}/image_raw
  • Check if all eight ring sensors are available: rostopic hz /amiro<robot_id>/proximity_ring_{0,1,2,3,4,5,6,7}/image_raw

Proximity

The AMiRo uses VCNL4020 proximity sensors in its basic version to rectify the environment.
4 sensors pointing the floor and 8 arranged co-circular on the housing.
Here is a brief overview of sensor indices (F:Front, B:Back):

Top view of the AMiRo ring sensors and their indices:
  _____
 / 3F4 \
|2     5|
|1     6|
 \_0B7_/
Top view of the AMiRo floor sensors and their indices:
  _____
 / 3F0 \
|2     1|
|       |
 \__B__/

Ring

• Every ring sensor is simulated by 3x3 gray-scale+depth camera
• Distances are integrated and normalized to meet the output of a VCNL4020
• TODO: Respect the color values as well to simulate reflectance behaviour

Floor

• Every floor sensor is simulated by 3x3 gray-scale camera (depth is not needed by now, because we don’t assume clifs)
• Intensities are integrated and normalized to meet the output of a VCNL4020
• TODO: Respect the depth values as well to detect clifs

RFID

• Only passive tags are supported by defining their positions in sensor_mockup/yaml/rfid.yaml
• It is necessary that every entry starts with the tag_* prefix
• RFID presence is measured by absolute distance between AMiRo and tag location
• TODO: Introduce active tags, or even better: Fix the naive RFID sensor in Gazebo which needs an additional sensor in ROS as well

Reference

• How to Build a Differential Drive Simulation
• SDF
• Using Gazebo plugins
• Using a URDF in Gazebo
• xacro
• Building a Visual Robot Model with URDF from Scratch
• gazebo_ros_diff_drive.cpp
• How do you run multiple hector_quadrotors without separate urdf files?
• Simulating Small Differential Drive Robot in Gazebo

Courtesy

• General introduction
• Meshes and scripts for RGBD camera
• Meshes and scripts for Hokuyo URG04 laser and generic camera

Debugging and Hints

Common

• If simulation is to heavy, try decreasing real_time_update_rate

ROS Melodic Issues

It could happen the the AMiRo CAD model is missing in Rviz when using ROS Melodic as mentioned here.
This is related to this bug.
A simple, yet efective fix is setting the environment variable:

export LC_NUMERIC="en_US.UTF-8"

Generate SDF from XACRO

First generate an URDF file and then build the SDF from that:

rosrun xacro xacro --inorder -o model.urdf model.xacro
gz sdf -p model.urdf > model.sdf

You might be intrested, if the model was loaded in Gazebo with its proper paramters:

gz model -m <Your model name e.g. amiro1> -i

The Caster Dilemma or why Surfaces do not Slide

Adding a caster might be intuitive on the first sight, but becomes actually a pain for some reasons:
First, one is always eager to minimize the sum of joints to keep the model simple.
Thus, it is a wise idea to add a rigid sphere to the main body as proposed in 1 and 2.
Second, after that one has to set the friction and sliding parameters of the ODE physics simulator so that the sphere acts as an ideal caster.
This is actually the official way to go because it is even explained so in the official documentation 2, 3.
Unfortunately, the model which is designed in such a way don’t behave well.
In fact, the caster is more a bumper wich bumpes into the ground and stops the vehicle which can result in numerical problems while using some controllers.
Actualy, if one digs deeper you’ll find out that the friction parameters cannot not be set at all 4, 5, 6.
There is only a minimal hint in one answer where one says that friction for ODE is not implemented yet 7.
One solution to this dilemma is to use a sphere with a revolutional joint as caster to get rid of the bumpy behaviour.
However, the problem with that is that these are non-controlled joints (they are just simulated by Gazebo) and thus, Rviz reports an tf error 8.

Install the current Gazebo7 simulator

Assuming that you have installed ROS Kinetic on Ubuntu 16.04, you can go to the Gazebo install page and follow the step-by-step instruction. Do not install gazebo8, but upgrade gazebo7 via:

sudo apt-get install gazebo7