2008-09-29T11:03:51Z

Lvm: New page: Three static modules are available to maintain and service coordinate systems: * odoPose intended for odometry pose as maintained from MRC (smrdemo) * mapPose intended for a map coordinat...

Three static modules are available to maintain and service coordinate systems:

* odoPose intended for odometry pose as maintained from MRC (smrdemo)
* mapPose intended for a map coordinate system, e.g. oriented as a room, building or area coordinate reference
* utmPose intended to be maintained from a GPS and possibly backed by localization from known map positions in UTM coordinates.

To add a module see (e.g. from the server window or in a script)
module help
To add all three coordinate system modules:
module add=mappose
module add=odoPose
module add=utmPose

'''Main function of pose information'''

The pose is information of robot position in som coordinate system at a point in time. The module stores a number of updates (currently 2000) and holds functions to maintain, query and do some calculations on this stack of positions.
Update of the pose can trigger an event, that can be used to trigger some action, e.g. a sensor fusion update or transfer of pose to another server.

A few parameters determine if an update is stored as an update, determined on the movement and the time since last stored update. Default values are (if not changed):

minDist = 0.03 // Adding update to history if distance is more than this
minTurn = 1.0 * M_PI / 180.0 // Adding update to history if turned more than this (1 degree)
minTime = 10.0 // Adding update to history if time passed is more than this

If either of these limitations are exceeded, then the new update is added to the update buffer. This means that if the distance criteria is the limiting criteria, then there could be 2000*0.03 = 60m of valid poses in the history buffer.

The history buffer can be used to determine
* pose at a specific time (often used to determine pose at the time of some sensor data.)
* pose at a distance from current position - e.g. 5m from current position, calculated as direct distance, not traveled distance.
* Direct iteration into stored values.

These functions are usually used directly using C++ calls to this resource.

A number of global available values are maintained, such as the distance traveled. These are primarily intended to be used by a mission scheduler, as trip counter and time passed functions. See e.g.:

var mapPose

to get an overview of available global values available.

'''How to use (one of) the pose modules from your own plug-in'''

You can get access to the pose module using a resource pointer. The procedure is the same
if you need it in an interface part of the plug-in or in a resource.

Create a pointer in the class definition to the common type UResPoseHist, e.g.:

#include <urob4/uresposehist.h>
...
protected:
UResPoseHist * mapPose;

This mapPose pointer needs to be initialized to NULL in the class constructor, as this usually is used as an indication of an invalid resource. e.g.:

UResYourClass::UResYourClass()
{
setResID(getResID());
resVersion = getResVersion();
mapPose = NULL;
}

The server core will tell you about available resources - and changes in the resource situation, this is done with a call to the function setResource(UResBase * resource, bool remove), and if your program should listen to this call, to get the correct pointer, i.e. to get the mapPose pointer:

bool UResYourClass::setResource(UResBase * resource, bool remove)
{
bool result = true;
if (resource->isA(UResPoseHist::getMapPoseID())) // *note
{ // ressource may be deleted or change
if (remove)
mapPose = NULL;
else if (mapPose != resource)
mapPose = (UResPoseHist *)resource;
else
result = false; // the resource is not neded by this class
}
// the base class may need the resource
result &= UResVarPool::setResource(resource, remove);
return result; // used or not
}

*note: The other alternatives are: UResPoseHist::getOdoPoseID() and UResPoseHist::getUtmPoseID() for the other coordinate systems.

Now the resource pointer is in place, ready for use.

'''Update with new positions'''

The main assumption is that one plugin maintains the pose and one or more other plugins (or the mission sequencer) uses the information.

To update the mapPose plugin, just provide a pose and the time when the pose is valid

UPoseTime pt; // structure with x, y, h and time
UTime t; // just time in linux time format (seconds since 1 jan 1970)
//
t.now(); // set time from linux clock
pt.set(xPosition, yPosition, headingInRadians); // set some pose
pt.t = t; // add the time
mapPose->addIfNeeded(pt, 0.0, -12); // add the new pose (if needed)

The call to addIfNeeded(...) has three parameters, the first is the pose, the second is an optional speed (not essential), the last is a number used to identify the updater - negative numbers are an update from a plugin, a positive number is a TCP/IP client.
This number is available to ease debugging in the help text:

mapPose help

'''Use the resource pointer to get a pose'''

To get a pose will normally use getPoseAtTime(UTime atTime), like:

UPose pose;
UTime t;
//
t.now();
pose = mapPose->getPoseAtTime(t);

See the class documentation for UResPoseHist for other available methods and values.

[[Image:odoPose-update-rev2.png]]

AU Robot Servers

2008-09-29T11:03:03Z

Lvm: /* Plug-in structure and description */

==Documentation of AU robot servers==

[[Image:Server-structure-1.png]]

AU Robot Servers is a software infrastructure that can combine a number of functional modules to a robot with functionality at a the higher abstraction levels. Yellow boxes are the currently available servers in this structure.

==Download and bug reporting==

For package and install notes see: [Christian's Wiki Page] - no, that page is now used by others for other purposes, but in summary the released versions are here: http://www.iau.dtu.dk/~jca/rac/releases

and a few comments for the releases in [[Release notes]]

CVS updated to version ~2.01 (19 may 2008)

NEW! BUG reporting page here: [[Change requests]]

Doxygen documentation http://www.iau.dtu.dk/~jca/rac/html/index.html

==Servers==

[Server structure] issues (global variables and methods)

Camera server [[ucamserver]]

Laser scanner server [[ulmsserver]]

Empty server [userver]

Data monitoring client [auclient]

==Static Plug-ins==

Static plug-ins is part of the server code, and can be loaded without any additional files, see:
>> 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)

==File plug-ins==

This is a list of the current available plug-ins in release 2.01:

The intension is that there should be a wiki page for each with further description.

* auavoid.so.0 - visual graph obstacle avoidance (not stable)
* 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 - the new - but not finished - [[Mission monitor sequencer]]
* auroaddrive.so.0 - a drive controller thet follows a road edge (uses auavoid, ausmr and ulmspassable)
* auseq.so.0 - mission sequencer - much like smrcl, but using variables and functions provided by the AU Robot servers - is to be replaced by aumission.so.0 once this is operational.
* 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.

==Plug-in structure and description==

[plug-in structure]

[Variables] (global variables and functions across plugins)

[[Coordinate systems]]

Scan features (@todo make page)

odometry, map or UTM (gps) pose and pose history [[pose]]

Guidemark (@todo make page)

Road detect (@todo make page)

Sequencer [[Sequencer]]

SMR interface (@todo make page)

Camera server interface (@todo make page)

Laser scanner interface (@todo make page)

Obstacle avoidance (@todo make page)

Road driver (@todo make page)

Sequencer

2008-09-29T10:48:35Z

Lvm: New page: ''Status'' The sequencer is in broad terms equal the the sequencer in smrdemo, but is less real time oriented ''How to operate'' Load the module 'auseq-1.XX.so.0' by e.g.: The module re...

''Status''

The sequencer is in broad terms equal the the sequencer in smrdemo, but is less real time oriented

''How to operate''

Load the module 'auseq-1.XX.so.0' by e.g.:
The module requires the variable handling module to be loaded too, so load both.
>> module load='/usr/local/smr/bin/auseq-1.77.so.0'
>> module load=var
The variable handling module is static - and can thus be loaded using a short name - see '>> module help' for a list of static modules.

Look at:
>> seq help
to get sequencer options, then try to add a sequencer line by e.g.:
>> seq add="a=sin(0.5)"
USeqLoop::run: 0 Parsing 'a=sin(0.5)'
USeqLoop::run: ** 1 warning: sequencer out of mission lines (try "seq help")
The sequenser reply is that the line is parsed and it now is out of sequence lines

All variables and functions available to the sequencer can be displayed with the command:
>> var all
false=0; Constant false is the same as 0
true=1; Constant true is the same as 1
pi=3.14159; Constant pi is the same as 3.14159...
replayTime=0; Current time index to replay file(s)
a=0.479426; new
core='struct'; Variables related to the server core.
poseHist='struct'; Holds the most recent robot position and the
seq='struct'; Plan sequencer settings and status
roaddrive='struct'; Road line driver settings and functions
drivepos='struct'; Drive to position settings and functions
limitToPi(d);
sin(d);
cos(d);
...
And among the list is the new variable 'a' introduced by the sequencer line.

Some modules introduce drive commands, the 'drivepos' module allow to drive to a position, in local or absolute coordinates
To try it, first load the module
>> module load="/usr/local/smr/bin/audrivepos-1.77.so.0"
To see the settings and functions in this plugin, try:
>> var drivepos
version=1.77; Resource version
updateTime=0; Last time the road drive command was calles
loopCnt=0; Number of times called by sequencer
odoX=0; (ro) target position used in obstacle avoidance
(set by call)
odoY=0;
odoH=0;
odoV=1; target velocity at end of obstacle avoidance
failCnt=0; Path fails since last success
finalDistance=0.7; Distance from target position where no new path
is calculated
odo(ddd); Drive towards this odometry position (x[m],
y[m], h[rad])
odo(dddd); Drive towards this odometry position (x[m],
y[m], h[rad]), the last (optional) parameter is
a repeat count for calls in rapid succession.
rel(ddd); Drive towards this position relative to the
robot (x[m], y[m], h[rad])
rel(dddd); Drive towards this position relative to the
robot (x[m], y[m], h[rad]), the last (optional)
parameter is a repeat count for calls in rapid
succession. First call (repeat==0) determines
origin for relative position
odoVel(dddd); Drive towards this odometry position and desired
end velocity (x, y, h, vel)

