MARS-mission III


created 23/08/05; last update 08/09/05

Luxembourg Science Festival is approaching, and we will participate again with our Mars-mission tele-robotics project. Some ideas have been launched so far:

New Mars rover realized by Paul-Nicolas Baumann. Some details :

The under-actuated robot-grabber is similar to the one of LEGO truck 8479.

Two RCX must communicate with each other. Since we are using the CMUCam2 and the IR/RF transceiver (from Mars Mission B), the IR-channel may not be used. (The CMUCam2-interface allows IR-serial communication only, if the the camera is powered down.) How to maintain a bi-directional communication between the two RCXs?

Trick: If we connect an RCX output port to an input port that is configured as Boolean switch, and we toggle between the RCX output states "BRAKE" and "FLOAT", we generate the values "0"-float and "1"-brake. The reason is that "brake" mode short-circuits both RCX-output pins with the result of nearly 0Ohm resistance while "float" mode produces a quasi infinite resistance.

With complete system stability, we can securely do 50 baud. Not terrific, but suitable ! Note that the sending Ultimate ROBOLAB program first sends 8 synchronization pulses, then a start bit, followed by the 8 data bits and a final stop bit. Also note that "send_HIGH" and "send_LOW" use a faster output-port access that immediately sets the output port without waiting for the system to do this at the system response time. (Could also simply use a "set motor brake" or "set motor float" function, but more reliability with the fast one.)

Here a test program that counts from 1 to 255, sends the counter-value to the other RCX, displays it and waits for an acknowledgement from the colleague :

The receiving task is constantly waiting for a synchronizing pattern, from which the timing can be deduced. The program waits 1.5 times the period to hit the middle of a bit-sending, where it is supposed to be correctly read. Then at a 1T rate the following 8 bits are read.

The second RCX uses the following program to receive the data and acknowledge a receiving:

This serial communication is only reliable at low speed, because of the complete RCX system running, and no hardware timer being directly engaged to assure hard-timing. But the major issue is the fact that the best reading moment is fixed at each bit by waiting a fixed time with no clock-reference coming from the sender. A better solution will be a future use of the Manchester encoding, where the bit representation changes to transitions rather than states. With the Manchester encoding, each bit can be read at the best moment, since a transition always occurs at the middle of the interval. Note however that for the purpose of this Mars-rover the actual serial communication is sufficient at the given 50baud speed.

Here the connection that is needed to assure the communication.


Problems with the new asynchronous serial communication:

The solution is a synchronous bi-directional clock pulsed communication, where timing imprecision does not affect the transmission. One RCX represents the MASTER, the other one is called the SLAVE. The MASTER initializes a transmission by sending a request pulse, which must be acknowledged by the SLAVE. Then the MASTER provides a clock pulse. At the falling edge the SLAVE sends the data-bits. Just before the next rising edge the MASTER reads the data. This seems to be a very robust system, where small timing differences don't disturb, since the data is sent and read at the MASTER's commands. Under multi-tasking conditions with many tasks running in parallel, there was no problem to obtain 50 baud. The following tests have been made with 25 baud, which is largely sufficient for the purpose.

NOTE that time-out management still is missing. With the test programs, if a wire is cut, the system could hang up. The next version will include time-outs, so there won't be any trouble at all. Also note that both RCXs can initiate a communication and become the MASTER. A SLAVE-wait-for-request "service" must constantly be running in the background. But, once a request sent or received, a semaphore must protect the functions, in order to prevent an RCX to become "MASTER" and "SLAVE" at the same time.


There was one unsatisfying characteristic of the described synchronous communication that causes problems in the applications of the system : the "MASTER" must initialize the transmission ! A better solution would be to have the "SLAVE", which is the sending device, initialize the transmission, because it knows the best, when its data are ready for being sent. Thus, we alter the communication system as follows:

New timing schedule:


Uni-directional test programs:

Bi-directional test-programs:

The uni-directional versions only provide the respective master or slave subroutine or task ! The bi-directional must provide them both.


Here both important sub.vis that are the heart of the synchronous bi-directional communication:

The Mars-rover has been changed a bit: now it is working with the following features:

- 2 RCX

- CMUCam2 color tracking : "find the meteorite mission"

- drive & turn (2 motors, 1 rotation sensor)

- grab and release meteorite (1 potentiometer as angle sensor, 1 touch-sensor as security (if they brought the grabber arm in a bad position)

- bumpers to detect collusion (3 touch sensors)

- IR/RF repeater system (I got the communication working with standard ROBOLAB tower communication sub.vis -needs "suppress error", reduce the retries to 5 and set up an automatic error recovering, so that the system can run autonomously without stopping in the case of a communication error) ; only need to add a 15/100 sec pause between receive and send reply to give the repeater the chance to reset internal states.

- hardwired two-wire bi-directional synchronous communication between both RCX at 50 baud (not famous, but regarded the fact that we have about 10 parallel tasks in both RCXs, this is one of my best programming stuffs.) Links: RCX1-Port1 to RCX2-PortA and RCX2-Port1 to RCX1-PortA -standard LEGO cable-connections. If you the toggle between float and brake mode, and configure as Boolean, you get 0 for float (open gates) and 1 for brake (short-circuit).

- sound and display error messages; perfect error handling to make sure everything keeps on working, even if problems appear -for example low battery.

The programs of the 2 RCX are quite complex. Here a few shots that might let you frustrated to have not all the code, but both compiled programs have the size of the first original RCX firmware !!!! However, since Ultimate ROBOLAB programs are so excitingly close to flowcharts, some of the functionalities can be guessed.

Comment: The RCX controls the CMUCam2 module to track a color (the meteorite) and return the picture quality in terms of area (expressed in pixels) and the x-position of the object on the image (Mx). Since the camera needs a lot of electric power, it will only be switched on, if a legal user is controlling the rover via Internet. The camera must be configured everytime it is powered up. The RCX controls the grabber arm and maintains the communication to the other RCX.

The rover has an important status-register that has the following values:

Since the synchronous communication now allows the transmission of word-sized data, we may compose the single values as:

S_Source S_Value Owner Comment
1 0 or 1 RCXCam Meteorite found
2 0..90 RCXCam x-position of meteorite center of gravity
3 0 -open / 1 -close / 2 -moving / 3 -error / 4 -fatal error RCXCam actual grabber-arm state
4 0..99 RCXCam actual RCXCam battery level in 1/10 Volts
5 0 or 1 RCXCam low battery (a low battery event may happen, if the camera is switch on. The system then switches it off with the result that immediately the battery-level increases,...)
0x100 ignore value RCXMain command RCXCam to upload 5 values Source 1..5
0x200 see above RCXMain Roverstatus
0x300 0-open / 1-close RCXMain command the grabber-arm

RCXMain sustains the communication to the PC via IR/RF repeater. The only difference in the opcode manager subroutine to the Ultimate ROBOLAB standard one is that we add a 15/100 sec pause between the receiving and the sending of the reply. So the standard ROBOLAB tower control sub.vis may be used. Therefore the transmittable data is transferred into standard containers :


Rover III in tests. Everything works fine except for the problem that the RCXMain program doesn't allow to remove the robot , if a bumper event happened. The bumper task waits for bumper release, but no action was planned to do so. Now, still using the subsumption architecture, the last action always is stored. If a bumper event happens, the rover is told to do exactly the opposite action. For example, the rover drives forward and hits the wall. it then has to move back for a moment in order to release the bumper. If it has turned to the right, it must turn to the left to release it. If the grabber-arm action caused a bumper-touch event, then the rover has to move back too.

Sometimes, the rover might get stuck, especially in a corner, being unable to free itself by simply un-doing the last action. After 5 seconds, the bumper task tells the robot to try random actions to realize the release. To prevent any robot-damage the motor power is reduced. (Note that the motor-power is sent as a message to the subsumption arbitrate task!) After 50 unsuccessful trials, the task enters a "fatal-error" state (NEW code 160) and the operators will have to manually help the robot. Well, this is hard to do on Mars !!

Here some shots of hardware changes:

to be continued