MARS-Mission Journal (long)

2^nd attempt

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:

• The infrared communication was difficult to be maintained. It took a long time to find out that the problem came from the high frequency neon lamps that illuminated the room where the Mars-environment was installed. So, the lamps had to be replaced ... by weaker ones, with the result that quality of the camera-pictures diminished.
• The robot sometimes got stuck, because the gears touched ground.
• Batteries have to be exchanged rather frequently...

==> 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

• Does the PIC run correctly?
• The connections, are they working?

2. Send an RCX F7-opcode Message test

• Does the LEGO tower and the RCX receive the correct message? (With Ultimate Robolab, we have a tool to read anything at the infrared tower.)
  • We send the following message : 55 FF 00 F7 08 03 FC FA 05, where
    • 55 FF 00 : header (each RCX message starts with this)
    • F7 & two's complement = 08 : opcode Send Message
    • 03 & compl.= FC : value
    • FA & compl. = 05 : checksum and complement
  • The LEGO tower is able to read the message without parity, the RCX is NOT. The parity check sub.vi has been explained earlier with  GASTON's audio sensor
  • The carrier signal at 38kHz is generated by switching on and off the carrier channel (RB3) with the correct pauses.

• We also tried to generate the carrier signal through the PIC Pulse Width Modulator. This works fine. However we still do need the pause after sending out the byte. We didn't succeed to use the back to back system based on the PIC TX interrupt. The reason was the fact that the interrupt-flag is so quickly and automatically reset by the CPU, that we can't ask reliably the origin of the interrupt. Unfortunately the PIC doesn't dispatch this alone. It is absolutely necessary to have a clear distinction of the interrupts, because we want to use at least another interrupt, namely the RX-interrupt.

3. Receive RCX opcode F7 test

• Do we receive data via infrared channel?
  • We try to verify the header + opcode from a table. Unfortunately MPASM at its actual development stage has no table sub.vis yet. So there's a lot of Assembler-code. There should also be a while and if for bit-control. So, MPASM still needs some work.
  • The result of the IR-reception should be read on the generic port made by the three pins RB7..RB5 and the control pin RA3. 

4. Send bit-data through synchronous communication port made by RB7..RB5

• Can we send something according to the TRX433 handshaking protocol

• for each line of the communication line we now have 6 new sub.vis:
  • configure line to input or output
  • if configured as output, set or clear pin
  • if configured as input, wait for pin to go HI or LO
• concerning the data-line there is an additional set of pin state tests

• The handshaking protocol for sending is the following (according to the CONRAD datasheet):

• The test program only follows the Send data procedure-part.  The result may be measured by a voltmeter or any logical test-device.

03/11/2004

The receive handshaking protocol looks like:

We still must answer several questions:

• How do we know the last bit?
• How do we know that the device got something ?

The following test programs allow us to test the protocol between two identical devices. Important notes:

• Port B must have "internal pull-ups" deactivated, which is the case by default and the pins RB7..5 should be pulled down to GND for this test only !!!! Otherwise the programs won't work.
• The receiving device should start blinking a certain number of times, depending on the sent message. (We used test value 0x53 as shown above, but the higher half-byte is masked, so the device should blink three times.)
• The blinking may be verified on PORTA3

All works well, so we may now pass to integrate the TRX433 devices:

• IMPORTANT NOTE: The TRX433 signalizes that it has received a correct message of either 8 or 16 bytes (default is 8 bytes) through setting the DATA-line HI. The control-device should then send the TRX433 system command 13 (= 4 bytes 0x0 0xD 0x0 0x0) to tell the TRX to download the received package. Then the control-device should activate the receiving handshaking protocol.
• We created some more sub.vis  to send and receive a single bit, to send and receive a certain number of bytes, to send or receive a complete package. Note that there are 4 important U8 variables that are used. The pointers should be correctly initialized.

All this leads to the next two test-programs:

• The two control-devices should now be connected to their TRX433
• One device should have the sending role, the other should be the receiving
• If everything is connected correctly, PortA,3 should blink eight times

