'Fail safe code' modification for RC vehilce using RFIN and RFOUT / 433mhz module

[Blazemaguire]

Hey all,

I have a student developing an RC vehicle using the cheap 433mhz ebay wireless modules. Essentially an RC tank. He's using the RFOUT and RFIN commands for simplicity, as myself (and especially him) are not the strongest at coding.

The transmitting PICAXE sends a different number (e.g, '1' for forwards, '2', for backwards, '3' for turn right etc) and the recieving PICAXE obviously waits for a number ursing RFIN, translates that number into what it should do with the drive motors, and thus how the vehicle moves. - It transmits a '0' constantly when no control buttons are pressed as an instruction to remain stationary)

The problem we're having is that if the vehicle goes out of range (and that's not hard with these cheap modules - maybe 15 meters) the last transmitted numbers is the last thing left in the Recieving PICAXE's variable, and seems impossible to update due to how RFIN works (i.e, RFIN waits until full data is received before proceeding - no time out feature like SERIN) - thus the robot continues driving off into the sunset... and it's quite a large / heavy robot (bike chains and sprockets for tank tracks) - As you can imagine, this isn't ideal round a school car park. It looks like it will do some speed as well, though the chassis is not quite finished so we haven't tested in anger yet, but we have discovered the fail safe issue just bench testing.

I would post the code, but I'm at home right now (doing his research for him... blame our results driven education system for that one) and don't have access to it.

I'm not sure how useful it would be anyway because I believe the problem is RFIN waiting for a response.

What we're looking for is some fail safe method of the receiver realizing it's gone out of range, and thus shutting the motors off. Or some way of making a variable with a number stored in it 'time out' - However, I can't see how to do this when the program loop gets stuck at RFIN waiting for a transmission)

I know this could be solved with serin[timeout] / serout, and I've used these commands with the XRF type serial wireless modules before, but these take care of error checking etc for you, which is why we wanted to use RFIN and RFOUT for simplicity... also, the student wouldn't stump up for the XRF modules, so we are stuck with the cheapo 433mhz ones.

Unfortunately, the student has already made the PCB, so a hardware mod to solve the problem would be tricky (also the board is using a combo of SPST and DPDT Relay's to act as the motor - PIC interface as we didn't have time or money to develop a H-Bridge / transistor based motor reversing circuit that could handle the current draw of the hefty motors he picked).

Any thoughts welcome. If it helps, I can try and replicate the code, but I hope people can understand what I'm trying to describe.

Rob

 

[eclectic]

First quick response:

What Antennae are you using,
and where are they?

e

 

[Blazemaguire]

They are just on the wireless modules direct. 17.5cm single core equipment wire as I think we read somewhere that length suited the wavelength. The PCBs are still on the bench at the moment (not married to the chassis as that's still in progress). They are working with the motors hooked up. It's just when they go out of range, the motor stays doing whatever it's last instruction was!

 

[hippy]

The best choice is to add a front-end interface device which can be allowed to block on RFIN which provides its data to the main PICAXE in such a way that it can use the timeout of SERIN to determine loss of signal.

That front-end could be a PICAXE ( 14M2, 20M2 ) or an NKM2401 chip.

Modifying a PCB should not be too hard if done by cutting the existing signal path then using flying wires to take that through the added front-end.

 

[JimPerry]

Can you sent a heatbeat code every few seconds? and if not received gosub stop all engines?

 

[Blazemaguire]

Can you sent a heatbeat code every few seconds? and if not received gosub stop all engines?

The problem is it would never detect the not received condition because rfout has no time out. And you have to pass the program flow to the rfin command to check for direction changes. The only work around I've got is make the motor do it's current instruction, for a time, say 0.5s, then stop and reset the transmission variable and then listen, but obviously you get jerky motion as a result. It stutters and then has a response lag as well

 

[tmfkam]

Could it be arranged that as well as sending the motor command (or zero) the transmitter sends a 'safety' variable that is constantly incrementing (Time?) and the receiving PicAxe checks to see if the received 'safety' variable is different to the last received 'safety' variable? If not different assume no command was received and after a few failures to update stop all motors.

RfOut b.0,(TxCommand,0,0,0,0,0,0,Time)

RfIn C.0, RxCommand,b1,b2,b3,b4,b5,b6,RxTime
If RxTime = LastTime Then
   'Stop motors
Else
   'Change direction
   Let LastTime=RxTime
EndIf

Sorry. I've not been concentrating. RfIn is a blocking command and so will prevent execution of any further program lines until a signal is recieved.

 

[BeanieBots]

@tmfkam No. As already stated, RFIN is a blocking command. No lines after will be processed, so no timeout, no watchdog etc.. etc..

This is a simple case of you get what you pay for. Those little RF modules are great for simple tasks but they have their limitations.
To be 'fail safe', you will need extra hardware.Either, invest in RF modules which do a lot of the hard work for you such as Bluetooth, Xbee, ERF or similar and use Serin with timeout, or (as Hippy suggests) add some extra hardware to allow either a catch of the serial up front or invoke some other hardware action such as a watchdog hardware (eg 08M2) that hardware resets your main controller if not 'kicked' periodically when a valid data command is received.

This in itself is an excellent example of the requirements that need to be taught for robotics.

 

[erco]

Hi Rob: I'm also using these modules for RC. As noted, RFIN/RFOUT are blocking commands, which can cause various problems. I'm experimenting with sending different-length pulsouts for various control signals. From my tests, a PULSOUT N from Picaxe to the transmitter is consistently received as a PULSIN (N+3) using these cheapie 433 MHz modules, +/-1. YMMV, but it might be worth a shot.

Note that the relays used for motor switching may cause enough EMI to interfere with the receiver, so try to isolate the receiver and motor relays, physically and electrically.

 

[Blazemaguire]

Thanks all. So as I suspected. There's no easy fix. I guess we will knock up an 08m2 on some strip board and try and splice this into the main pcb somehow. Am I getting the 08m to listen to the same serial line as the main board? Bit unclear on this still. I'm guessing no data is all it needs to detect using serin and timeout (error checking not necessary)and then pull the main PICs reset pin high?

 

[hippy]

You cannot listen to the radio receiver serial line to tell when it is active or not because that will be full of noise which gives the impression that it is always active, even when no data is being received.

The front-end would have to use RFIN itself and then send data using SEROUT to the main PICAXE. The main PICAXE uses SERIN to read that and can use a timeout to tell that the link is dead when the front-end becomes stuck its RFIN having received no data.

Note you cannot use an 08M2 as the front-end because that does not support RFIN.

 

[erco]

@hippy: Seems like an optional timeout parameter in RFIN would be a useful improvement for the next firmware upgrade, just as IRIN has. Since the RFOUT protocol is fixed (effective baud rate and 8 bytes of data), RFIN knows exactly what it wants to hear.

 

[Technical]

A timeout won't work due to all the noise in that frequency band.

The correct solution for this project is to use the very low cost NKM2401 chip (not an 08M2 chip) as a front-end.

http://www.picaxestore.com/index.php/en_gb/nkm2401.html

 

[Dartmoor]

I probably still don't understand enough to answer questions but I'll try anyway!
Perhaps a watchdog / increment could actually be used in software?
The original post does not seem to mention what type of Picaxe is being used?
If it is 18M2/20M2 etc, then a parallel task could be run to look for the watchdog / increment?

 

[premelec]

@Technical - is RFOUT fully compatible with the NKM2401? [so you'd just need it on the input...], thanks...

 

[erco]

A timeout won't work due to all the noise in that frequency band.

Not sure what that means. Can you elaborate?

The one & only time I tried RFIN/RFOUT, it worked perfectly, so RFIN wasn't affected by noise in the least. I was quite impressed how well it worked, capturing exactly 8 bytes and moving on, even on the fringes of radio reception, where noise nearly overpowersthe signal.

If it's a blocking command, it sits & stops & thinks & waits for all the right info before proceeding, noise or no noise. How does the noise problem prevent a timeout for radio but not IR?

 

[erco]

@jim: Here's a PDF on the Picaxe transmit/receive pair: http://www.picaxe.com/docs/AXE213.pdf

It shows an NKM2401 on the transmitter and receiver. Surely that would allow an 08M2 (devoid of RFIN/RFOUT commands) to be used on both ends.

Per Manual 2, adding an NKM2401 to a 14-18-20M2 on the receiver end makes receiving a signal non-blocking since it uses SERIN instead of RFIN. But it's not clear if adding one to the transmitter end brings much to the party. If RFOUT is a blocking command, seems like it would only stop execution briefly while sending a data burst. That's less impactful than RFIN blocking, which just stops everything on the receiving end when no signal is received.

From Manual 2 on the RFOUT command

The rfout command encodes and transmits 8 bytes of data over a radio link to a NKM2401 decoder or another PICAXE chip. This provides much more reliable radio communication than using serout commands with low cost RF modules.
This command is equivalent to using an NKM2401 encoder to transmit the data. Therefore if using a PICAXE chip that does not support this command, simply use a NKM2401 encoder instead.

Note that if you do use an NKM2401 as an encoder on a transmitter, you'll use SEROUT, not RFOUT.

I just ordered 9 of these from the Picaxe Store, Jim, FYI. $10.66 shipped.

 

[erco]

I'm getting decent results controlling one servo & pushbutton by sending pulsouts over this cheap radio link, no NKM modules used. It's breadboarded right now using 14M2 & 20M2 chips, but I'm rebuilding with 08M2s, shooting for 2 servos & pushbutton, will advise. The receiver uses pulsout commands, not servo/servopos to drive the servos. If it works then a failsafe mode would be easy to incorporate.

If you don't hear back from me then I failed.

 

[Bill.b]

I have used the AXE213 in conjunction with the RFA001 on my bot with no problems.
You only require SERIN on the receiving end and SEROUT on the tx end.

The only drawback is that you are required to fill the 8 bytes before it will transmit. This was not a problem with my bot as I am sending a ID byte, 8 digital bits and 4 bytes of analogue data from the joy sticks.
the other 2 bytes are filled with 0s.

Bill

 

[erco]

No progress to report on my servo project, too busy with work. But another post led me to some useful info on using the cheapie 433 mhz radio modules: http://www.romanblack.com/RF/cheapRFmodules.htm