Difference between revisions of "IKart"

From Wiki for iCub and Friends
Jump to: navigation, search
m (iKart overview)
m (iKart overview)
Line 5: Line 5:
  
 
BLA BLA  
 
BLA BLA  
 +
* six omni-directional wheels
 
* Intel i7 quad core CPU.
 
* Intel i7 quad core CPU.
 
* A Lithium-ion (48V, 20Ah) provides 2 hours of autonomy to iKart+iCub system (4 hours if iCub is not connected).
 
* A Lithium-ion (48V, 20Ah) provides 2 hours of autonomy to iKart+iCub system (4 hours if iCub is not connected).

Revision as of 02:00, 5 January 2012

iKart overview

The iKart

iKart is an holonomic mobile platform designed to provide to iCub autonomous navigation capabilities in structured environments.

BLA BLA

  • six omni-directional wheels
  • Intel i7 quad core CPU.
  • A Lithium-ion (48V, 20Ah) provides 2 hours of autonomy to iKart+iCub system (4 hours if iCub is not connected).
  • A 300Mbit/s wireless is used to transfer data.
  • A Laser Range finder for obstacle detection and localization.
  • BLA BLA
  • BLA BLA
  • BLA BLA
  • BLA BLA

BLA BLA

iKart hardware description

In this section the main iKart hardware components are described. In the picture below, the location of the various components is shown:

Ikart components.jpg

Main panel

BLA BLA

Ikart main panel.jpg

Internal panel

BLA BLA

Ikart internal panel.jpg

Battery

BLA BLA

File:Ikart battery.jpg

Wireless

IKart is equipped with a DAP-1522 wireless bridge (techanical specifications can be found on the manufacture website http://www.dlink.com/products/?pid=663), located just on the top the iKart battery. On the back of the wireless bridge, two LAN ports are used: one port is connected to the iKart motherboard, the other one is connected to iCub PC104 (through the power cable which connects iKart with iCub). The wireless bridge is powered by the iKart 48V-to-5V DC/DC converter.

Ikart wireless.jpg

Hard Disk

The iKart hard disk is located under the front plate, on the left side.

Motor control boards

Wheels suspensions

The three idle wheels of the iKart platform are equipped with a suspension mechanism. The preload of the suspensions can be individually tuned through two nuts that are located on the top of the mechanism, inside the iKart. A screw, also located on the top of the mechanism, allows to set the limit of the suspension. During the iKart assembly, the preload is tuned in order to take in account the weight of the battery and of the whole iCub placed on the top of the platform.

File:Ikart suspensions.jpg

CAN to USB converter

A CAN-USB2 converter is used to communicate with the motor control boards. The interface is located under the front plate, on the right side. Technical information about the CAN-USB2 converter can be found on the manufacturer website: http://www.esd.eu/esd2004/german/PDF-file/CAN/Englisch/can-usb2_e.pdf

Esd2.jpg

Internal power supply

The iKart in equipped with three internal power supply modules:

  • An ATX power supply (input: 48V) which provides power to the iKart motherboard.
  • A 48V-to-12V DC/DC converter, which provides power to the laser rangefinder.
  • A 48V-to-5V DC/DC converter, which provides power supply to the wireless switch.

Laser scanner

An UTM-30LX Laser Range finder (Hokuyo Ltd) is mounted in front of the iKart. It is powered by the iKart 48-to-12V DC/DC converter, while the data are transmitted on through a separated USB cable. The range finder is able to detect obstacles up to 30m, with a scan angle of 270 degrees. The maximum refresh rate is 40Hz.

Hokuyo.jpg

Joystick receiver

The joystick receiver is a standard XBox 360 wireless receiver. It is placed on the of the battery and is connected to an internal USB connector. The wireless range is about 10 meters.

XboxWirelessReceiver.jpg

External power supply (read carefully!)

iKart uses the same external power supply of iCub (please refer to: http://eris.liralab.it/wiki/Power_supply) although with different settings. The external power supply must be in fact configured in order to provide a voltage of 52.5V with a current limit of 18A. Using these settings is extremely important:

  • Since the iKart battery has a nominal voltage of 52V, the external power supply voltage must be always higher then the battery voltage, in order to prevent an undesired battery discharge when the iKart power supply switch is set to battery (blue led on).
  • A current limit of 18A, instead, is required in order to prevent accidental brownouts due to to the high inrush-current when the iKart motor switch is turned on. Since an unexpected reset during a write operation on the disk may compromise the integrity of the saved data, it is extremely important to increase the current limit of the power supply to 18A.

Xantrex.jpg

iKart Software

In this section the core modules required to run the iKart are described. A diagram describing how these module are interconnected is presented below (click to enlarge).

x

iCub Interface

iKart uses the same iCubInterface application used by the iCub to communicate with the motor control boards. The system configuration is specified in the files iKart.ini and ikart_wheels.ini, which are located in the $IKART_ROOT\app\iKart\conf folder and installed by the make install command in the folder $ICUB_ROOT\app. The robot configuration is extremely simple, since a single CANbus line is used. This results in a single Yarp device driver which is used to control the robot analogously to the way in which iCub is controlled. The only difference between the two is that instead of having multiple robot parts such as head, left_arm, right_leg, etc. iKart has one only robot part, called wheels.

iKart Control

The iKartCtrl module is the main control module that acts as the interface between the user commands and the robot. The application consists of several threads which run concurrently, each of them responsible for a particular robot interface. More in particular:

  • motorControlThread: The thread receives the user commands and transform them into speed reference signals which are sent to the individual motors. The input commands can be sent to the controller through three different input ports:
    • /ikart/joystick:i This is the port to which connect the output of the joystickCtrl module.
    • /ikart/control:i On this port a user module (for example, a navigation software) can send commands to the iKart.
    • /ikart/aux_control:i Additional port providing the same functionality of /ikart/control:i

While all the three ports provide the same functionality, they have different (decreasing) priority. An input on the joystick:i port overrides an input on control:i port, which, in turn overrides an input on the aux_control:i. In this way, for example, the user can always take control of the iKart through the joystick, even if another module is sending wrong commands to the iKart. The commands sent to iKart through these ports can be expressed in two formats:

    • percentage respect to the maximum speed. This is the format used by default by the joystickCtrl module. The bottle is consituted by five values, with the following meaning
  • protocol identifier (int): an int value fixed to 1.
  • heading (double): the commanded linear direction of the iKart, expressed in degrees. The heading must me expressed accordingly to iKart reference frame, represented in the picture at the end of this section.
  • linear speed (double): the commanded linear speed, expressed as a percentage of the robot maximum linear speed (0-100.0%).
  • angular speed (double): the commanded angular speed, expressed as a percentage of the robot maximum angular speed (0-100.0%).
  • motor scaling factor (double): a scaling factor expressed in percentage (0-100.0%) that multiplies both the linear and the angular speed.
    • metric format. This is the preferred format for user modules. The bottle is constituted by four values, with the following meaning:
  • protocol identifier (int): an int value fixed to 2.
  • heading (double): the commanded linear direction of the iKart, expressed in degrees. The heading must me expressed accordingly to iKart reference frame, represented in the picture at the end of this section.
  • linear speed (double): the commanded linear speed, expressed in m/s.
  • angular speed (double): the commanded angular speed, expressed in deg/s.
  • odometryThread': It computes the iKart odometry, using the information take from the motor encoders. It provides the two following yarp ports:
    • /ikart/odometry:o. This port broadcasts the robot odometry. The bottle is constituted by six values (double), with the following meaning:
  • x position [m]
  • y position [m]
  • orientation [deg]
  • x velocity [m/s]
  • y velocity [m/s]
  • angular velocity [deg/s]
Please note that wheels slippage and model inaccuracies may affect the odometry accuracy, resulting in a cumulative error. This is not an issue of the iKart platform, but it is an intrinsic problem of the odometry computation in all mobile robot. For this reason, odometry information must be integrated with a localization mechanism (based for example on the laser data). Please refer to the SLAM section for information about performing absolute localization with the iKart. For the orientation of the x and y axes, please refer to the iKart reference frame picture at the end of this section.
  • /ikart/odometer:o. Information about the cumulative distance traveled by the robot is broadcasted by this port. The bottle is consitituted by two values (double), with the following meaning:
  • traveled distance [m]
  • traveled angle [deg]
Both the odometry and the odometer information can be zeroed by sending the command reset_odometry to the /ikart/rpc port.
  • laserScannerThread: It retrieves the laser rangefinder measurements through its yarp interfaces, and broadcasts the data on the outport port.
    • /ikart/laser:o. Contains the laser scan measurements. The data is constituted by an array of 1080 double, corresponding to the measurements (expressed in mm) obtained from the laser during a counterclockwise scan (each measurements corresponds to an angle of 270/1080= 0.25 degrees).

iKartCtrl RPC commands

The iKartCtrl module also provides a port /ikart/rpc to which the user can send rpc commands. Below is reported the list of the available rpc commands:

  • help displays the list of the available commands
  • run turns on the three motors (use to run again the iKart after pressing the fault button)
  • idle turns off the three motors.
  • reset_odometry set to zero both the odometry and the odometer data.

The iKart Reference frame

Both the cartesian joystick/user commands and the iKart odometry are expressed into the iKart reference frame which is oriented according to the following convention:

  • the y axis is directed forward.
  • the x axis is directed toward right.
  • the heading angle is positive clockwise and negative counterclockwise.

Ikart ref frame.jpg

Joystick Control

The joystickCtrl module allows to take the input from a joystick and send it on a yarp port (by default: /joystickCtrl:o). The module takes in input a .ini file in which the user can specify the configuration of the joystick, including axis remapping, different scaling factors, deadbands, etc. A complete list of the available configuration options is reported in the module documentation.

Below is reported the default joystick configuration to control the iKart. The joystick configuration is specified in the file: $ICUB_ROOT/app/joystickCtrl/iKart.ini

x

Laser GUI

The laserScannerGUI provides a simple graphical interface in order to visualize the measurements performed by the frontal laser rangefinder. The module receives the measurements from the iKartCtrl module through the /ikart/laser:o yarp port. A list of all the available options (e.g. zoom, refresh rate etc.) is displayed by pressing the key 'h'.

LaserGui.jpg

Battery Manager

The iKartBattteryManager is the module responsible of verifying the status of charge (SoC) of the battery. The module is automatically started from the script /etc/rc.local during the boot sequence and periodically reads the from the /dev/ttyUSB0 serial port the SoC of the battery. The default update rate is 10 seconds. In order to preserve the robot sensible components from dangerous brownouts, the module takes the following actions if the battery is low:

  • The user will be notified with a wall message if the charge of the battery level is lower than 10%.
  • If the battery reaches a critical level (below 5%), the module will start an emergency shutdown procedure, by stopping the iCub and iKart motor interfaces, and turning off the machine, with a two minutes advance notice.

The module executes independently if the yarp server is running or not. If yes, infomation about the SoC of the battery is sent through the /ikart/battery:o port. You can also ask the module to save a timestamped logfile of the performed battery measurements, by specifying the option --logToFile into the startup script (default: off).

Battery Display

The iKartBatteryDisplay is a graphical tool which displays the current SoC of the battery. The module receives the battery info from the iKartBatteryManager module through the /ikart/battery:o yarp port. Since the iKart obviously doesn't have a graphical output, this module will not run on the iKart machine. Instead, the iKartBatteryDisplay is thought to be executed by the user on all the machines remotely connected to the iKart. The provided always-on-top window will remember to the user the remaining autonomy of the robot, so it's a good idea to execute to keep an iKartBatteryDisplay instance always running on each user machine connected to the iKart.

BatteryDisplay.jpg

Starting the iKart with the joystick

There are cases in which you may want to start moving the iKart just after the boot, without connecting to the robot in ssh, starting all the application etc. This joystick start-up is particularly useful if, for example, you turned on the iKart in a room where there is no wireless connection, and you want to move it to another room. In order to command the iKart to perform a joystick start-up, you have to follow the procedure:

  • Turn on the the iKart (with the motor switch on and the fault button unpressed).
  • Turn on your joystick by pressing the central joystick button.
  • Wait for the beep coming from the iKart, indicating that the boot is finished.
  • At this point you have for 5 seconds the chance, by pressing any button on the joystick (or moving the sticks) to initiate the joystick start-up procedure.

If a the joystick activity has been detected, the iKart will automatically initialize the following processes (and will make automatoically all the required connections):

  • The Yarp server.
  • The iCubInterface required to control the iKart motors.
  • The iKartControl module.
  • The joystickControl module.

You will be now able to move the iKart around usually the joystick as in normal operation.

How the joystick-startup procedure works

The script responsible for the joystick-startup procedure is ikart_start.sh which is originally located under $IKART_ROOT/app/iKart/ikart_boot and copied to $ICUB_BIN during the installation procedure. The scripts executes the joystickCheck module in order to verify if a joystick activity is detect, and executes initializes the yarp server and the control software if so. The ikart_start.sh script is automatically executed from the main boot script /etc/rc.local after the low-level drivers initialization.

Stopping/Restarting the joystick-startup

An analogous script ikart_stop.sh is provided in order to stop all the modules launched by the ikart_start.sh script, when controlling the iKart is no longer required. Currently, there is no way to execute this script using the joystick, so it has to be manually invoked through an ssh connection to iKart. Please also note the yarp server started by the ikart_start.sh script will be not stopped by the ikart_stop.sh script. Finally, remember that the joystick start-up procedure, which is particularly convenient during the boot, can be also manually invoked anytime, by launching the ikart_start.sh script from a console, or through an ssh connection.

Additional/user modules

In this section only the core iKart module have been described. Additional user modules, providing useful functionalities, such as reactive navigation, force control etc. are contained in the iKart repository. Please refer to the individual module documentation for a detailed description of their usage.

Using the iKart

Starting the robot

Recharging the battery

Battery can be recharged both if iKart is off and if with iKart running on the external power supply.

  • Recharging the battery with iKart turned off.
  1. Connect the battery recharge cable
  2. Put the power supply switch of the iKart frontal panel on the recharge position. The red led will turn on.
  3. Press the start button on the battery recharger.
  4. The recharger will automatically turn off when the recharge is complete.
  5. The recharge cable can be disconnected.
  6. Before turning on the iKart, remember to put battery switch back to the the external power supply position or the battery position.
  • Recharging the battery during normal operation (iKart turned on).
  1. Connect the battery recharge cable. Do not disconnect the external power supply cable.
  2. Put the battery switch of the main panel on the recharge position. The red led will turn on.
  3. Press the start button on the battery recharger.
  4. You can see the battery status of charge using the batteryDisplayManager application.
  5. The recharger will automatically turn off when the recharge is complete.
  6. The recharge cable can be disconnected. Do not disconnect the external power supply cable.
  7. The power supply switch of the iKart frontal panel can be now put back on the external power supply poistion.
  • It is not possible to recharge the battery and at the same time use the battery as primary power supply with the external power supply disconnected.

iKart (re)installation

Additional information related to the installation/configuration of iKart software are reported in this section.

Firmware

The two motor control boards use a firmware version which is different respect to the iCub. The firmware version is called 3.51 and the binary file can be found in $ICUB_ROOT\firmware\build\2BLL.iKart.out.S. The firmware of the boards can be upgraded using the canLoader application, as in iCub (see also: http://eris.liralab.it/wiki/CanLoader). The CAN interface must be set to socketCAN and the bus number to 0.

Drivers

Esdcan driver

iKart uses an ESD CAN-USB2 interface to communicate with the motor control board. The driver of the CAN-USB2 interface is contained in the socketcan linux package (further documentation here: http://lxr.linux.no/linux+v2.6.36/Documentation/networking/can.txt). You should check the installation of the socketcan package from the the kernel module configuration menu (by launching make menuconfig from the /usr/src/linux directory). Please be sure that the following kernel modules/options are installed/enabled:

  • networking support
    • CAN bus subsystem support
      • Raw CAN Protocol
      • Broadcast Manager CAN Protocol
      • CAN Device Drivers
        • CAN bit-timing calculation

After compiling the kernel, you can check if the driver modules are correctly loaded by:

  • typing dmesg and searching for a string similar to esd_usb2 2-1:1.0: device can0 registered.
  • modprobing the modules can, can_raw, can_bcm.

Additionally to the kernel modules installation, the can-usb2 driver has to be initialized by the user before using it. This operation is automatically performed at the end of the iKart boot sequence, by a line contained in the /etc/rc.local script:

ip link set can0 up type can bitrate 1000000

In order to final check if everthing is correctly working, you can run the canLoader application:

canLoader

From the GUI, choose the socketcan interface and click on the connect button. If the list of the motor control boards appears in the window below, the CAN interface is properly configured.

Joystick driver

iKart uses the xboxdrv userspace driver (further information can be found on: http://pingus.seul.org/~grumbel/xboxdrv). Since the driver runs in the user space, no additional kernel modules are required. Instead, it is highly recommended to blacklist the xpad kernel module (which is the Ubuntu default choice) since the two drivers can enter in conflict. This operation is performed by editing the file /etc/modprobe.d/blacklist.conf and adding a line:

blacklist xpad

The driver is automatically launched at the end of the iKart boot sequence by the following line of the etc/rc.local file:

xboxdrv --silent

NOTE: If you want to stop and restart the xboxdrv driver, remember that it be executed with superuser privileges.

Start-up scripts

The main iKart start-up scripts are stored in the $IKART_ROOT\app\iKart\ikart_boot directory. In particular:

  • rc.local : It is the main script that initializes the hardware drivers. It is invoked by the operating system during the boot sequence. During the iKart installation, the script must be copied to the /etc directory. All the commands included in this file are executed with super-user privileges.
  • ikart_start.sh : It is invoked by the /etc/rc.local script. The script checks if joystick activity is detected and, if so, automatically starts the yarp server and the iKart motor interface. The script must be copied to the $ICUB_BIN directory.
  • ikart_stop.sh : It can be executed by the user to stop the modules previously launched by ikart_start.sh. The script must be copied to the $ICUB_BIN directory.
  • .bashrc : This script configures the user environment variables. It includes the default search paths for the yarp/icub software. The script must be copied to the $HOME directory.

Yarp and iCub repositories

The yarp and iCub repositories are located under the folders /usr/local/src/robot/yarp2 and /usr/local/src/robot/iCub respectively.

  • To compile the Yarp repository on the iKart follow the following steps:
cd $YARP_ROOT/build
ccmake ..

check that the following mandatory cmake options are turned on:

CREATE_GUIS
CREATE_LIB_MATH
CREATE_DEVICE_LIBRARY_MODULES
ENABLE_yarpmod_serial
ENABLE_yarpmod_serialport
ENABLE_yarpmod_laserHokuyo

Once cmake has generated the makefiles, compile the yarp repository:

make 
  • When compiling the iCub repository on the iKart, please check that the following mandatory cmake options are turned on:
ENABLE_icubmod_canmotioncontrol
ENABLE_icubmod_debugInterfaceClient
ENABLE_icubmod_socketcan

Network configuration

BLABLA

iKart and ROS

It is possible to interface iKart with ROS using the ikart_ros_bridge application. The module connects to the output ports opened by the iKartCtrl module and publish the corresponding topics onto the ROS workspace. Viceversa, motor commands sent by a generic ROS node can be translated by the ikart_ros_bridge into the proper commands which can be executed by the iKartCtrl module. Below is reported the list of the yarp ports / ros topics used.

Compiling iKart_ros_bridge

Before compiling, you have to configure your environment. BLABLA

edit .bashrc

Now you can compile the ikart_ros_bridge BLABLA

ccmake
make

Running the ikart_ros_bridge

1.Check that the machine can reach the yarp nameserver located on the iKart:

yarp check

if there are problems, verify that:

  • you can can ping the iKart
ping ikart
  • you are using the correct yarp namespace
yarp namespace <your_namespace_name>

If you still cannot find the nameserver, maybe a wrong default nameserver address has been saved in the configuration of your machine. You can force Yarp to find the nameserver on the specific iKart ip address and save this configuration using the command:

yarp conf <ikart_ip_address> 10000 --write

2.Start the ROS name server:

roscore

3.Start the core iKart applications (joystickCtrl, iKartCtrl etc.) Furter information are reported in iKart user manual section: http://eris.liralab.it/wiki/IKart#Starting_the_robot

4.Start the ikart_ros_bridge application:

ikart_ros_bridge

Running the SLAM gmapping node

The following script will start the gmapping node and the ROS visualizer rviz:

roslaunch ikart_build_map.launch

Please refer to gmapping package documentation for further information about the configuration parameters used inside the script: http://www.ros.org/wiki/gmapping

x

When you are satisfied with the map create with gmapping, you can save it to a file:

rosrun map_server map_saver -f map_filename

Note: You can edit the saved map using a standard graphical editor: the color codes used for each pixel are used to represent blocking wall (black) or free areas (light grey). By adding black lines or clearing areas on the map you can instruct the navigation package to keep away the robot from those area or grant access to them.

Running the AMCL localization on a previously saved map

The gmapping node is used to create a map of environment. During the normal operation/navigation, instead, you may want just to localize the ikart into a previously saved map. This task is accomplished by the AMCL (Adaptive Monte Carlo Localization). First load the previously saved map:

rosrun map_server map_server map_filename.yaml

You can start the AMCL node launching the script:

roslaunch ikart_localize.launch

For further information about the AMCL pacakge, refer to the official documentation: http://www.ros.org/wiki/amcl

Running the navigation stack

BLABLA

Opening the visual GUI rviz

If you are not interested in running any navigation/localization package but you want just to opent the rviz GUI and connect it to the ikart_ros_bridge, simply use the following command:

rosrun rviz rviz -d ikart_build_map.vcg

iKart dimensions

Important things to remember

  • The external power supply settings are different respect to the iCub. The supply voltage must be set to 52.5V ant the current limit to 18A.
  • The iCub configuration file must be edited in order to disable the robot legs.
  • When moving around the iKart, be sure that the arms are put in a safe position (i.e. not fully extended) in order to avoid collisions with the surrounding environment.
  • Remember to replace the wireless joystick batteries regularly.

Support

If you have questions, or you experience difficulties, please contact the rc-hackers mailing list: robotcub-hackers@lists.sourceforge.net