Some plug-ins were developed for RHD, enabling control of the AU SMR and the KVL HAKO robots using the framework.

== Existing Plug-ins for RHD ==
* [[AUSerial plug-in]] Configurable driver for the RS485 bus used on the SMR
* [[HakoCan plug-in]] Can-bus driver for controlling the automated Hako Tractor
* [[GPS plug-in]] GPS module supporting classic NMEA serial GPS and the RTK GPS at KVL
* [[FOGyro plug-in]] Driver for the Fibre Optic Gyro, from KVL
* [[Crossbow plug-in]] Driver for the Crossbow IMU400 unit
* [[SMRDSerial plug-in]] Wrapper for the old SMRD interface, used for testing on the SMR
* [[rFLEX plug-in]] Driver for the iRobot rFLEX research robots platform
* [[RS232 Linesensor plug-in]] Interface for the RS232-based SMR linesensor module
* [[Stage 2.1 plug-in]] Simulator plug-in, using the [http://playerstage.sourceforge.net/index.php?src=stage Stage simulator] from the [http://playerstage.sourceforge.net/ Player/Stage project]

RHD:Plug-ins

2009-04-27T14:44:27Z

S021786:

RHD:Changelog and roadmap

2009-04-27T14:37:13Z

S021786:

RHD is a project in ongoing development.

This page will present the versions in development, and the roadmap for future releases. Files for these releases can be downloaded from the [[RHD:Downloads]] page

== Current stable release ==
This version, is the recommended version for stable operation. This version should be found on the robots runnig the RSE flash

'''2.0 (trunk)'''

This version will implement the plug-in architecture, this is now the official way to write new hardware modules for RHD.
* Major change: Plug-in architecture implementation (AB: done)
* Build envoriment updated to handle shared libs and output structure (AB: done)
* New ncurses client application for testing (AB: done)
* Final testing (AB + LVM: in progress)

== Versions in development ==
The list below, feature the current development versions of RHD. To obtain a version of RHD, that support new features, pick a version below. Remember, that this versions are not considered stable, before they are released. Requested features will be found in these versions.

'''2.1 (testing)'''
* Possibility to configure for soft-realtime through configuration. To run simulator in non-root environment. (AB:done)
* Add stage 2.1 simulator to package (LVM: done)
* Debugging of auSerial and RS232 linesensor plugins (AB: done)
* Debuggnig of server's client handling (disconnected all clients on one-client disconnect) (AB: done)
* Testing of plug-in structure on the HAKO platform (SH+JCA: Done)

'''2.2 (planned)'''
* Improvement of client-sever communication to all variable data is exchanged on connect.
* Auto log-off on inactive clients to avoid locked master client when disconnecting.

== Previous releases ==

Previous releases can be found here, with their change logs. Only use versions from this list, if some needed functions are broken in newer releases (and please inform the author if that is the case!)

'''1.1 (release tag)'''

* Formailzed version numbering and first development version, using RSE SVN (AB:done)
* Removed usleep(100) bug in GPS module (AB:done)
* Implement NAA HakoCan functionality into main RHD branch (AB:done)
* Added freerunning mode to scheduler to let simulator control time (AB:done)

'''1.0'''
* AuSerial integrated in test version
* HakoCan added in test version
* Variable database API optimized

SMRD communication

2009-02-05T10:50:51Z

S021786:

Normally, the SMR C library copes with communication between a user's program and the SMR
sensor daemon SMRD.

This page documents this communication.
----
'''Connect'''

SMRD listens for TCP/IP connections on port 24901.
Multiple clients (up to ten) can be connected at once.
----
'''Data Packets'''

The communication protocol is byte oriented and binary coded.

Data both from client to server, and from server to client, is sent in packets.
Each packet starts with a ''length'' byte, specifying the number of bytes to follow.
For example:

0x04 0x10 0x20 0x30 0x40

Only the lower 5 bits of the first byte give the length. The upper 3 bits describe the source/destination of the packet:
0b000?????: RS485 master/slave serial bus
0b001?????: RS232 serial port
0b011?????: AU simulator packet
0b111?????: SMRD control packet
----
'''Poll'''

Clients start the communication by sending a ''client ready'' packet:

0xE1 0x02

The server responds with a number of packets. First, a ''start of period''. This is followed by a series of data packets. Finally, an ''end of period'' packet is sent.
----
'''Start of period'''
0xE9 0x00 <sample no.> <time stamp>
<sample no.>: 4 byte (integer) sample number
<time stamp>: 4 byte (integer) cpu clock time stamp
----
'''Motor data'''

The two motors on an SMR are numbered 1 and 2. In the following, replace ''i'' with the motor number.

Some motor modules return more data than others. The length byte distinguishes between module types.

0x03 0xAi <encoder position>
0x05 0xAi <encoder position> <status> <pwm>
<encoder position>: 2 byte (integer). 2000 positions per wheel turn.
<status>: 1 byte status
<pwm>: 1 byte motor drive voltage

MSB is to the left, for example: encoder position = 256*byte2 + byte3.
----
'''IR proximity data'''

0x09 0x88 <proximity data>
<proximity data>: 8 bytes (array of bytes) proximity data. The first 6 bytes contain measurement data.
----
'''Serial line sensor'''

The serial port line sensor sends 16 bytes of sensor data; typically split into 2 or more packets.
So, the ''length'' fields can vary from packet, and from sample to sample. A typical period might look like this:
0x27 0x73 <6 bytes serial data>
0x2B 0x73 <10 bytes serial data>
<serial data>: Up to 16 bytes (array of bytes) serial data. The first 8 bytes contain measurement data.
Other packets may be received between serial port packets.
----
'''RS485 line sensor'''

0x09 0x17 <line sensor data>
<line sensor data>: 8 bytes (array of bytes) line sensor data.
----
'''Power module'''

0x08 0x19 0b<fedcbaAA> 0b<BBCCDDEE> 0b<AAAAAAAA> 0b<BBBBBBBB> 0b<CCCCCCCC> 0b<DDDDDDDD> 0b<EEEEEEEE>
fedcba: Digital input channels 5 to 0.
AAAAAAAAAA...EEEEEEEEEE: Analog input (10 bits) channels 0 to 4. The two MSBs come from one of the pairs in byte 2 or 3. LSB is to the right.

The module inputs are connected as follows:
Digital input 0: Power on.
Digital input 1...5: Unused.
Analog input 0: Battery voltage.
Analog input 1: External supply voltage.
Analog input 2,3,4: Unused.

To convert analog input readings to volts:

Vin = 4.1 * 3.5 / 1.1 / 1024 * ADin

----
'''New Power Module v. 3.3b (firmware 3.31+)'''

Data is sent in same format as the old module

The module inputs are connected as follows:
Digital input 0 (a): Power on.
Digital input 1 (b): External Power Connected.
Digital input 2 (c): Robot is charging.
Digital input 3 (d): Robot is calibrating battery
Digital input 4..5 (e..f): Unused.
Analog input 0 (A): Battery voltage.
Analog input 1 (B): Robot Power Supply voltage.
Analog input 2 (C): Battery charge current.
Analog input 3 (D): Battery temperature sensor 1.
Analog input 4 (E): Battery state-of-charge.

'''To convert analog input readings into usable values:'''
Battery voltage: Vbatt = 4.1 * 3.5 / 1.1 / 1024 * ADin. [V]
Robot PSU voltage: Vpsu = 4.1 * 3.5 / 1.1 / 1024 * ADin. [V]
Battery Chg Current: Ichg = ADin * 3 [mA].
Battery Temp 1: Tbatt = ADin [0.1 °C].
Battery SOC: Bsoc = ADin [% remaining capacity]

----
'''End of period'''

SMRD signals that the period is finished by sending ''end of period''.
0xE1 0x01
No more packets will be sent to the client until a new poll is started.

----
'''Simulation time'''

When SMRdemo is connected to the simulator, it will receive the simulation
time just before the ''end of period'' packet.
0x69 0x01 <simulation time>
<simulation time>: 8 byte (double) simulation time.

S021786:

RHD:Changelog and roadmap

2008-09-29T13:57:41Z

S021786:

RHD:News

2008-09-29T13:56:39Z

S021786:

<noinclude>
News for the [[RHD]] project

</noinclude>

* '''29 September 2008:''' rFLEX plug-in is completed and ready for use (see doc here [[rFLEX plugin]])
* '''29 September 2008:''' RHD 2.0 is in it's final testing state
* '''18 September 2008:''' RHD 2.0 work started and RHD project report online
* '''21 July 2008:''' Development roadmap added
* '''29 June 2008:''' RHD Wiki page online (still no info though)


<noinclude>

</noinclude>

RHD:News

2008-09-29T13:56:14Z

S021786:

<noinclude>
News for the [[RHD]] project

</noinclude>

* '''29 September 2008''' rFLEX plug-in is completed and ready for use (see doc here [[rFLEX plugin]])
* '''29 September 2008''' RHD 2.0 is in it's final testing state
* '''18 September 2008:''' RHD 2.0 work started and RHD project report online
* '''21 July 2008:''' Development roadmap added
* '''29 June 2008:''' RHD Wiki page online (still no info though)


<noinclude>

</noinclude>

RFLEX plugin

2008-09-29T13:54:39Z

S021786: rFLEX plugin description final

As the Institute for Automation got a hand on an iRobot ATRV-Jr robot platform, we needed a plug-in to control the robot. The robot has a fully developed control framework built-in, the rFLEX, that provides odometry and sensors through a RS-232 connection.

iRobot has moved focus towards developing consumer (vacuum) and military robots, so no documentation '''at all''' is available for the robot. Fortunately, Carnegie Mellon University (CMU) has drivers for the rFLEX in their Carnegie Mellon Robot Navigation Toolkit ([http://carmen.sourceforge.net, CARMEN]). This is actually also the base for the rFLEX drivers in Player/Stage framework. About half of the code is ported from [http://carmen.sourceforge.net, CARMEN] - Thank you guys!

== The rFLEX system ==

rFLEX provides a full interface to the robot sensors, and does somewhat of post-processing, such as odometry calculations and ultrasound processing.

The intension of the interface is to create a flexible platform for all iRobot research robots. As we only had the ATRV-Jr robot for testing, the rFLEX plugin is kept as universal as possible, but bumpers and ultrasound senaors are mapped specifically for ATRV-Jr.

Odometry is provided in a translation / rotation axis configuration. The system outputs position, velocity, accelleration and torque in both axes (i.e. forward speed and rotation speed)

== XML Configuration ==

Through the RHD XML configuration, it is possible to define parameters for the plug-in

The default configuration is seen below:

<code>

<rflex enable="true" lib="librflex.so.1" critical="true">
<serial port="/dev/ttyUSB0" baudrate="115200" />
<odometry period="100000" />
<translation accel="100000" torque="30000" />
<rotation accel="100000" torque="35000" />
<bumperbrake default="true" />
</rflex>
</code>

Configuration include serial port settings and default values for accelleration and torque in both translation and rotation axes.

The odometry period sets, how often a odometry package is sampled to the serial bus. The value is in µs.

The final parameter is the bumperbrake, that is described below.

== Plug-in special features ==

Normally, it is against RHD principles to assign too much robot functionality into the plug-ins. But as a safety feature, a brake feature is coupled to the bumpers of the robot.

If the bumperbrake is enabled, the robot will enable it's brake, when bumpers is touched. The default setting is assigned in the XML configuration, but a write-variable makes it possible to en/disable the feature at runtime.
This makes the response-time as short as possible for emergency stop.

== Plug-in variables ==

Most of the plug-in functionality is described by the plug-ins it creates

{| class="wikitable"
|+ rFLEX plugin variable table
|-
! Direction     !! Variable name     !! Array contents     !! Description
|-
! r
| transvel || [vel] || Velocity of translation
|-
! r
| transaccl || [accl] || Acceleration of translation
|-
! r
| transtorque || [torque] || Torque of translation
|-
! r
| transposition || [pos] || Position of translation (distance)
|-
! r
| rotvel || [vel] || Velocity of rotation
|-
! r
| rotaccl || [accl] || Acceleration of rotation
|-
! r
| rottorque || [torque] || Torque of rotation
|-
! r
| rotposition || [pos] || Position of rotation (bering)
|-
! r
| sonar || [s0]..[s16] || Measurements of sonars (mapped 0-16, as on ATRV-Jr)
|-
! r
| bumper || [front][rear] || Status of ARTV-Jr bumpers
|-
! r
| brake || [brake] || Status of robot brake (updated at 1Hz)
|-
! r
| battvoltage || [batt] || Raw mesurement of battery voltage (needs calibration and updated at 1Hz)
|-
! w
| cmdtransvel || [vel] || Desired velocity of translation (command)
|-
! w
| transaccl || [accl] || Max acceleration of translation (XML default used if = 0)
|-
! w
| transtorque || [torque] || Max torque of translation (XML default used if = 0)
|-
! w
| rotvel || [vel] || Desired velocity of rotation (command)
|-
! w
| rotaccl || [accl] || Max acceleration of rotation (XML default used if = 0)
|-
! w
| rottorque || [torque] || Max torque of rotation (XML default used if = 0)
|-
! w
| usesonar || [enable] || Enable / disable ultrasound sonars (default off)
|-
! w
| cmdbrake || [brake] || Enable / disable robot brake (default off)
|-
! w
| bumperbrake || [enable] || Enable / disable bumperbrake (overrides default)
|}

Using these variables, it is possible to control all functions on the ATRV-Jr robot... Enjoy

2008-09-18T08:06:26Z

S021786:

RSE projects are all developmental projects, with ongoing improvement and research.

For proper version management, backup and sharing, the projects are managed in a central SVN repository, hosted by the DTU Elektro production server Timmy.

== SVN Access ==

To get access to the RSE SVN, you must have an account on the timmy server and be a RSE group member.

The SVN is accessed using the svn+ssh protocol, with the following connection string:

<code>
svn+ssh://[timmy username]@timmy.elektro.dtu.dk/home/project-users/rse/svnrepo
</code>

As the SVN is run through SSH, you will be requested to input your SSH password MANY times, until you have setup your computer with a shared SSH key.

== Handling SVN projects ==

Managing the projects in SVN should be done according to the guidelines in the SVN book[http://svnbook.red-bean.com/]. It is really good and usefull reading.

At a prevoius robot-meeting, there was given an introduction for SVN useage.

The slides from the presentation can be found here: [[Media:SVN_Best_practice.pdf]]

== SSH Shared keys ==

A great toturial for generating shared SSH keys can be found in the article [http://www.cvrti.utah.edu/~dustman/no-more-pw-ssh/ No More Passwords (with SSH)]

RHD:Changelog and roadmap

2008-09-15T14:48:45Z

S021786: