MARS-Mission Journal (long)
journal created 29/10/2004
During the Luxembourg Science Festival 2003, organized by the Luxembourg Museum of Natural History, our contribution was the Mars-telerobotics project. This was a great success. Many people from all over the world tried to move our tiny robot called Rover-X over the simulated Mars-environment.
We have been asked for a remake of the project that should happen from November 24th to December 4th 2004. The emplacement will be Luxembourg's largest shopping center "La Belle Etoile".
During the first edition some problems appeared:
==> This time we are trying to set up a better communication between computer and robot. The idea is to have a radio-communication. Therefore we are currently developing an infrared-radio-repeater for the RCX. (One first idea was to have the RCX directly wired to the PC. But, the young student-developers thought this was a way back. They largely prefer a wireless solution. (Thanks to Flemming Bundgaard from LEGO for his support with that idea. The delay to realize the repeater is perhaps too short, so probably we'll need to keep the wired solution as our joker ! )
During the last three weeks, Ben Birkel has developed the new rover. As usual, he created a powerful, reliable and perfect machine, again equipped with the well-known direction-master. Rover-X_B has all the functionality of its predecessor, but with a new chassis and bumpers. Have a look at some pictures -and note the gum rings that Ben has wrapped around the tyres to reduce the grip :
The IR-RF repeater keeps on tracking our minds. (We never announced it on these pages, but we are not only robotics-fans, but also licensed radio-amateurs known as LX9CC / LX1BW). First of all, we decided to buy the Conrad Electronics transceiver module TRX 433 (part number 190045). This is an intelligent micro-controller-based module that communicates with any computer-system. You only have to respect a certain handshaking protocol to fill the RF-sender's buffer or get the RF-received data. There are several system commands that allow you to adjust the sending power or change the RF-channel.
What we need to realize is an electronics device that can mainatin an accurate communication between the RCX IR-channel and the TRX RF-channel. This is our actual design:
We have a stabilized power-supply as usual, maximum current 90mA, if both the infrared and the radio were continuously sending. Vishay TSOP1738 is receiving the 38kHz infrared signal from the RCX or the LEGO tower. It decodes the signal to HIGH or LOW states that are transported to the PIC 16F628 UART RX-channel (pin RB1).
The UART-TX-channel (pin RB2) drives PNP-transistor 2N2907, which is situated in series with carrier NPN-transistor 2N2222, a current limiting resistor and the infrared LED. The transistors in series form a logical AND-function. Thus the LED is only powered, when both transistors are switched. The carrier-channel (RB3) is switched at 38kHz. We had developed this infrared sending device with GASTON's audio-sensor. The system works very reliable and is very economic with power.
The TRX433 module is connected to the PIC 16F628: acknowledgement-line (RB7), clock-line (RB6) and data-line (RB5). The module is powered through the repeater-device.
Note that the PIC16F628 is clocked at 18.432MHz. This frequency may seem strange, but the reason for it is that it allows a perfect UART-communication at 2400 baud (2400 is a multiple of 18432000).
Also note that Port A pin 3 is used as control bit during the test phase.
The PC-board is dimensioned to fit on the top of the RCX as shown on the following photos.
The micro-controller PIC 16F628 is programmed with our ROBOLAB-like MPASM-code generator. (MPASM253 with additional sub.vis). We have several preparing tests:
1. General device test
2. Send an RCX F7-opcode Message test
3. Receive RCX opcode F7 test
4. Send bit-data through synchronous communication port made by RB7..RB5
|Prepare for sending||Configure Ackn, Clock, Data lines as inputs|
|Configure Clock as output|
|Set Clock HI|
|Wait for acknowledgment = HI|
|Clear Clock to LO|
|Wait for acknowledgment = LO|
|Send data||Configure Data as output|
|*** Set data line to HI or LO, depending on data bit|
|Set Clock HI|
|Wait for acknowledgment = HI (in the test program, wait 2 seconds)|
|Clear Clock to LO|
|Wait for acknowledgment = LO (in the test program, wait 2 seconds)|
|Last bit ? If FALSE GOTO ***|
|Return to basic state||Reconfigure Clock and data lines as inputs|
The receive handshaking protocol looks like:
|Prepare for receiving||Configure Ackn, Clock, Data lines as inputs|
|Wait for Clock = HI|
|Configure Acknowledge as output|
|Set Ackn HI|
|Wait for Clock = LO|
|Clear Ackn to LO|
|Receive data||Wait for Clock = LO //make sure clock is really LO|
|+++ Wait for Clock = HI|
|Set Ackn HI|
|Wait for Clock = LO|
|Clear Ackn to LO|
|Last bit ? IF FALSE GOTO +++|
|Return to basic state||Reconfigure Acknowledge line as input|
We still must answer several questions:
The following test programs allow us to test the protocol between two identical devices. Important notes:
All works well, so we may now pass to integrate the TRX433 devices:
All this leads to the next two test-programs:
Yes, in deed, everything works for now ! Cool !
The next step will be to combine the IR and RF program-modules to have a reliable repeater.
The repeater works correctly !! :)
This is how we made it :
First, a preparing program that should read and analyze a LEGO protocol IR-packet and convert it to a sequence of RF packets. The second device should work with test_receive_handshaking2.vi in order to observe the transmission.
RF-packets are composed of 8 bytes, the first byte is reserved for future networking use, the second is the packet number, the rest are data-bytes. If the last frame isn't completely filled with data, the remaining bytes are sent as zeros. The RF-device only transmits the LEGO opcode, and its parameters, plus the checksum. The header (55FF00) and the complements are not sent.
NOTE that the packet number is decreasing. So, if we have three packets, the first send is number 3, followed by number 2 and terminated by number 1. If there is only one packet -which will mostly be the case, the packet number is 1.
This program works as a state-machine :
This test-program leads us to our final IR-RF repeater program :
|send_bit_SUB.vi||sends a single bit to the TRX433; subroutine|
|send_byte_SUB.vi||sends a packet of bytes to the TRX433; subroutine - calls send bit procedure|
|receive_bit_SUB.vi||receives a single bit from the TRX433; subroutine|
|receive_byte_SUB.vi||receive a packet of bytes from the TRX433; subroutine - calls receive bit procedure|
|init_TRX_system_instructions.vi||initializes 4 bytes @0x64 with 0x00 0x0D 0x00 0x00 = command 13 (tells the TRX433 to download the RF-buffer to the PIC|
|IR_carrier_SUBs.vi||generates a short 38kHz burst (200 cycles = 5.26ms); subroutines|
|clear_SUB.vi||initializes various data; clears the IR-RX buffer (read twice !) and overrun-error; subroutine|
|IR_receive_ISR.vi||IR-RX interrupt service routine; overrun-check, header & complement check; RF-8byte frame generation|
|verify_header.vi||verifies the 55FF00 header|
|verify_complement_operate_checksum.vi||verifies complement, computes checksum and creates RF-8byte frame|
|IR_receive_complete.vi||completes the IR-reception; verifies the checksum; adds correct packet numbers to RF-frames, completes the last RF-8byte frame, if less than 8 bytes long; sets RF_send state|
|add_RF_packet_numbers.vi||adds the correct packet numbers|
|send_package.vi||preamble and package sending; calls send byte procedure|
|receive_package.vi||preamble and package reception; calls receive byte procedure|
|Blinking_.vi||switches port A, 3 a certain number of times at a variable frequency; needed to show error numbers|
|IR_send.vi||sends an IR-message according to the LEGO protocol; header + data/complement + checksum/complement|
|Cycles2.vi||simply calls the carrier procedure|
|Parity_check.vi||adds the IR-parity bit (9th bit) to each byte; RCX needs this, tower doesn't.|
Two important selectors:
error numbers start with 0 (no error) up to 8 (RF packet time out)
There are two new states now:
if during "lazy"-phase the program detects DATA line = HI, the state changes to "RF_receive". Now the PIC should receive all the RF-packets. The LEGO opcode raw sequence is rebuilt from the RF-packets. The program waits for the next time that the DATA line gets HI. But if there is a yellow timer overflow, the waiting is broken. Without error, the systems changes to:
"IR_send" which generates the complete IR-message with header, data, complements and checksum + complements. The zeros from the last RF-packet do not disturb the reception of the IR-message, neither at the PC nor at the RCX.
The IR-RF repeater can easily be used for one-directional communication. With the RCX opcode F7 (send_message) or D2 (remote_control) don't expect any reply. So, these opcodes can be used without any problem in any direction PC --> RCX or RCX --> or RCX --> RCX
Bi-directional communication is a bit more difficult, for two main reasons:
with the LEGO standard RCX firmwares, the replies immediately follow the receiving of an opcode. There is no wait-time between receiving and sending the reply.
the PC has a short time-slice during which an RCX reply should occur. If not so, the PC starts resending the opcode several times. If there still doesn't appear any correct answer, an error-message is generated.
==> with Ultimate ROBOLAB it is possible to add a wait-delay between receiving the opcode and sending the reply; with some minor effort the computer time-slice can be changed too.
see Rover_Xb with the repeater at the top of the RCX; the tower is enveloped with the second repeater and some LEGO bricks
tower with repeater
NOTE: interested people who wish to acquire the IR-RF repeater system, should contact the web-master
For two weeks now we tested RoverXb with the new IR-RF repeater device. Some observations:
1. Probably due to RF-disturbances not all the packets arrive correctly. (average: 92.5%) This largely depends, if wireless PC keyboards or other devices are used on the same channel. (TRX433 allows to change the channel, so we might add some minor code.)
2. The total transmission speed is reduced to about 1000 baud. This is obvious, since an RCX or tower data-package first is sent via IR, then RF, finally IR again.
3. Thanks to Mr. Kraus from Conrad electronics, who helped us to find out that the TRX433 has an internal watchdog of 120ms. This is a good thing, because our device must not be equipped with another watchdog-timer. However, sometimes 120ms recovering time is too long, causing packages to be lost.
Some screen-shots :
Ben's RoverXb wiring : (as can be seen, Ben uses our direction-master = mechanical compass to measure the robot orientation; a rotometer is placed on the main left gearing)
Thanks to Mr. Feiereisen (P&T) and Mrs Bernadette Muller for their support to have two DSL-lines ready for next Tuesday. So, the Mars-robot may be online next Wednesday.
Thanks to Patrick Delhalt and the collaborators of the National Museum for Natural History for the job they with the Mars-environment. (Special thanks to Jérôme Herr for preparing the Laptops)
Thanks to the students : Ben Birkel, Yves Gloden, Max Thommes, Gilles Kneip, François Warnier, Jacques Hoffmann, who will be personnally present in the mall on Saturday/Sunday (27th & 29th) and Saturday, December 4th.
Last minute changes: Ben reviewed the bumpers with the result that the new ones are very sensitive to any touch-event.
Thanks to Benoît Crussaire, who realized the new Mars-rover base.
All this proves that such a complex LEGO Mindstorms project needs lots of people.
Photo of the Rover in the mall taken during the bug-fixing (sic!)