BeeSoft User's Guide and Reference
Chapter 15: The ACCESS.bus and mspterm
Overview: abusd, abusk and mspterm
Some important files to know:
~bee/lib/abusk.o -- The kernel driver
~bee/bin/abusd -- The A.bus daemon/manager
~bee/lib/libabus.a -- The A.bus client library
~bee/include/acb/*.h The A.bus header files
/lib/modules/default/misc -- A symlink to ~bee/lib/abusk.o
Installing abusd and abusk
Be sure that the following line is included in /etc/conf.modules:
alias char-major-28 abusk
Be sure the following lines are included in /etc/rc.d/rc.sysinit:
echo 'Starting abusd'
~bee/bin/abusd -irq [**IRQ**]
Using abusd, abusk and mspterm
There are two parts to the A.b driver system: the kernel module, ~bee/lib/abusk.o, and the daemon, ~bee/bin/abusd
abusd is normally loaded at boot time by /etc/rc.sysinit which causes kerneld to automatically load abusk.o.
To check that abusd is loaded, type:
ps ax | fgrep abusd'
To see if abusk.o is loaded, type:
cat /proc/modules
If it’s loaded, it will be listed. You should also find it by typing:
cat /proc/devices
except here it is called just 'abus'. Additionally, status information can be found in /var/log/messages, the system log.
At this time root permission is not required to run abusd. If at any time it isn't running, you can start it with this command:
~bee/bin/abusd -irq [**IRQ**]
Abusd will not exit if abusk is unable to find the A.b host controller card. You will normally find a message in /var/log/messages from abusk saying that it was unable to find it. If the A.b is locked by any device for any reason, the controller card will appear to not be installed and abusd will continue attempting to connect to the card at 5 second intervals.
If you suspect that the A.b is locked, look at the amber A.b LED. On the B21, this LED is near the bottom of the column of console LEDs, arrayed vertically on the robot’s left console strut. On the B14, the A.b LED is just above the leftmost toggle switch on top of the robot. This LED will be steadily lit (not flickering) if any of the devices has locked up the bus. See the procedure detailed below for clearing a locked bus. Once the bus has been freed, abusd should be able to connect to the card on its next attempt.
With both abusk and abusd loaded you are ready to run mspterm. mspterm uses stderr to print various status information and will make a mess of your screen if stderr it isn't redirected. Also, mspterm uses curses and divides the screen into three sections. The middle debug window isn't really used anymore and just takes up valuable screen space. As a result,
if an tall screen or window is available, it is highly recommended.
You must restart mspterm if you change its window size. So, start it as follows:
mspterm 2> mspterm.log
You may prefer to redirect output to /dev/null instead of a log file. Do not use the tcsh shell, as it will not let you redirect only stderr. Use bash or zsh instead.
General Operation Guidelines
NOTE: mspterm suffers either from a bug within curses, or a programmer's bug. Anytime information is printed in either the device or debug window the location of the cursor in the term window gets messed up. If data is being printed in either of the other windows (as it normally is) it is necessary to type blind because you won't be able to properly see what you are typing until you press enter. Then the typed line will scroll up and you will see what youtyped.
Do not use <CTRL-C> to terminate mspterm. Use the mspterm 'quit'command to exit
or kill it from an other terminal.
The mspterm prompt is:
{xxxx}>
Where xxxx is the number of the default MSP. Each MSP has a set of dip switches to set its number and each must be unique.
Commands are entered as either:
<mspnum> <command> <parameter> <parameter>
or:
<command> <parameter> <parameter>
In the latter case, the default MSP is used. Note that when mspterm is started the default MSP is 0. There is normally no MSP 0, so you will have to specify which one you want.
Normally the MSPs on a B21 are numbered 0x20, 0x21 and 0x22 on the enclosure with 0x20 being located behind the left rear door and controlling the two rear doors. The others are found clockwise from there. The MSPs on the base are normally numbered 0x30, 0x31, 0x32 and 0x33.
NOTE: all numbers in mspterm are hex and the 0x notation is not actually used.
Again, the rear most one is 0x30 and they increase in number in a clockwise direction as viewed from the top.
Messages from MSPs will start with their number.
All intervals on MSPs are in units of 1/150 cycles per second.
Firing the Infrared Sensors
To fire an Infra-red sensor, type:
<msp_number> iri <time_interval>
Example:
20 iri 15
Don’t use a time interval lower than 15. To stop the IR’s, use 0 (zero) as the time interval.
Engaging the Tactile Sensors
Push each bump switch in turn, while someone is reading the returned values from the screen.
Firing the Sonar Sensors
For the sonar to operate properly and not get lots of cross talk and interference, it is important that the firing of sonars be synchronized among all the MSPs with sonar. To accomplish this, sonar operation is done with one MSP acting as a master that directs the operation of the
other MSPs.
The master MSP is the one that has been issued a sonstart command. When issued a sonstart command, the MSP will send a sonparm message to all other MSPs so that they are all using the same parameters. It will then broadcast messages to direct the firing of sonars based on a table that has been given to it. It will remain as master until it receives a sonstop command.
There are a number of sonar parameters that you can set. To see the currently-set parameters for a sonar sensor, type:
xx sonparms
where xx represents MSP number 0x20. This will return the current parameter settings of MSP number 0x20. The only parameter that you are likely to want to change is the firing
interval. To set it type, for example:
sonparms -fi 28
If MSP number 0x20 is already the default MSP, this will set MSP number 0x20's firing interval to 0x28.
In order to fire sonar, you must first set the sonar table. The sonar table consists of a set of sonar transducer numbers as follows:
sontable xxxx xxxx xxxx xxxx : yyyy yyyy yyyy yyyy : zzzz zzzz zzzz zzzz
The set of xxxx's are the transducer number of the transducers to be fired first. After the 'fire interval', the set of yyyy transducers will be fired. Then the set of zzzz transducers are fired and the cycle starts over. Sonar data is reported after each firing and the pace at which they are fired is set by the fire interval.
Typically for normal operation, there are four sets of six transducers where each set consists of one transducer from each of the six doors on a B21. For typical testing you want to fire the transducers one at a time so the table consists of only one transducer number.
A sonar transducer number consists of four digits. The first two digits are the MSP number. Third digit is the sonar chain number. The chains are 0, and 1. Fourth digit is the individual sonar chain address. Sonar chain addresses normally range from 1-4 and never exceed 1-7.
Examples:
sontable 2101
This will set the sonar table to fire MSP #21, the first sonar on the first chain.
sontable 2214
This will set the sonar table to fire MSP #22, the fourth sonar on the second chain.
To start the sonars, type:
sonstart
To stop the sonars, type:
sonstop
Do not change the sonar parameters while the sonar is running. You can, however, change the sonar table. For normal testing operation it is normal to set the fire interval, set the sonar table to the first transducer to be tested and then start the sonars with sonstart. Then to change to the next transducer to be tested, just change the sonar table.
Troubleshooting a Locked A.bus
If you suspect that the A.b is locked, look at the amber A.b LED. On the B21, this LED is near the bottom of the column of console LEDs, arrayed vertically on the robot’s left console strut. On the B14, the A.b LED is just above the leftmost toggle switch on top of the robot. This LED will be steadily lit (not flickering) if any of the devices has locked up the bus.
If you have a lockup, begin by switching off the MSPs on the computer enclosure. If the bus is
still locked, turn off the MSPs on the base by turning off the base. If the locked condition has cleared, then turn the MSPs back on. If the bus is still locked, then the host controller card is the cause, and you’ll have to shutdown Linux and reboot the computer with the reset button.
NOTE: A soft boot won't clear the problem.
Known Problems and Deficiencies
1. The full abus manager protocol is not yet supported. This is only important if you are developing your own abus drivers and devices.
2. The CATC A.bus card occasionally crashes and requires that the host computer be rebooted with a hardware reset or power cycle.
