Fail Safe assistance

[cwkoehler]

Hello,
I have connected the IsopodX to (2) OSMC's for the purpose of driving a slid steer bot. I have successfully demonstrated that my isomax code works using wireless serial communications for real time control of the OSMC's. The problem is when I loose serial connection the last serial input before interuption remains active. Thus a hole in my living room wall when my (6) 12V drill motor bot lost serial communication, flew full speed across the room in a beeline (forward full power was last command) and bam, right into my wall, knocking off the corner bead and punching a hole in the drywall. My wife was agast. Question - can anyone help clean up my code so that when I loose serial wireless my bot doesnt make a new door to my soon to be doghouse outside. Code and connections below. Thanks in advance. PS - any other 'clean' code recommendations welcome.



( ISOPODX TO OSMC PINOUT
(
( OSMC ISOPODX
( BUS HEADER PIN FUNCTION HEADER PIN
( --------------------------------------------
( LMOTOR 1 4 DISABLE J9 PWMA4
( LMOTOR 1 5 AHI J9 V+
( LMOTOR 1 6 ALI J9 PWMA1
( LMOTOR 1 7 BHI J9 V+
( LMOTOR 1 8 BLI J9 PWMA0
( LMOTOR 1 9 GROUND J9 GROUND

( RMOTOR 2 4 DISABLE J9 PWMA5
( RMOTOR 2 5 AHI J9 V+
( RMOTOR 2 6 ALI J9 PWMA3
( RMOTOR 2 7 BHI J9 V+
( RMOTOR 2 8 BLI J9 PWMA2
( RMOTOR 2 9 GROUND J9 GROUND




SCRUB

HEX

VARIABLE BUSIN EEWORD
VARIABLE BUSOUT EEWORD
VARIABLE CMDOUT EEWORD
VARIABLE CMDIN EEWORD

MACHINE ROBOT EEWORD
ON-MACHINE ROBOT
APPEND-STATE SERIN EEWORD
APPEND-STATE MOVEMENT EEWORD

: PWM-INIT
PWMA0 INDEPENDENT
PWMA1 INDEPENDENT
PWMA2 INDEPENDENT
PWMA3 INDEPENDENT
PWMA4 INDEPENDENT
PWMA5 INDEPENDENT
4E2 PWMA0 PWM-PERIOD
7FFF PWMB0 PWM-PERIOD
; EEWORD

: TILT
CMDOUT @ PWMB0 PWM-OUT
; EEWORD

: PAN
CMDOUT @ PWMB1 PWM-OUT
; EEWORD

: DRVREV
CMDOUT @ PWMA1 PWM-OUT
CMDOUT @ PWMA3 PWM-OUT
PWMA0 OFF
PWMA2 OFF
PWMA4 OFF
PWMA5 OFF
REDLED TOGGLE
; EEWORD

: DRVFOR
CMDOUT @ PWMA0 PWM-OUT
CMDOUT @ PWMA2 PWM-OUT
PWMA1 OFF
PWMA3 OFF
PWMA4 OFF
PWMA5 OFF
; EEWORD

: DRVLFT
CMDOUT @ PWMA1 PWM-OUT
CMDOUT @ PWMA2 PWM-OUT
PWMA0 OFF
PWMA3 OFF
PWMA4 OFF
PWMA5 OFF
; EEWORD

: DRVRGT
CMDOUT @ PWMA0 PWM-OUT
CMDOUT @ PWMA3 PWM-OUT
PWMA1 OFF
PWMA2 OFF
PWMA4 OFF
PWMA5 OFF
; EEWORD

: TURNOFF
PWMA0 OFF
PWMA1 OFF
PWMA2 OFF
PWMA3 OFF
PWMA4 OFF
PWMA5 OFF
; EEWORD

IN-STATE SERIN
CONDITION
CAUSES
HEX
SCI0 RX BUSIN !
SCI0 RX DROP
0
SCI0 RX 30 - + A *
SCI0 RX 30 - + A *
SCI0 RX 30 - + A *
SCI0 RX 30 - + A *
SCI0 RX 30 - + CMDIN !
HEX

THEN-STATE MOVEMENT TO-HAPPEN IN-EE

IN-STATE MOVEMENT
CONDITION
CAUSES

CMDIN @ CMDOUT !

BUSIN @ 31 = IF
TILT
THEN
BUSIN @ 32 = IF
PAN
THEN
BUSIN @ 33 = IF
DRVFOR
THEN
BUSIN @ 34 = IF
DRVREV
THEN
BUSIN @ 35 = IF
DRVRGT
THEN
BUSIN @ 36 = IF
DRVLFT
THEN
BUSIN @ 20 = IF
TURNOFF
THEN
BUSIN @ 1B = IF
SCRUB
THEN

THEN-STATE SERIN TO-HAPPEN IN-EE

: START
PWM-INIT
SERIN SET-STATE
INSTALL ROBOT
EVERY 1388 CYCLES SCHEDULE-RUNS ROBOT
; EEWORD

[ngkdc]

My first thought is to see whether your wireless comms supports RTS/CTS/DTR. Thus, if you lose the link, the RTS/DTR/CTS (choose one), you cause an immediate stop. This requires your code to be looking for the handshake line ALL the time (use a machine to perform this every tick).

Further, when the handshake line is activated, you should wait a finite period before accepting any commands ... to ensure you have a good signal.

If the wireless comms has a signal strength or quality of signal analog output, you could use the A/D converter to monitor signal strength, and perhaps warn you (yellow LED on top goes on when signal below 50 %, Green when above 50 %, and Red when comms lost and all stop issued.

Another method would be to require a constant data stream sent to the serial port ... this constant stream would cause a reset to the hardware watchdog timer ... before you parse the data and throw away all of your idle data (sync is a good one here perhaps). The watchdog timer routine is pretty simple to set up and believe me, it works. I'm running a 500 mS watchdog, so if the hardware hangs or I fail to reset the watchdog in time, the processor reboots. I'm also reading the reset registers to determine whether the watchdog reset, external reset was pressed, or whether one of the low-voltage detectors caused an internal reboot (great for troubleshooting).

Hope this helps.

Rick

[RMDumse]

What kind of serial link? Is there anything on the serial link that indicates carrier detected? If so, you can do a shut down when the carrier is lost.

For instance, on the SparkFun Blue-SMiRF's they come in two varieties, the Basic one which has just four signals, RX TX Gnd Pwr and Extended one with six signals, adding RTS (Ready to Send) and CTS (Clear to Send). Then you could tell by those signals if your link was there or not (if no RTS, shut the drive down).

If not, then you have to establish some sort of ping-pong protocol back and forth to maintain the sense the serial link is still there, which sounds rather difficult to do. It might require something more than just a terminal program to send the programs, and some sort of packets and perhaps even checksums.

And yes, I see some problems with the code.

For one, the state machines CONDITION CAUSES has no boolean value in them to evaluate, so when they run, you don't know if they will go through the CAUSES TO-HAPPEN action or not. They just pick something up off the stack at random. It is only because of the protection we put into the interrupt handler, this consuming of values not provided doesn't cause a system crash.

Possibly what would be best there would be something checking to see if the serial command is ready, like a counter that checked to see if seven serial characters were waiting, and the eigth was a <CR> or something like that.

When you call RX in the background (scheduled) task, and no serial characters are there, RX will wait until one arrives. That is a Program Counter Capture, and shoudln't be used in the background.

So I'd advise maybe using the serial interrupt buffering, and some sort of sync character as well. But since I can't remember how much of this we've talked about before, I'll stop here, and see what comments you might have in reply.

[cwkoehler]

thanks for the advice thusfar

As for what serial connection I am using - Surelink 900 mHz RF module with a Quicklink Board http://www.parallax.com/detail.asp?product_id=30065. After review of the online pdf for the Surelink it becomes clear to me that there is some a signal indicator for a successful link between two transceivers (I think it is Clear to Send). How exactly I am to read this signal off the Quicklink is elusive at the moment yet I will continue to do my homework. Thanks for the input

cwkoehler

[RMDumse]

Since it is an LED, strapping a photo resistor on it, and bringing that to a digital line on the 'Pod might get you a nicely isolated sense.

[cwkoehler]

That offering contains great ingenuity and one I will surely attempt
Thanks RMDumse