AU Robot Servers

From Rsewiki
(Difference between revisions)
Jump to: navigation, search
(Modules (plug-ins))
 
(100 intermediate revisions by one user not shown)
Line 1: Line 1:
==Download==
 
  
The tarball (zipped) versions are here: http://server.elektro.dtu.dk/ftp/jca/mobotware/
+
==Base Documentation==
  
and a few comments for the releases in [[Release notes]]
+
====Programming API documentation====
  
Latest version:
+
'''AU Robot servers (AURC)'''
  
'''On Jensen:''' (in /usr/local/smr/bin) is 2.870 (from 24 feb 2010).
+
AURS class documentation http://aut.elektro.dtu.dk/mobotware/doc/html/classes.html
  
The Jensen version is kept at this version until course 31388 finishes (until ~ 1 june 2010)
+
'''Open CV'''
  
'''On SVN:''' is version 2.920.
+
http://docs.opencv.org/
  
NB! the svn version can not directly load plugins compiled against version 2.870 (or earlier).
+
'''Point Cloud Library'''
  
In version 2.920 the server core is updated to make the minimum plug-in design (one cpp file) and still use all server resources (global variables, call to other plugins etc).  
+
http://pointclouds.org/documentation/
  
==Base Documentation==
+
[[Mobotware Changes for 18.04]]
  
===Programming API documentation===
+
====Servers====
  
'''AU Robot servers (AURC)'''
+
===== Camera server =====
 +
The camera server - see [[ucamserver]] for use details - is pre-configured for camera related functionality.
  
AURS class documentation http://www.iau.dtu.dk/~jca/rac/html/index.html
+
===== Laser scanner server =====
  
'''Open CV'''
+
The laser scanner server - see [[ulmsserver]] for details - is optimized for functions using laser scanner data.
  
OpenCV (1.0) general documentation http://server.elektro.dtu.dk/www/jca/opencv/
+
===== Client for monitoring (auclient) =====
  
OpenCV (1.0) CXCORE documentation http://server.elektro.dtu.dk/www/jca/opencv/ref/opencvref_cxcore.htm
+
A data monitoring client [[auclient]] is a server pre-configured to display graphics on an x-console. It should be executed on a computer with a screen, i.e. not on the robots.
  
OpenCV (1.0) CV documentation http://server.elektro.dtu.dk/www/jca/opencv/ref/opencvref_cv.htm
+
===== General server =====
 +
An general server [[userver]] is intended for functionality not related to camera and laser scanners
  
===General issues===
+
=====Server stub=====
 +
A server stub [[auservertest]] is a port server that just shows messages from connected clients - with a timestamp. This can e.g. be used to replace the MRC to verify the messages intended for the MRC.
  
====Server structure====
+
==Modules (plug-ins)==
  
[[Server structure]] issues (global variables and methods)
+
====Descriptions====
  
Camera server [[ucamserver]]
+
Not all plug-in modules has a description on these pages (yet).
  
Laser scanner server [[ulmsserver]]
+
* [[auball]] - eksamel ball-finder plugin
 +
* Raspberry Pi camera plugin ([[aupicam]]) - works only on Raspberry
 +
* Crop row follower (robotti) camera plugin - aucroprow2.so.0 - by Aske Bay Jakobsen [[Crop row finder]]
 +
* Time of flight camera - autof.so.0 by Kristian Villien [[Time of flight camera]]
 +
* People detection and tracking - aupplfinder.so.0 by Mikkel Viager [[People tracker]]
 +
* Obstacle avoidance - auavoidk.so.0 Kaspers intuitive method [[Obstacle Avoidance K]]
 +
* Obstacle avoidance (visibility graph) auavoid.so.0 - [[Obstacle avoidance - visibility graph]]
 +
* Rule engine (aurule.so.0) [[Rule based scripts]]
 +
* drivebase.rule - The basis for (HAKO) missions - [[Drivebase.rule]]
 +
* Stereo camera - Videre design device (ausvs.so.0) - [[Videre Design stereo camera plug-in]]
 +
* Kinect camera (aukinect.so.0) - [[Kinect plug-in]]
 +
* Mapped obstacles (aumapobst.so.0) - converts near map lines to obstacle polygons [[Mapped obstacles]]
 +
* Laser obstacles (aulobst.so.0) - make obstacles from laserscan - uses ransac lines [[Laser obstacles]]
 +
* Locater - tree row locater (locater.so.0) - [[locater - tree row]] based on laserscan lines and fluffy lines (tree-rows) and line definitions in mapbase.so.0
 +
* smr - MRC interface (ausmr.so.0) - [[MRC interface]] holds some routines to control and interface with the MRC, and a smrctl resource to translate manoeuvres to SMRCL.
 +
* Vaiable pool (auvar.so.0) is linked staticalli in all servers - use "module load=var".  for variables and methods see [[Variables]]
 +
* Pose and pose history is maintained by odoPose, mapPose and utmPose - see [[Coordinate systems]]
 +
* Map ([[Mapbase]]) using lines and points - with optional attributes (mapbase.so.0) - a plug-in for mapped lines and connected graph of routes
 +
