Teleop Walkthrough
From MARIEWiki
--> NOTE : Incomplete <--
Description
This walkthrough explains all the steps required to create the Teleop project included in the Showcase. Please refer to Teleop page for complete description of the project.
Required softwares
- MARIE 0.5
- Player
- Stage
- Gazebo
- FlowDesigner
- Robotflow
- CARMEN
- WxWidgets
Please refer to MARIE 0.5 Installation Guide and Showcase 0.5 Installation Guide for installation instructions.
Walkthrough
The Big Picture
This project is a semi-autonomous tele-operated mobile robot application. Here's the list of main requirements :
- Autonomous naviguation in faculty's corridors using a map
- Avoid objects and persons at anytime
- Wander in the environment
- Rest when nothing to do
- Can be teleoperate at anytime
- Avoid behavior can be deactivated (useful for pushing objects)
- Start/Stop software control
- Validation of the same base system with 2D simulation, 3D simulation and on a real robot (Magellan Pro).
Where should we start? There's a lot of possibilities! Let's try to build a complete setup rapidly. First, let's take a look on the requirements and try to do a first design iteration.
Simulation and Real Robot Environments
From the requirements, it is said that the project should run both in simulation (2D and 3D) and on Magellan Pro robot. All this can be done with Player/Stage/Gazebo.
No model of the Magellan Pro is available in simulation environements, but for global validation of the system the Pioneer model should be fine. In the real setup, Player supports all required drivers for the robot (Sick PLS and rflex drivers).
Localization & Autonomous Navigation
Requirements also specified the use of localization and autonomous navigation algorithms. CARMEN is a good candidate offering all we need. Creating a model for Magellan Pro doesn't seem difficult and CARMEN already have model for Pionner needed for simulation.
Teleoperated Navigation & Application Control
A dedicated GUI to do the teleoperation (joystick) and application controls should do the trick for this part.
Decision Making Architecture
From the requirements, the robots have many tasks to do like avoid, rest, autonomous or teleoperated navigation, etc. One well known approach to organize those tasks is by using a behavior-based architecture. As we might want to change this approach later on, maybe it's a good idea to decouple the decision making implementation from the rest of the setup right at the beginning. This will allow us to make change to it with minimal impact. Let's define data interface of the decision making implementation :
- Laser data required for avoid and push behaviors.
- Joystick data is required for teleoperated behavior.
- Autonomous navigation's motor command is required for autonomous navigation behavior.
- GUI control command is required to activate/deactivate behaviors.
- Motor command will be outputed by behavior arbitration.
Preliminary Design
Here's a view of our preliminary design :
- Blocks represents independant processes.
- Arrows represents communication links to sends and/or receives data.
- Dashed Arrows represents communication links handled directly by processes.
More details will be added gradually on this image to reflect implementation choices.
Creating simulation environment Stage
To use Stage, many configuration files must be created (.cfg, .world, .png, .inc). Please refer to Stage documentation to see how to create thoses files.
In our simulation setup, we have created a map (using Pmap) of the 5th floor of the faculty and convert it to Stage format (.png). We used Pioneer definition files already available in Stage, with laser and odometry.
Configuring AAPlayer
AAPlayer offers communication ports to send laser and odometry data at fix frequency rate, and to receive asynchronous motor command to control the robot from external applications.
In our setup, 10 Hz frequency for laser and odometry should be enough. When using Stage and Gazebo, Player's server will be located at port 6665 on localhost. Those parameters will changed when using a Pioneer robot depending on the network configuration. We'll also use the Security Watchdog Timer to activate emergency stop if motor command is not received each second.
We'll use MARIE XML data format for inputs and outputs data protcols, and we'll use sockets as Communication Strategy. To use MARIE XML data format, MARIEXMLExtractor CFB is used for motor input and MARIEXMLFormatter CFB for outputs.
Here's the configuration file for this component :
<?xml version="1.0"?>
<player elem="conf">
<server elem="q">
<hostname elem="kv">localhost</hostname>
<portnumber elem="kv">6665</portnumber>
<frequency elem="kv">10</frequency>
</server>
<watchdogTimerDelay elem="kv">1000</watchdogTimerDelay>
<inputs elem="q">
<port elem="type">
<type elem="kv">Default</type>
<name elem="kv">motor</name>
<connectionName elem="kv">player_motorCmd</connectionName>
<cs elem="type">
<type elem="kv">Socket</type>
</cs>
<receiveCFBs elem="q">
<cfb elem="type">
<type elem="kv">MarieXMLExtractor</type>
<convertToDataAbstract elem="kv">true</convertToDataAbstract>
</cfb>
</receiveCFBs>
<datatype elem="kv">any</datatype>
<description elem="kv"></description>
</port>
</inputs>
<outputs elem="q">
<port elem="type">
<type elem="kv">Default</type>
<name elem="kv">laser</name>
<connectionName elem="kv">player_laser</connectionName>
<cs elem="type">
<type elem="kv">Socket</type>
</cs>
<sendCFBs elem="q">
<cfb elem="type">
<type elem="kv">MarieXMLFormatter</type>
</cfb>
<cfb elem="type">
<type elem="kv">QtProbe</type>
<name elem="kv">DEBUG PLAYER OUTPUT LASER</name>
</cfb>
</sendCFBs>
<datatype elem="kv">any</datatype>
<description elem="kv"></description>
</port>
<port elem="type">
<type elem="kv">Default</type>
<name elem="kv">odometry</name>
<connectionName elem="kv">carmen_odometry</connectionName>
<cs elem="type">
<type elem="kv">Socket</type>
</cs>
<sendCFBs elem="q">
<cfb elem="type">
<type elem="kv">MarieXMLFormatter</type>
</cfb>
</sendCFBs>
<datatype elem="kv">any</datatype>
<description elem="kv"></description>
</port>
</outputs>
</player>
Configuring AACARMEN
The Application Adapter for CARMEN (AACarmen) have multiple operating modes. The navigation mode is well suited for our application as we'll use both CARMEN's localization and navigation capabilities, giving us the possibility to use the available interface to postionned the robot, the goal and to start autonomous navigation. In this mode, AACarmen uses communication ports to receive laser and odometry data (given by AAPlayer), and an output port for navigation motor command.
Creating Behavior-based decisional architecture with FlowDesigner/RobotFlow
Programming the behavior-based decisional architecture can be achieve using many languages. MARIE offers an Application Adapter for FlowDesigner/RobotFlow which is a graphical programming tools that already have behavior-based blocks available. This might accelerate our development at the beginning and we'll see later if we need something more specific as programming language for this implementation.
Configuring AAFD for decisional architecture
Creating joystick control with FlowDesigner/RobotFlow
Configuring AAFD for joystick control
Unfortunately, we don't have any joystick program to interfaces our joystick. To minimize hardware interface development at the beginning, we can quickly use RobotFlow to do a virtual joystick and we'll replace it with the real joystick later on. We just need to take care of the interface between the joystick and the system to make sure we can replace the vitual joystick with the real one seamlessly.
Configuring Splitters, Mailboxs and SharedMap
Creating GUI for application control
Creating project
First, we need to create a new directory that will contain all our project files :
> mkdir teleop
The first file to create is the main project file. In this file, we need to give the information about the different variations of the project. We know for sure that we have at least three variations : one using Stage, one using Gazebo and another one with Magellan Pro. For each variation we also need to indicate the grid configuration, which means how many computing nodes will be used. In simulation (Stage and Gazebo) we will use only 1 node for all applications. In the Magellan Pro setup, we'll use 2 nodes : one for GUI and teleoperation applications and the other node running everything else.
Knowing all this, we can then edit the teleop.prj file according to the expected syntax describe in Project Files. In order to keep track of all the required files, we tried to use meaningful filenames. Here's the final result :