To add a line that will drive to a position 1 meter forward and 0.5 meter to the right maintaining the current heading, try:
>> seq add="drivepos.odo(1, -0.5, 0) : false"
The first part is a function call the the 'odo(ddd)' function in the 'drivepos' module with the 3 needed 'double' parameters. Then a ':' to say that it is a drive command that should be continued until it returnes 'true' or the explicit stop condition after the ':' evaluates to true.

Then a failure remark is most likely returned, this is because the drive module depends on other modules to complete the command

@todo more info needed

AU Robot Servers

2008-09-29T10:47:57Z

Lvm: /* Plug-in structure and description */

==Documentation of AU robot servers==

[[Image:Server-structure-1.png]]

AU Robot Servers is a software infrastructure that can combine a number of functional modules to a robot with functionality at a the higher abstraction levels. Yellow boxes are the currently available servers in this structure.

==Download and bug reporting==

For package and install notes see: [Christian's Wiki Page] - no, that page is now used by others for other purposes, but in summary the released versions are here: http://www.iau.dtu.dk/~jca/rac/releases

and a few comments for the releases in [[Release notes]]

CVS updated to version ~2.01 (19 may 2008)

NEW! BUG reporting page here: [[Change requests]]

Doxygen documentation http://www.iau.dtu.dk/~jca/rac/html/index.html

==Servers==

[Server structure] issues (global variables and methods)

Camera server [[ucamserver]]

Laser scanner server [[ulmsserver]]

Empty server [userver]

Data monitoring client [auclient]

==Static Plug-ins==

Static plug-ins is part of the server code, and can be loaded without any additional files, see:
>> 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)

==File plug-ins==

This is a list of the current available plug-ins in release 2.01:

The intension is that there should be a wiki page for each with further description.

* auavoid.so.0 - visual graph obstacle avoidance (not stable)
* 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 - the new - but not finished - [[Mission monitor sequencer]]
* auroaddrive.so.0 - a drive controller thet follows a road edge (uses auavoid, ausmr and ulmspassable)
* auseq.so.0 - mission sequencer - much like smrcl, but using variables and functions provided by the AU Robot servers - is to be replaced by aumission.so.0 once this is operational.
* 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.

==Plug-in structure and description==

[plug-in structure]

[Variables] (global variables and functions across plugins)

[[Coordinate systems]]

Scan features (@todo make page)

odometry, map or UTM (gps) pose and pose history [pose]

Guidemark (@todo make page)

Road detect (@todo make page)

Sequencer [[Sequencer]]

SMR interface (@todo make page)

Camera server interface (@todo make page)

Laser scanner interface (@todo make page)

Obstacle avoidance (@todo make page)

Road driver (@todo make page)

MMR

2008-09-29T10:45:32Z

Lvm: New page: This page holds information relevant for the Natty Bumpo robot. '''make video from images''' 1. Convert to filenames with sequential numbers and a supported image formap (e.g. png) 2. r...

This page holds information relevant for the Natty Bumpo robot.

'''make video from images'''

1. Convert to filenames with sequential numbers and a supported image formap (e.g. png)

2. run ffmpeg with appropriate options

A script to do so could be:
#! /bin/bash
let COUNTER=1000000
for f in $( ls *.bmp ); do
echo convert $f path$COUNTER.png
convert $f path$COUNTER.png
let PREV=$COUNTER
let COUNTER+=1
done
# convert to mpeg format
# -r 25 frames per second
# -b 5000000 bitrate på 5Mbit/sec
# -y betyder overskriv destination
ffmpeg -y -r 25 -b 5000000 -i path1%06d.png path.mpeg
ls -l path.mpeg

----
'''Natty Bumpo – demo instructions (short version)'''

''Assumptions:''

Near AU, i.e. Wireless network running (if not: reboot to set default gateway).

(old mmrd version of software - pre 2007)

--

Using acer PC for control (boot with linux).

Acer PC is connected with twisted network cable to Natty. Natty has IP 10.0.2.116,
Acer is assumed to have IP 10.0.2.1. (IP is set on acer in /etc/rc.d/rc.inet1.conf:
IPADDR[0]=”10.0.2.1”
USE_DHCP[0]=”no”
NETMASK[0]=”255.255.255.0”.

LMSserver and gpsserver must be running – check with ps -A. If not then start manually from a ssh session (no parameters required). SMRDEMO, UCAMSERVER and MMRD should be started manually, e.g.:

ssh demo@smr16 # and password
cd /rhome/demo/bin
./smrdemo -t1 # smrdemo opens port 31001

ssh demo@smr16
cd bin
./ucamserver -t "path gmk" --imagepath="/mnt/ram" # camera server opens port 24920

And the navigation server currently called mmrd

ssh demo@smr16
cd bin
./mmrd -i /mnt/ram # drive planner opens port 24922

--

''On acer: for mission control and monitoring''

Find the graphical control application (based on openCV):
./uclient # is in /usr/local/smr/bin on "nyquist" and "jensen"

Connect to smr16 (session3) port 24922

>> connect smr16 24922
>> connected ...

To watch status image (getting laser scan and other info every 1 sec).

>> push cmd=”get all” # major variable values
>> push cmd=”obstget” # obstacles
>> push cmd=”planget status” # gets current command line (etc)
>> push cmd=”scanget andall” # gets the laser scan and result of path finding (etc)

Run a mission e.g. Down the hall (25 meter on the left side):
>> planset goto=”fwd left 25”
Set (max) speed (to 0.9 m/s) – current speed is shown on status image (top-left):
>> set speed=0.9
Run a script, (look in /rhome/demo/bin/*.mmr) place MMR in hall and try
>> planset load="doors.mmr"
It will drive along left side of hallway (~25m) and stop at all open doors to the right, and return.

For other commands try
>> help
>> shelp

If vision path finding is to be used, then the following parameter must be set:
>> set visPathUse=true
The vision polygon can be seen by a further push command:
>> push cmd="get visPoly"

----
'''FAQ'''

''Tilt of laser scanner does not work.''

The tilt controller can enter a no-operation mode where it needs a reset to resume operation.
Reset can be done through the 'smrd' interface or by hardware action:

Hardware reset of laser scanner tilt controller:

Open plastic box behind the laser scanner (4 screws).
The PCB closest to the laser scanner is the tilt controller board.
The 2-wire (thick gray and orange wires) is the 24 volt supply, unplug this
and reinsert. The tilt function should then find the lower extreme and reset to horizontal position.

If the tilt has passed one of the end-switches, the above reset might fail.
In this case disconnect the two wires to the motor (red and black (red closest to scanner))
- screwed to the end of the controller board - and connect an
external power supply (+/- 2 to 5 volt) to turn the tilt to a normal angle, then try the
reset procedure again.

NB! Do not try to turn the laser scanner by hand - it will damage the axle.

''Module will not load -- symbol not found''

If the server is not compiled with the same library as the module, there may be "symbol not found" errors.
The solution is to recompile their server with the same library as the modules (or vise versa).

----
'''Robot documentation'''

Documentation by Malte and Anders is on kalman:/vhome/ ... ?

''hardware''

1.2 GHz Via C2 processor with 512 MByte RAM.

----
'''Serial IO'''

The following devices are used:

/dev/ttyUSB0 // Laser scanner using USB/serial device
/dev/ttyS4 // symbolic link for old laser scanner server
/dev/ttyUSB1 // gps receiver
/dev/ttyACM0 // Small laser scanner (URG)
/dev/ttyS1 // used by smrd for RS485 interface

With kernel version 2.6.17, these are not the devices created by UDEV, they are now all in /dev/tts/*.

The com1 and com2 ports are swapped relative to ordinary SMRs, to correct for this the devices in the mmr are cross-linked in /etc/rc.d/rc.local as follows:

rm /dev/ttyS0
rm /dev/ttyS1
ln -s /dev/tts/1 /dev/ttyS0
ln -s /dev/tts/0 /dev/ttyS1

Further the devices /dev/tts/USB0 and /dev/tts/USB1 may be swapped after a reboot,
to solve for this issue the devices are mapped to /dev/ttyUSB0 for gps and /dev/ttyUSB1 for SICK
This is done in /etc/rc.d/rc.local using:

if udevinfo -a -p /class/tty/ttyUSB0 | grep 'DRIVER=="pl2303"'; then
echo USB0 is GPS, USB1 is SICK
# direct ttyUSB0 to tts/USB0 as it is the gps connection
ln -s /dev/tts/USB0 /dev/ttyUSB0
# direct ttyS4 to tts/USB1 as it is the SICK laserscanner
ln -s /dev/tts/USB1 /dev/ttyS4
ln -s /dev/tts/USB1 /dev/ttyUSB1
else
echo USB0 is SICK, USB1 is GPS
# direct ttyUSB0 to tts/USB1 as it is the gps connection
ln -s /dev/tts/USB1 /dev/ttyUSB0
# direct ttyS4 and ttyUSB1 to tts/USB0 as it is the SICK laserscanner
ln -s /dev/tts/USB0 /dev/ttyS4
ln -s /dev/tts/USB0 /dev/ttyUSB1
fi

----
'''RAM disk'''

A RAM disk is mounted at
/mnt/ram
with write access for all. Remember all content are lost after a reboot.
The RAM-disk takes RAM as needed up to a maximum of 300 MByte.

The ram disk size is defined in with the other disk definitions
/etc/fstab
with the line
tmpfs /mnt/ram tmpfs size=300m 0 0

The ram-disk is intended for temporary data (logging), that can be used in areas, where no network connection is available or as a fast logging device. These data can then later be copied to a more permanent place - if needed.
----
'''Flash disk'''

An user area is created on the flash disk for more permanent files at
/rhome
Please make a home directory using your initials or project number. e.g. like:
/rhome/ex39
There is limited space on the flash disk - p.t. approx 150 MByte.
(Check disk space with the 'df' command).

----

Main Page

2008-09-29T10:44:49Z

Lvm: /* Robots */

Wellcome to the wiki pages of the Robot Systems Engineering (RSE) group at Institute for Automation, DTU Electical engineering.

These pages will contain updated information on RSE projects and other issued related to robotics research at the Institute for Automation.

= RSE Projects =
[[AU Robot Servers]], download and documentation

[[RHD]] Robot Hardware Daemon

[[Robot sensor modules]], description and documentation

[[Simulation]], description of simulation environments

= Robots =

[[SMR]] (Small Mobile Robot)

[[MMR]] (Medium Mobile Robot)

= How-to documentation =

[[NTP howto]] time-sync 2 computers

Using the [[RSE SVN]] repository

SMR [[Wiring and assembly]]

SMR [[Flash disk cloning]]

[[RoboCup]]

Ucamserver

2008-09-29T10:40:10Z

Lvm:

''' Camera server'''

Intended for image handling functions.

[[Image:cam-server2.png]]

The following camera-related plug-ins are available:
* Camera control (camget, camset etc)
* Image access (imageget, imageset) access to fresh images.
* Image pool handling (poolget poollist etc.) pool of imege buffers with image handling functionality.
* Guidemark detection (gmkget) giudemark 3D pose and code
* Road outline plugin (pathget) polygon with road outline matching a seed area.
* Sample plugin (center of gravity)

The following cameras are supported:
* all USB cameras supported by the pwc (Philips Web Cam) driver, e.g.
* - Philips 740K, 840K,
* - Logitech Orbit
* A few frame-grapper cards (I have not tried for a long time)
* IEEE1394 DCI-standard
* IEEE1394 DVI - not supported
* palantir streaming video - not supported p.t.

To run the server

./ucamserver

It then shows a command prompt:

>>

To monitor images and results use the monitoring client UCLIENT or AUCLIENT (or the server console directly - or as a last resort TELNET)

See:

>> module list

For further command keywords, and then try the command keyword followed by 'help', like:

>> camset help

File:Cam-server2.png

2008-09-29T10:39:41Z

Lvm:

Ucamserver

2008-09-29T10:38:30Z

Lvm:

''' Camera server'''

Intended for image handling functions.

[http://www.iau.dtu.dk/~jca/rac/cam-server2.png]
[[Image:cam-server2.png]]

The following camera-related plug-ins are available:
* Camera control (camget, camset etc)
* Image access (imageget, imageset) access to fresh images.
* Image pool handling (poolget poollist etc.) pool of imege buffers with image handling functionality.
* Guidemark detection (gmkget) giudemark 3D pose and code
* Road outline plugin (pathget) polygon with road outline matching a seed area.
* Sample plugin (center of gravity)

The following cameras are supported:
* all USB cameras supported by the pwc (Philips Web Cam) driver, e.g.
* - Philips 740K, 840K,
* - Logitech Orbit
* A few frame-grapper cards (I have not tried for a long time)
* IEEE1394 DCI-standard
* IEEE1394 DVI - not supported
* palantir streaming video - not supported p.t.

To run the server

./ucamserver

It then shows a command prompt:

>>

To monitor images and results use the monitoring client UCLIENT or AUCLIENT (or the server console directly - or as a last resort TELNET)

See:

>> module list

For further command keywords, and then try the command keyword followed by 'help', like:

>> camset help