* PCL test plugin ([[aupcltest]]) requires that pcl version >=1.4 is installed.
 +
* auv4lgst gstreamer plugin - experimental - [[gstreamer-plugin]]
 +
* [[auview]] - a 3D viewer for the auclient, shown pointclouds and most of the features that the audisp can show in 2D.
 +
* [[audisp]] - 2D (top view) display of robot, sensor data (e.g. laserscans) an path history.
  
Empty server [[userver]]
+
@todo document these:
  
Data monitoring client [[auclient]]
+
* Stereo (aimed for 2 aligned cameras supported by ucamserver) (austereo.so.0) - uses openCV stereo library.
 +
* Slow task scheduler (aucron.so.0) - a module to execute bash commands at regular intervals - e.g. to move logged images at low priority
 +
* Drive control to a specific pose (audrivepos.so.0) - uses auavoid plug-in to find path to pose.
 +
* Roaddrive - a drive controller thet follows a road edge (auroaddrive.so.0) - uses auavoid, ausmr and ulmspassable for path planning.
 +
* Line finder plug-in to find and maintain wall lines (auefline.so.0). Is based on the libauextractfeatures library.
 +
* Gps plug-in (augps.so.0) - maintains an UTM pose from a serial/USB GPS (NMEA) connection.
 +
* aulmsnear.so.0 - a small function to return the closest point in a laserscan as a <laser l0=0.0 .../> type message
 +
* ulmspassable.so.0 - extracts road lines from a laserscan (tilted laser) and holds a database of detected obstacles.
 +
* Virtual 360 deg laser scanner device (ulmsv360.so.0). This is also available as static plug-in for the ulmsserver (module load=v360).
 +
* auseq - deprecated sequencer plug-in
  
 
====Coordinate systems====
 
====Coordinate systems====
  
 
The three [[Coordinate systems]] are available as static: odometry (odoPose), UTM (utmPose) and Map (mapPose)
 
The three [[Coordinate systems]] are available as static: odometry (odoPose), UTM (utmPose) and Map (mapPose)
 +
 +
====How to make a plugin====
  
 
[[plug-in structure]]
 
[[plug-in structure]]
 +
 +
====Variables and functions====
  
 
[[Variables]] (global variables and functions across plugins)
 
[[Variables]] (global variables and functions across plugins)
  
 +
====Replay functionality====
  
===Module description===
+
A data interface can often be logged, and a replay of the interface may then be beneficial for analysis and debugging.
  
Not all plug-ins has a description on these pages (yet), the following is available.
+
AURS has a replay facility, see [[Replay]]
  
====Obstacle avoidance (auavoid.so.0)====
+
==Interface description==
  
 +
MOBOTWARE is a set of socket servers, each server has 1 port and allows up to 10 simultaneous clients (port numbers used are from 24919 to 24930).
  
* auavoid.so.0 - visual graph obstacle avoidance (not stable)
+
XML consist of tags and text, a tag is in brackets “<” and “>” and may be split into an open tag and a close tag, with some text imbetween e.g. <tagname> some tekst </tagname>. The open tag may have attributes and may have an implicit close tag (named a full tag), e.g.:
(version 2.920)
+
<tagname info=”low on power” device=”gps”/>. Attributes must have a value, the value must be in quotes (or apostrophes).
  
====Script language - rule based - (aurule.so.0)====
+
===Connect===
  
* aurule.so.0 - A rule based mission sequencer - [[Rule based mission sequencer]]
+
When a client connects to a server the server sends an XML opening sequence of XML tags – something like:
** drivebase.rule - The basis for (HAKO) missions - [[Drivebase.rule]]
+
(version 2.920)
+
  
====Stereo camera (ausvs.so.0)====
+
<?xml version="1.0" encoding="UTF-8"?>\n
 +
<camServer name="ucamcomp" version="2.182">\n
  
