AU Robot Servers: Difference between revisions
(→Bugs) |
|||
Line 300: | Line 300: | ||
-L../lib -lurob4o -lugen4o -lumap4o -lucam4o \ | -L../lib -lurob4o -lugen4o -lumap4o -lucam4o \ | ||
-lpng -ldl -rdynamic -lcurses -lreadline | -lpng -ldl -rdynamic -lcurses -lreadline | ||
Revision as of 17:09, 16 March 2011
Download
The tar ball (packed) versions are here: http://server.elektro.dtu.dk/ftp/jca/mobotware/
and a few comments for the releases in Release notes
Latest version (other than tarball above):
On Nyquist/SMRs: (in /usr/local/smr/) is 2.1353 (as of 12 feb 2011).
On SVN: is version 2.1353 (as of 12 feb 2011).
Base Documentation
Programming API documentation
AU Robot servers (AURC)
AURS class documentation http://server.elektro.dtu.dk/ftp/jca/mobotware/doc/html/index.html
Open CV
OpenCV (1.0) general documentation http://server.elektro.dtu.dk/www/jca/opencv/
OpenCV (1.0) CXCORE documentation http://server.elektro.dtu.dk/www/jca/opencv/ref/opencvref_cxcore.htm
OpenCV (1.0) CV documentation http://server.elektro.dtu.dk/www/jca/opencv/ref/opencvref_cv.htm
Most of the openCV-2.1 is available too: http://opencv.willowgarage.com/documentation/cpp
NB! the highgui part of openCV (capture, file handling and display of images) are not available in a plug-in, that is to run on the robot, as the robot has no X (GUI librarys).
Camera server
The camera server ucamserver is pre-configured for camera related functionality.
Laser scanner server
The laser scanner server ulmsserver is optimized for functions using laser scanner data.
Client for monitoring (auclient)
A data monitoring client auclient is a server pre-configured to display graphics on an x-console. It can be started on computers with X installed, i.e. not on the robots. The auclient uses openCV (highgui) to display the data.
Other servers
An empty server userver is intended for functionality not related to camera and laser scanners
A server stub auservertest is a port server that just shows messages from connected clients - with a timestamp. This can be used to replace the MRC to verify the messages intended for the MRC.
Server module tester uservermoduletester is a special server, where most of the available plug-ins are compiled staticly into the server, and thus available in the >> module help list for direct creation. This server is intended for debug only.
Modules (plug-ins)
Descriptions
Not all plug-in modules has a description on these pages (yet).
- 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 mission sequencer
- drivebase.rule - The basis for (HAKO) missions - Drivebase.rule
- Stereo camera - Videre design device (ausvs.so.0) - Videre Design stereo camera 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.
@todo document these too
- Stereo (aimed for 2 aligned cameras supported by ucamserver) (austereo.so.0) - uses openCV stereo library.
- Obstacle avoidance using visual graph and line-arc planning (auavoid.so.0)
- 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
- ausmr.so.0 - smr interface
- 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).
- Map using lines and points - with optional attributes (mapbase.so.0) - a plug-in for mapped lines and connected graph of routes
Coordinate systems
The three Coordinate systems are available as static: odometry (odoPose), UTM (utmPose) and Map (mapPose)
How to make a plugin
Variables (global variables and functions across plugins)
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
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).
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.
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:
\n
The server will reply in this format:
\n
or
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).
Full structure
An example of request of a full structure could be (camera device info):
The server reply is something like:
The matrix value uses a “;” to indicate a new row, i.e. the intrinsic matrix above is a 3x3 matrix.
Set value
A value is changed (if allowed) like this:
Server reply is something like:
The oldValue attribute is just for debug info.
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.
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:
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>
Installation notes
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