Limiting Timeout on PULSIN for Radio Control Receiver

Zoot

I'm using a radio control transmitter and receiver for my 'bot, and my code works fine, but I am looking to obviate the length of the timeout on the PULSIN (BS2p40).

In other words, on the BS2p the length of a timeout on PULSIN is 52.428 milliseconds. If I scan the RC channels for possible pulses (if pulses are present, then you are under radio control), I have timeouts that add up to nearly 100ms -- just waiting for something that might not be there.

I tried one trick that sort of worked -- I did a COUNT over a 25ms duration, and if it only counted 1 pulse, then the program presumed there was radio control, and would do two PULSINs for the 2 channels. The only problem there is that I have a pretty cheap transmitter/receiver (AM) and it is subject to unbelievable interference from the local radio station, so I would sometimes get false positives on the count. My PULSIN routines check for good values on pulses, so the bad pulses get thrown away, but that left me right back at waiting on possible timeouts up to 100ms.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

slamer

I had to fix a similar problem with EVA by testing to see what the PWM signal value from the receiver was when the transmitter was turned off and the receiver was just picking random values...

Receiver:
·· 'Read the signals from the receiver and sends the values to the servo control board
·· 'the signals from the servo control board is then sent to the speed controllers.
·· 'Standard Teleoperated mode unless channnel2 variable changes
DO
··· PULSIN 0,1,channel0 'Measure receiver positive pulse pin p0
··· PULSIN 1,1,channel1 'Measure receiver positive pulse pin p1
··· PULSIN 2,1,channel2 'Measure receiver positive pulse pin p2
·· 'PULSIN 3,1,channel3 'Measure receiver positive pulse pin p3 'future use
·' check receiver to activate autonomus mode actually channel 5 on receiver
·· IF channel2 < 750 THEN motorstop 'failsafe robot for loss of radio signal
·· IF channel2· > 1000· THEN AutoEVA
·· pw = channel1
·· pw1 = channel0
SEROUT Sdat, Baud+$8000,[noparse][[/noparse]"!SC", ch, ra, pw.LOWBYTE, pw.HIGHBYTE, CR]
SEROUT Sdat, Baud+$8000,[noparse][[/noparse]"!SC", ch1, ra, pw1.LOWBYTE, pw1.HIGHBYTE, CR]

"show me what the heck is going on
·DEBUG "channel0 = ",DEC channel0 ,CR
·PAUSE 1000
·DEBUG "channel1 = ",DEC channel1 ,CR
·PAUSE 1000
·DEBUG "channel2 = ",DEC channel2 ,CR
·PAUSE 1000
LOOP

****************************
Basically I test the PWM signal between two exstream values of 750 uS (stick center)to 1000 uS (semi exstream stick movement from center.) if it's out of this range then I tell the robot to stop moving. I used the DEBUG statment to find the values in this test program.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Steven Kirk Nelson (slamer)

Team K.I.S.S
Build Safe, Build Mean, Build Strong!

Zoot

That's *exactly* what I'm doing to check for good pulses (of course my values are different and were chosen based on empirical evidence from my transmitter). Glad to know I'm not alone So "bad" pulse widths are thrown away and not used for control.

My quasi "problem" is the timeouts on the PULSIN commands to begin with. On the BS2p, a PULSIN times out after 52ms or so -- obviously way longer than I need to check for a good pulse (<25ms in my case). This is a precious 104ms wasted in my main program loop while the 'bot checks for RC transmission.

Now, the reflex states in my 'bot "turn off" the PULSIN commands when they are executing, and turns them back on when it is done with any reflex behaviors (in other words, it only checks -- and wastes time -- on the PULSIN commands if it's not doing something really important like avoiding a wall).

As I wrote above, the only scenario I could come up with to shorten the wait time was to COUNT for 1 good pulse, then use that to check for PULSINs, e.g.

- COUNT for < 25ms. If there is ONLY ONE pulse during that time period, THEN
- PULSIN x, Y

Since I know I've got a good pulse from the COUNT, there won't be a timeout to wait for on the PULSINs. So that cuts the time for "good" checks to about 65-75ms, and cuts the time for "no RC" to 25ms. But naturally with the noisy RC, it doesn't work. I dunno, I may have to live with it, or get another RC package that isn't subject to so much interference.

Oh, one other check that I do that helps in eliminating bad counts is to check the state of the RC pin input for a "LOW" first -- if it isn't low, then the program skips the pulsins -- a high state would indicate a pulse "in progress". You still get a good pulsin (because pulsin waits for a complete 0-1-0 state change) but waiting to check when the pin is ready shortens the time required to read the pulse.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

Capt. Quirk

What about using some small servo positiotion sensors instead. On my own project, this worked better than trying to track the servo's electronicly.

Zoot

Capt. Quirk -- not sure what you mean? I'm reading pulses in from a radio control transmitter and receiver. The 'bot program checks for good pulses on the receiver, and if they exist, it presumes to be under radio control (turn/speed). If it doesn't have good pulses, then it acts autonomously. Servo refresh and such is not an issue (I use a PSC for my servos), but the 100ms timeouts really stack up and so the main program loop gets a bit slow for my taste.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

Capt. Quirk

With my project I was using the pulsin commands to recieve·servo instructions from a Futaba 1024 PCM Rx, then my stamp would control 2 servos based off the data from the·Rx and other sensors. It turned out in my case that small potentiometers·with an ADC0834, (using shiftin ) it was much quicker and with 256 steps it was similar to reading Pulsin data without the delay.·

Zoot

How did you do that? Did you convert the pulses to a measurable voltage with an reistor/cap circuit? or? Ingenious.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

slamer

Well personally I'd recycle the AM radio and receiver·with a sledge hammer. They are very unreliable. We barely allow them in the one pound weight class (without weapons)·in robotic combat because of their ability to get confused. You can get a pretty decent Futaba Sky Sport·or Hitec Ranger II·75 Mhz FM radio·for less than $100.00. I think they can both·be ordered in 75 Mhz ground frequency. If not there is a guy that can do it.

His name is George Steiner at GSP products. He does a lot of the (72 Mhz (AIR) to (75 Mhz )(ground) for the combat robot folks. He does good work. I mention him on this web page

http://www.teamkiss.com/newkiss1220.html

75 Mhz FM radios·are a lot better and more predictable than AM. Browse around EBAY for a deal.

·The radios·I use·are the Futaba 9CAP and the Hitec Prizum 7x. Both are capable of PCM and programable failsafes and they have a lot of mixing functions as well. (of course these are sorta high end radio systems $350.00-$600.00)

But in EVA, I'm just using them in 75 Mhz PPM mode and talking to a Novak Xxtra 75 Mhz FM·tunable ·receiver without failsafe.

· I've found that even 75 mhz PPM FM is pretty stable and predictable.·I did had to add a line of code to take care of·the nonfailsafe function or PPM·limitation. But in the long run using a slightly better·75 Mhz FM radio·will save you a lot of Trial and Terror.

By the way thanks for the tip on checking for the negative part of the PWM receiver output I'll have to try that out.... Saving a bit of processing time is usually a good thing.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Steven Kirk Nelson (slamer)

Team K.I.S.S
Build Safe, Build Mean, Build Strong!

Post Edited (slamer) : 3/14/2007 1:02:30 AM GMT