• PORTA,3 or receiving device should now start blinking 8 times, then wait. Each cycle should have a duration of 18 seconds

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.

05/11/2004

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 :

• The first state is "initialize" which clears all the variables, activates infrared RX interrupt monitoring and chooses the next state:
• "lazy" (sic!) Yes a micro-controller may be lazy! (Wasn't there a Deep Purple song called "lazy"?). In this program the micro-controller hasn't to anything during this state.
• if there is an IR- RX interrupt, the micro-controller reads and stores the received byte. The header and the complement are verified, the checksum is computed and the device number and the RF-packet number are added to the stored data. NOTE: IR-messages may not be longer 60 bytes (opcode and checksum comprised). The total buffer size is 80 bytes, always two bytes used for RF-transmission framing. (If there is an overrun error on the IR-RX channel or any other error occurred, the state changes to "error".) If all went well the state is changed to :
• "IR_receive" : After interrupt service routine (ISR) execution, the RX interrupt is rearmed, so the verifying, storing is done until we have the yellow timer has reached the equivalent value of 10ms without having executed the ISR again. Now the PIC16F628 knows that the whole LEGO opcode and parameters are well received. It is time to verify the received checksum. If it matches the computed checksum, we are certain about the received message. The packet numbers are computed and added to each frame. The last packet is expanded to 8 bytes (filled with zeros), if it were smaller than the desired 8 bytes. The message may now be sent via RF-channel. The state is changed to :
• "RF_send" : The packets are sent one by one with a 50ms pause between each transmission. 

This test-program leads us to our final IR-RF repeater program :

Icon	Sub.vi	Function
	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:

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.

ATTENTION:

• 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

from above

tower with repeater

NOTE: interested people who wish to acquire the IR-RF repeater system, should contact the web-master

20/11/2004

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.

Conclusions:

• We must increase the LEGO tower read time-out at least to 300ms (better 350). We do this in the tower settings:

• We have to parameterize the tower-RCX communication on the PC-side :

• ... and on the RCX-side in the RoverXb-program (written in Ultimate ROBOLAB) :

• RoverXb now has 4 states : ready, running, aborted and error
  • ready : the robot waits for new program instructions from the base; everything is OK
  • running : the robot currently is running a user program-step
  • aborted : the current program-step has been aborted either from a new program download or a bumper-event
  • error : currently only indicates a low battery state.
• The control program is completely rewritten now as a state-machine with the control-states: lazy, new_program, allow_new_upload, wait_for_robot_aborted, verify_program_step, wait_for_robot_ready, uplad_error (=lazy + message), couldn't_abort_program (=lazy + message)
  • lazy : the program waits for new user code; the PC continues communicating with the Rover, getting the battery-level, the light-sensor values and the RoverXb-state
  • new_program : abort old user program, if ever there is one; change state to allow_new_upload
  • allow_new_upload : send new program-step; change state to wait_for_robot_aborted (except, if the new program-step was called "none", then don't change the state; if there is no program-step left, change state to lazy.)
  • wait_for_robot_aborted : wait until the communication returns the RoverXb state aborted ; if this is the case, change state to verify_program_step; if there is a time-out, change state to couldn't_abort_program
  • verify_program_step: verify, if RoverXb received the right program-step; if so, then change state to wait_for_robot_ready else change it to upload_error
  • wait_for_robot_ready : if program-step is ready, then change the state to allow_new_upload; if there is a time-out or an abortion, then do the same.

  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.

29/11/2004

Photo of the Rover in the mall taken during the bug-fixing (sic!)

• We have had some server problems revealed through two hacker-attacks: the server produced an unknown error, and the server still tried to upload an non-existing file with empty filename causing LabVIEW to run a file-open dialog. This is fixed now.
• Many people visit the site and try to move the Rover around
• The radio-communication sometimes suffers: the next time we should choose a different channel (433.6MHz) is too overloaded, especially in Luxembourg's biggest mall.

Main Page