* ausvs.so.0 - a not quite finished [[Videre Design stereo camera plug-in]]
+
where “\n” is a “newline character (&#10;) - all commands and replies are terminated with a newline (handy when decoding commands and when debugging).
* aumapobst.so.0 - converts near map lines to obstacle polygons [[Mapped obstacles]]
+
(version 2.920)
+
  
== Installation notes==
+
The client will reply with a similar sequence, something like:
  
===Installation without FIREWIRE===
+
<?xml version="1.0" encoding="UTF-8"?>
 +
<marg name="paroll client" version="1267">
  
If you do hat have (and should not use) firewire, then the AURS can be compiled by changing two of the Makefiles:
+
This is mandatory to comply with the XML standard (open a “document”).
  
library ucam4 (in subdirectory ucam4):
+
At the end of the communication there should be a matching close tag:
  
In the Makefile change the DEFINES line from
+
</marg>\n    from MARG
DEFINES = -D USE_IEEE1394
+
or
to
+
  </camServer>\n    from the camera server
  DEFINES = -D USE_NO_IEEE1394
+
  
And the cameraserver (in directory ucamserver)
+
This “end of document” tag has never been mandatory in either MARG nor in our MOBOTWARE servers.
  
In the Makefile change the DEFINE line from
+
===Value exchange===
DEFINES = -D USE_IEEE1394
+
to
+
DEFINES = -D USE_NO_IEEE1394
+
  
and the  LDDFLAGS line from
+
The client has to initiate any data transfer.
LDFLAGS = -g0 -lcxcore -lcv \
+
        -L../lib -lurob4o -lugen4o -lumap4o -lucam4o \
+
        -lpng -ldl -rdynamic -lcurses -lreadline -lraw1394 -ldc1394_control
+
to
+
LDFLAGS = -g0 -lcxcore -lcv \
+
          -L../lib -lurob4o -lugen4o -lumap4o -lucam4o \
+
          -lpng -ldl -rdynamic -lcurses -lreadline
+
  
==Bugs==
+
To get a value of some variable, a data request is send to the server:
  
NEW! BUG reporting page here: [[Change requests]] (if you do not have write access, then send me a mail mailto:jca@elektro.dtu.dk)
+
<var mappose.pose=””/>\n
  
 +
The server will reply in this format:
 +
<var name="odoPose.pose" typ="pose" size="4" value="1.531 -21.912 -2.026 1286376207.8752" x="1.531" y="-21.912" th="-2.026"/>\n
 +
or
 +
<var warning="not found - try: var help" name="odoPose.poser"/>
 +
or (if the command keyword is misspelled or unknown)
 +
<vur warning="Unsupported function keyword"/>
  
==Old stuff==
+
The return tag name (here var) is the same as in the command.
  
===Servers===
+
The important attribute names are:
 +
warning=”” is a general warning to be used if a command can not be executed (other general types are info=”” (debug info) and error=”” (fatal errors).
  
[[Image:Server-structure-1.png]]
+
name=”” is the name of the variable, a “.” indicates that the name prior to the “.” is a structure name, i.e. odoPose is a structure, and pose is a variable name in that structure. Variable names are not case sensitive.
  
[[Server structure]] issues (global variables and methods)
+
typ=”pose” is the type of a variable, relevant types are “d” (a single or array of double), “pose” a 2D pose (x,y,th), “m2” a matrix of doubles (any size), “s” for a string of any size, but ASCII characters – only tested with 7-bit ASCII with escape sequences as allowed by XML.
  
Camera server [[ucamserver]]
+
size=”4” is the size of the value field, either in characters if a string or number of doubles in all other cases.
  
Laser scanner server [[ulmsserver]]
+
Value="1.531 -21.912 -2.026 1286376207.8752" is the value of the variable coded as characters using default C locale, i.e. using “.” as decimal notation (e-notation should be valid too e.g  1.2863762078752e9).
  
Empty server [[userver]]
+
===Full structure===
  
Data monitoring client [[auclient]]
+
An example of request of a full structure could be (camera device info):
 +
<var campool.device0.allcopy=””/>
  
===Static Plug-ins===
+
The server reply is something like:
 +
                                                                                                                         
 +
<var name="campool.device0.name" typ="s" size="26" value="Logitech Pro 3000"/>
 +
<var name="campool.device0.log" typ="d" size="1"  value="0"/>
 +
<var name="campool.device0.replay" typ="d" size="1" value="0"/>
 +
<var name="campool.device0.intrinsic" typ="m2" size="9" value="709 0 320; 0 709 240; 0 0 1"/>
 +
<var name="campool.device0.distortion" typ="m2" size="5" value="-0.207 0.2813 0.0013 0.0036 -0.3"/>
 +
<var info="done"/>
  
Static plug-ins is part of the server code, and can be loaded without any additional files, see:
+
The matrix value uses a “;” to indicate a new row, i.e. the intrinsic matrix above is a 3x3 matrix.
>> module help
+
To get the available list of static plug-ins (and a short description)
+
  
The three [[Coordinate systems]] are available as static: odometry (odoPose), UTM (utmPose) and Map (mapPose)
+
===Set value===
  
===File plug-ins===
+
A value is changed (if allowed) like this:
 +
<var campool.device0.log="1"/>
  
This is a list of the current available plug-ins in release 2.176:
+
Server reply is something like:
 +
<var name="camPool.device0.log" typ="d" size="1" value="1" oldValue="0"/>
  
The intension is that there should be a wiki page for each with further description.
+
The oldValue attribute is just for debug info.
  
* auavoid.so.0 - visual graph obstacle avoidance (not stable)
+
===Get value to another server===
* auballfinder.so.0 - sample blob finder in a camera image
+
* aucamcog.so.0 - a sample center of gravity plug-in for part of a camera image
+
* aucamfocus.so.0 - a focus (contrast) calculation on a camera image.
+
* aucron.so.0 - a module to execute bash commands at regular intervals - e.g. to move logged images at low priority
+
* audrivepos.so.0 - drive control to a specific pose (uses auavoid)
+
* auefline.so.0 - sample line finder plugin extended to find and maintain wall lines. Is based on the libauextractfeatures library.
+
* augps.so.0 - a gps plugin, that maintains an UTM pose from a serial/USB GPS connection
+
* aulmsnear.so.0 - a small function to return the closest point in a laserscan as a <laser l0=0.0 .../> type message
+
* (aumission.so.0 - is now renamed to aurule [[Mission monitor sequencer]])
+
* aurule.so.0 - A rule based mission sequencer - [[Rule based mission sequencer]]
+
** drivebase.rule - The basis for (HAKO) missions - [[Drivebase.rule]]
+
* auroaddrive.so.0 - a drive controller thet follows a road edge (uses auavoid, ausmr and ulmspassable)
+
* auseq.so.0 - deprecated mission sequencer - use aurule.so.0.
+
* ausmr.so.0 - smr interface
+
* ausvs.so.0 - a not quite finished [[Videre Design stereo camera plug-in]]
+
* uexres.so.0 - sample resource share plug-in - works with uexuse
+
* uexuse.so.0 - sample resource share plug-in - works with uexres
+
* ulmspassable.so.0 - extracts road lines from a laserscan (tilted laser)
+
* ulmsv360.so.0 - virtual 360 deg laser scanner device. This is also available as static plug-in for the ulmsserver.
+
* mapbase.so.0 - a base plugin for mapped lines and connected graph of routes
+
* aumapobst.so.0 - converts near map lines to obstacle polygons [[Mapped obstacles]]
+
  
===Plug-in structure and description===
+
When a server is connected to another server, the variables accessible with the VAR command can be transferred from the other server, e.g. the values in the guidemark structure on the camera server to be available in the laser scanner server.
  
[[plug-in structure]]
+
The laser scanner server needs a connection to the camera server, e.g.:
  
[[Variables]] (global variables and functions across plugins)
+
>> module load=if alias=cam
 +
>> cam connect=localhost:24920
  
[[Coordinate systems]]
+
Then to get updated values every time the GMK structure is updated, add this command to the laser scanner server:
  
Scan features (@todo make page)
+
>> cam varpush struct=gmk cmd="var gmk copy"
  
odometry, map or UTM (gps) pose and pose history  [[pose]]
+
This will put the structure and all the variables in the structure in a special structure on the laser scanner server called VAR, i.e. the var directory will now hold a GMK structure (when this is updated in the camera server):
  
Guidemark (@todo make page)
+
>> '''var var.gmk'''
 +
<help subject="var list" name="gmk">
 +
Description:                  new
 +
  imageSerial=11 1021        added
 +
  count=0                    added
 +
  IDs=0                      added
 +
  gmkPose=0 0 0 0 0 0        added
 +
  robPose=0 0 0 0 0 0        added
 +
  gmkcamPose=0 0 0 0 0 0    added
 +
  vertical=1                added
 +
  diagonal=0                added
 +
(H: has time series, L: is logged, R: replay)
 +
</help>
  
Road detect (@todo make page)
+
To get the structure anywhere else (e.g. in the root, as on the camera server) use the destination option:
  
Sequencer [[Sequencer]]
+
>> cam varpush struct=gmk cmd="var gmk copy dest=."
  
SMR interface (@todo make page)
+
The period in the destination (dest=.) marks that it should be placed in the root of the variable system - rather than the special VAR structure.
  
Camera server interface (@todo make page)
+
Note that the description of the variables is not included. To get the description the DESC option will do it:
  
Laser scanner interface (@todo make page)
+
>> cam var gmk copy dest=. desc
 +
<help subject="var list" name="gmk">
 +
Description:                  new
 +
  imageSerial=11 1021        (r) camera number and serial number of image used in
 +
                              search
 +
  count=0                    (r) Number of guidemarks found
 +
  IDs=0                      (r) ID codenumber (in decimal) of the found guidemarks
 +
  gmkPose=0 0 0 0 0 0        (r) pose of first guidemark in robot coordinates
 +
                              (x,y,z,O,P,K) x=forward, y=left z=up [meter], O,P,K
 +
                              [radians] is rotation around the same 3 axes
 +
  robPose=0 0 0 0 0 0        (r) pose of robot seen from first guidemark also
 +
                              (x,y,z,O,P,K)
 +
  gmkcamPose=0 0 0 0 0 0    (r) pose of guidemark in camera coordinates (x,y,z,O,P,K)
 +
  vertical=1                (r/w) expect vertical oriented guidemarks - better
 +
                              performance on diagonal guidemarks if 0
 +
  diagonal=0                (r/w) expect diagonal oriented guidemarks - better
 +
                              performance on vertical guidemarks if 0
 +
  gmk='struct';              new
 +
(H: has time series, L: is logged, R: replay)
 +
</help>
  
Obstacle avoidance (@todo make page)
+
===Server push===
  
Road driver (@todo make page)
+
The server can be requested to send (or process) data in responce to an event.
 +
 
 +
An event can be e.g. a new camera image, an updated image in the image pool, some time passed, update of some structure in the variable tree or an interface is connected.
 +
 
 +
In general the command for server push events includes the keyword "push", like
 +
 
 +
<push t=1.5 cmd="odopose pose"/>
 +
 
 +
This is a time push, and the command (the value of the "cmd" attribute) is send to the server command queue every 1.5 seconds.
 +
 
 +
Other events has typically an interval parameter, like:
 +
 
 +
<poolpush img=19 i=3 cmd="poolget all"/>
 +
 
 +
Then every third time image number 19 in the image pool is updated the image is send to the client.
 +
 
 +
 
 +
===Online help===
 +
 
 +
In mobotware there is on-line help for all commands, i.e.:
 +
Client request for help:
 +
<help/>\n
 +
 
 +
Server reply:
 +
<help subject="server help">
 +
----- Main help:
 +
This is Camera_server-2.182 (Jan 15 2011 16:51:23 jca@oersted.dtu.dk) a server in the AU Robot Server series
 +
running on host pluto port 24920
 +
with 12 modules and 29 ressources.
 +
---
 +
Available commands (from currently loaded modules):
 +
- push q server help shelp module do BASH alive quit exit
 +
- camGet camSet camPush camsGet
 +
- var varPush
 +
- poolGet poolList poolSet poolPush
 +
- odoPose odoPosePush
 +
- utmPose utmPosePush
 +
- mapPose mapPosePush
 +
- laser laserOnConnect
 +
- laserdata laserobst
 +
- cron
 +
- obj3d
 +
- nav navOnConnect
 +
All commands has a help option, e.g.:
 +
server help      Help on server core functions
 +
module help      Module list and addition/removal of modules
 +
q                Close connection to this client by server
 +
(ping [tod=sss.usec] Time difference analysis (TCP only))
 +
---
 +
A command should be packed in XML brackets and must be terminated by a \n (newline)
 +
e.g.:
 +
&lt;module list/>  or if you are lazy just:
 +
module list
 +
---
 +
</help>
 +
<help info="done"/>
 +
 +
The bullet list is the available commands, e.g. the var command is in the same module as varpush.
 +
 +
Then help on the var command from client:
 +
<var help/>
 +
 
 +
Server reply:
 +
<help subject="VAR">
 +
-------------------- Available VAR options:
 +
'variable [variable]*'  Get value of variable(s)
 +
variable="value"        Assign a value to a variable
 +
list                    Get list of variables in root of variable structure
 +
struct                  Get list of all variables in a structure
 +
[struct.]allCopy        Get list of all variables for var pool copy
 +
desc                    Get variable description too
 +
type=T                  semi-structure where T='pose' | '3d' | 'dq' | 's' | 't'
 +
call='me(par1,par2,..)' Test a method call with name 'me' and some parameters
 +
returnType=[lineseg|3d|pose|...] Expected struct result type of call
 +
log[=false]            Open (or close) logfile (open false) /home/chr/chr/results/ucamserver.var.log
 +
log[=false] struct      Start or stop logging of this struct
 +
isLogging  struct      Is this structure beeing logged?
 +
help                    This help message
 +
See also VARPUSH (update event handling)
 +
</help>
 +
<var info="done"/>
 +
 
 +
== Installation notes==
 +
 
 +
=== Raspberry pi camera ===
 +
 
 +
[[Raspberry pi camera servers]]
 +
 
 +
===Installation without FIREWIRE===
 +
 
 +
If you do hat have (and should not use) firewire, then the AURS can be compiled by changing two of the Makefiles:
 +
 
 +
library ucam4 (in subdirectory ucam4):
 +
 
 +
In the Makefile change the DEFINES line from
 +
DEFINES = -D USE_IEEE1394 or -D USE_GUPPY
 +
to
 +
DEFINES = -D USE_NO_IEEE1394 -D USE_NO_GUPPY
 +
 
 +
And the cameraserver (in directory ucamserver)
 +
 
 +
In the Makefile change the DEFINE line from
 +
DEFINES = -D USE_IEEE1394 or -D USE_GUPPY
 +
to
 +
DEFINES = -D USE_NO_IEEE1394 -D USE_NO_GUPPY
 +
 
 +
and the  LDDFLAGS line from
 +
LDFLAGS = -g0 -lcxcore -lcv \
 +
        -L../lib -lurob4o -lugen4o -lumap4o -lucam4o \
 +
        -lpng -ldl -rdynamic -lcurses -lreadline -lraw1394 -ldc1394_control
 +
or
 +
LDFLAGS = -g0 -lcxcore -lcv \
 +
        -L../lib -lurob4o -lugen4o -lumap4o -lucam4o \
 +
        -lpng -ldl -rdynamic -lcurses -lreadline -lraw1394 -ldc1394
 +
to
 +
LDFLAGS = -g0 -lcxcore -lcv \
 +
          -L../lib -lurob4o -lugen4o -lumap4o -lucam4o \
 +
          -lpng -ldl -rdynamic -lcurses -lreadline

Latest revision as of 15:31, 11 February 2020

Contents

[edit] Base Documentation

[edit] Programming API documentation

AU Robot servers (AURC)

AURS class documentation http://aut.elektro.dtu.dk/mobotware/doc/html/classes.html

Open CV

http://docs.opencv.org/

Point Cloud Library

http://pointclouds.org/documentation/

Mobotware Changes for 18.04

[edit] Servers

[edit] Camera server

The camera server - see ucamserver for use details - is pre-configured for camera related functionality.

[edit] Laser scanner server

The laser scanner server - see ulmsserver for details - is optimized for functions using laser scanner data.

[edit] Client for monitoring (auclient)

A data monitoring client auclient is a server pre-configured to display graphics on an x-console. It should be executed on a computer with a screen, i.e. not on the robots.

[edit] General server

An general server userver is intended for functionality not related to camera and laser scanners

[edit] Server stub

A server stub auservertest is a port server that just shows messages from connected clients - with a timestamp. This can e.g. be used to replace the MRC to verify the messages intended for the MRC.

[edit] Modules (plug-ins)

[edit] Descriptions

Not all plug-in modules has a description on these pages (yet).

  • auball - eksamel ball-finder plugin
  • Raspberry Pi camera plugin (aupicam) - works only on Raspberry
  • Crop row follower (robotti) camera plugin - aucroprow2.so.0 - by Aske Bay Jakobsen Crop row finder
  • Time of flight camera - autof.so.0 by Kristian Villien Time of flight camera
  • People detection and tracking - aupplfinder.so.0 by Mikkel Viager People tracker
  • Obstacle avoidance - auavoidk.so.0 Kaspers intuitive method Obstacle Avoidance K
  • Obstacle avoidance (visibility graph) auavoid.so.0 - Obstacle avoidance - visibility graph
  • Rule engine (aurule.so.0) Rule based scripts
  • drivebase.rule - The basis for (HAKO) missions - Drivebase.rule
  • Stereo camera - Videre design device (ausvs.so.0) - Videre Design stereo camera plug-in
  • Kinect camera (aukinect.so.0) - Kinect plug-in
  • Mapped obstacles (aumapobst.so.0) - converts near map lines to obstacle polygons Mapped obstacles
  • Laser obstacles (aulobst.so.0) - make obstacles from laserscan - uses ransac lines Laser obstacles
  • Locater - tree row locater (locater.so.0) - locater - tree row based on laserscan lines and fluffy lines (tree-rows) and line definitions in mapbase.so.0
  • smr - MRC interface (ausmr.so.0) - MRC interface holds some routines to control and interface with the MRC, and a smrctl resource to translate manoeuvres to SMRCL.
  • Vaiable pool (auvar.so.0) is linked staticalli in all servers - use "module load=var". for variables and methods see Variables
  • Pose and pose history is maintained by odoPose, mapPose and utmPose - see Coordinate systems
  • Map (Mapbase) using lines and points - with optional attributes (mapbase.so.0) - a plug-in for mapped lines and connected graph of routes
  • PCL test plugin (aupcltest) requires that pcl version >=1.4 is installed.
  • auv4lgst gstreamer plugin - experimental - gstreamer-plugin
  • auview - a 3D viewer for the auclient, shown pointclouds and most of the features that the audisp can show in 2D.
  • audisp - 2D (top view) display of robot, sensor data (e.g. laserscans) an path history.

@todo document these:

  • Stereo (aimed for 2 aligned cameras supported by ucamserver) (austereo.so.0) - uses openCV stereo library.
  • Slow task scheduler (aucron.so.0) - a module to execute bash commands at regular intervals - e.g. to move logged images at low priority
  • Drive control to a specific pose (audrivepos.so.0) - uses auavoid plug-in to find path to pose.
  • Roaddrive - a drive controller thet follows a road edge (auroaddrive.so.0) - uses auavoid, ausmr and ulmspassable for path planning.
  • Line finder plug-in to find and maintain wall lines (auefline.so.0). Is based on the libauextractfeatures library.
  • Gps plug-in (augps.so.0) - maintains an UTM pose from a serial/USB GPS (NMEA) connection.
  • aulmsnear.so.0 - a small function to return the closest point in a laserscan as a <laser l0=0.0 .../> type message
  • ulmspassable.so.0 - extracts road lines from a laserscan (tilted laser) and holds a database of detected obstacles.
  • Virtual 360 deg laser scanner device (ulmsv360.so.0). This is also available as static plug-in for the ulmsserver (module load=v360).
  • auseq - deprecated sequencer plug-in

[edit] Coordinate systems

The three Coordinate systems are available as static: odometry (odoPose), UTM (utmPose) and Map (mapPose)

[edit] How to make a plugin

plug-in structure

[edit] Variables and functions

Variables (global variables and functions across plugins)

[edit] Replay functionality

A data interface can often be logged, and a replay of the interface may then be beneficial for analysis and debugging.

AURS has a replay facility, see Replay

[edit] Interface description

MOBOTWARE is a set of socket servers, each server has 1 port and allows up to 10 simultaneous clients (port numbers used are from 24919 to 24930).

XML consist of tags and text, a tag is in brackets “<” and “>” and may be split into an open tag and a close tag, with some text imbetween e.g. <tagname> some tekst </tagname>. The open tag may have attributes and may have an implicit close tag (named a full tag), e.g.: <tagname info=”low on power” device=”gps”/>. Attributes must have a value, the value must be in quotes (or apostrophes).

[edit] Connect

When a client connects to a server the server sends an XML opening sequence of XML tags – something like:

<?xml version="1.0" encoding="UTF-8"?>\n
<camServer name="ucamcomp" version="2.182">\n

where “\n” is a “newline character ( ) - all commands and replies are terminated with a newline (handy when decoding commands and when debugging).

The client will reply with a similar sequence, something like:

<?xml version="1.0" encoding="UTF-8"?>
<marg name="paroll client" version="1267">

This is mandatory to comply with the XML standard (open a “document”).

At the end of the communication there should be a matching close tag:

</marg>\n     from MARG

or

</camServer>\n    from the camera server

This “end of document” tag has never been mandatory in either MARG nor in our MOBOTWARE servers.

[edit] Value exchange

The client has to initiate any data transfer.

To get a value of some variable, a data request is send to the server:

<var mappose.pose=””/>\n

The server will reply in this format:

<var name="odoPose.pose" typ="pose" size="4" value="1.531 -21.912 -2.026 1286376207.8752" x="1.531" y="-21.912" th="-2.026"/>\n

or

<var warning="not found - try: var help" name="odoPose.poser"/>

or (if the command keyword is misspelled or unknown)

<vur warning="Unsupported function keyword"/>

The return tag name (here var) is the same as in the command.

The important attribute names are: warning=”” is a general warning to be used if a command can not be executed (other general types are info=”” (debug info) and error=”” (fatal errors).

name=”” is the name of the variable, a “.” indicates that the name prior to the “.” is a structure name, i.e. odoPose is a structure, and pose is a variable name in that structure. Variable names are not case sensitive.

typ=”pose” is the type of a variable, relevant types are “d” (a single or array of double), “pose” a 2D pose (x,y,th), “m2” a matrix of doubles (any size), “s” for a string of any size, but ASCII characters – only tested with 7-bit ASCII with escape sequences as allowed by XML.

size=”4” is the size of the value field, either in characters if a string or number of doubles in all other cases.

Value="1.531 -21.912 -2.026 1286376207.8752" is the value of the variable coded as characters using default C locale, i.e. using “.” as decimal notation (e-notation should be valid too e.g 1.2863762078752e9).

[edit] Full structure

An example of request of a full structure could be (camera device info):

<var campool.device0.allcopy=””/>

The server reply is something like:

<var name="campool.device0.name" typ="s" size="26" value="Logitech Pro 3000"/>
<var name="campool.device0.log" typ="d" size="1"  value="0"/>
<var name="campool.device0.replay" typ="d" size="1" value="0"/>
<var name="campool.device0.intrinsic" typ="m2" size="9" value="709 0 320; 0 709 240; 0 0 1"/>
<var name="campool.device0.distortion" typ="m2" size="5" value="-0.207 0.2813 0.0013 0.0036 -0.3"/>
<var info="done"/>

The matrix value uses a “;” to indicate a new row, i.e. the intrinsic matrix above is a 3x3 matrix.

[edit] Set value

A value is changed (if allowed) like this:

<var campool.device0.log="1"/>

Server reply is something like:

<var name="camPool.device0.log" typ="d" size="1" value="1" oldValue="0"/>

The oldValue attribute is just for debug info.

[edit] Get value to another server

When a server is connected to another server, the variables accessible with the VAR command can be transferred from the other server, e.g. the values in the guidemark structure on the camera server to be available in the laser scanner server.

The laser scanner server needs a connection to the camera server, e.g.:

>> module load=if alias=cam
>> cam connect=localhost:24920

Then to get updated values every time the GMK structure is updated, add this command to the laser scanner server:

>> cam varpush struct=gmk cmd="var gmk copy"

This will put the structure and all the variables in the structure in a special structure on the laser scanner server called VAR, i.e. the var directory will now hold a GMK structure (when this is updated in the camera server):

>> var var.gmk
<help subject="var list" name="gmk">
Description:                  new
  imageSerial=11 1021        added
  count=0                    added
  IDs=0                      added
  gmkPose=0 0 0 0 0 0        added
  robPose=0 0 0 0 0 0        added
  gmkcamPose=0 0 0 0 0 0     added
  vertical=1                 added
  diagonal=0                 added
(H: has time series, L: is logged, R: replay)
</help>

To get the structure anywhere else (e.g. in the root, as on the camera server) use the destination option:

>> cam varpush struct=gmk cmd="var gmk copy dest=."

The period in the destination (dest=.) marks that it should be placed in the root of the variable system - rather than the special VAR structure.

Note that the description of the variables is not included. To get the description the DESC option will do it:

>> cam var gmk copy dest=. desc
<help subject="var list" name="gmk">
Description:                  new
  imageSerial=11 1021        (r) camera number and serial number of image used in
                             search
  count=0                    (r) Number of guidemarks found
  IDs=0                      (r) ID codenumber (in decimal) of the found guidemarks
  gmkPose=0 0 0 0 0 0        (r) pose of first guidemark in robot coordinates
                             (x,y,z,O,P,K) x=forward, y=left z=up [meter], O,P,K
                             [radians] is rotation around the same 3 axes
  robPose=0 0 0 0 0 0        (r) pose of robot seen from first guidemark also
                             (x,y,z,O,P,K)
  gmkcamPose=0 0 0 0 0 0     (r) pose of guidemark in camera coordinates (x,y,z,O,P,K)
  vertical=1                 (r/w) expect vertical oriented guidemarks - better
                             performance on diagonal guidemarks if 0
  diagonal=0                 (r/w) expect diagonal oriented guidemarks - better
                             performance on vertical guidemarks if 0
  gmk='struct';              new
(H: has time series, L: is logged, R: replay)
</help>

[edit] Server push

The server can be requested to send (or process) data in responce to an event.

An event can be e.g. a new camera image, an updated image in the image pool, some time passed, update of some structure in the variable tree or an interface is connected.

In general the command for server push events includes the keyword "push", like

<push t=1.5 cmd="odopose pose"/>

This is a time push, and the command (the value of the "cmd" attribute) is send to the server command queue every 1.5 seconds.

Other events has typically an interval parameter, like:

<poolpush img=19 i=3 cmd="poolget all"/>

Then every third time image number 19 in the image pool is updated the image is send to the client.


[edit] Online help

In mobotware there is on-line help for all commands, i.e.: Client request for help:

<help/>\n

Server reply:

<help subject="server help">
----- Main help:
This is Camera_server-2.182 (Jan 15 2011 16:51:23 jca@oersted.dtu.dk) a server in the AU Robot Server series
running on host pluto port 24920
with 12 modules and 29 ressources.
---
Available commands (from currently loaded modules):
- push q server help shelp module do BASH alive quit exit
- camGet camSet camPush camsGet
- var varPush
- poolGet poolList poolSet poolPush
- odoPose odoPosePush
- utmPose utmPosePush
- mapPose mapPosePush
- laser laserOnConnect
- laserdata laserobst
- cron
- obj3d
- nav navOnConnect
All commands has a help option, e.g.:
server help       Help on server core functions
module help       Module list and addition/removal of modules
q                 Close connection to this client by server
(ping [tod=sss.usec] Time difference analysis (TCP only))
---
A command should be packed in XML brackets and must be terminated by a \n (newline)
e.g.:
<module list/>   or if you are lazy just:
module list
---
</help>
<help info="done"/>

The bullet list is the available commands, e.g. the var command is in the same module as varpush.

Then help on the var command from client:

<var help/>

Server reply:

<help subject="VAR">
-------------------- Available VAR options:
'variable [variable]*'  Get value of variable(s)
variable="value"        Assign a value to a variable
list                    Get list of variables in root of variable structure
struct                  Get list of all variables in a structure
[struct.]allCopy        Get list of all variables for var pool copy
desc                    Get variable description too
type=T                  semi-structure where T='pose' | '3d' | 'dq' | 's' | 't'
call='me(par1,par2,..)' Test a method call with name 'me' and some parameters
returnType=[lineseg|3d|pose|...] Expected struct result type of call
log[=false]             Open (or close) logfile (open false) /home/chr/chr/results/ucamserver.var.log
log[=false] struct      Start or stop logging of this struct
isLogging   struct      Is this structure beeing logged?
help                    This help message
See also VARPUSH (update event handling)
</help>
<var info="done"/>

[edit] Installation notes

[edit] Raspberry pi camera

Raspberry pi camera servers

[edit] Installation without FIREWIRE

If you do hat have (and should not use) firewire, then the AURS can be compiled by changing two of the Makefiles:

library ucam4 (in subdirectory ucam4):

In the Makefile change the DEFINES line from

DEFINES = -D USE_IEEE1394 or -D USE_GUPPY

to

DEFINES = -D USE_NO_IEEE1394 -D USE_NO_GUPPY

And the cameraserver (in directory ucamserver)

In the Makefile change the DEFINE line from

DEFINES = -D USE_IEEE1394 or -D USE_GUPPY

to

DEFINES = -D USE_NO_IEEE1394 -D USE_NO_GUPPY

and the LDDFLAGS line from

LDFLAGS = -g0 -lcxcore -lcv \
        -L../lib -lurob4o -lugen4o -lumap4o -lucam4o \
        -lpng -ldl -rdynamic -lcurses -lreadline -lraw1394 -ldc1394_control

or

LDFLAGS = -g0 -lcxcore -lcv \
        -L../lib -lurob4o -lugen4o -lumap4o -lucam4o \
        -lpng -ldl -rdynamic -lcurses -lreadline -lraw1394 -ldc1394

to

LDFLAGS = -g0 -lcxcore -lcv \
         -L../lib -lurob4o -lugen4o -lumap4o -lucam4o \
         -lpng -ldl -rdynamic -lcurses -lreadline
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox