DIY custom 2.4ghz RC radio system for robotics

:open_mouth:

:smiling_imp:

:open_mouth:

Looking good Jim!

heh, the word “wow” first came to mind, followed very shortly by “cool…”
8)

The word "wow also came to my mind… but it was followed by “Oh wait… I made those…” 8)

:laughing: I live that from time to time. :wink:

You could just sell the chassis and leave the radio stuff out… Muhahahahahaaa! :smiling_imp:

J/K, I understand… It looks fantastic… very impressive.

Time for some technical content. I have started the receiver side program. This is where we read the AUX2 or Channel 7 pulse length to know which pin is being pressed. I wrote a simple program to display the value in a terminal window.

[code]pulse_value var word
input p3

start:
pulsin p3, 0, pulse_value
serout s_out, i9600, [dec pulse_value, 13]
goto start[/code]

Here is a list of the key, the value in the program, the measured value.

prog measured N 1100 1144uS 0 1150 1193uS 1 1200 1243uS 2 1250 1292uS 3 1300 1340uS 4 1350 1390uS 5 1400 1439uS 6 1450 1490uS 7 1500 1538uS 8 1550 1589uS 9 1600 1637uS A 1650 1687uS B 1700 1736uS C 1750 1786uS D 1800 1835uS E 1850 1885uS F 1900 1934uS

This is fine for doing some if-then statements to turn things on and off. Not sure why the discrepancy in values though. If the program is supposed to generate a 1100uS pulse, why is there a 40uS-ish discrepancy? I’m not doing any interupt or debug or even any terminal commands in the transmitter code. I measured with both a scope, and an Atom Pro doing a pulsin and serout-ing to a terminal with the same results.

Moving on…

Here is a little program to turn on and off the A, B, C led’s on the receivers Bot Board II. They follow the keypresses exactly.

[code]pulse_value var word
keypress var byte
input p3

start:
pulsin p3, 0, pulse_value
;serout s_out, i9600, [dec pulse_value, 13]
if pulse_value > 1662 and pulse_value < 1712 then
keypress = “A”
elseif pulse_value > 1712 and pulse_value < 1761
keypress = “B”
elseif pulse_value > 1761 and pulse_value < 1811
keypress = “C”
else
keypress = " "
endif

if keypress = “A” then
low 12
else
input p12
endif

if keypress = “B” then
low 13
else
input p13
endif

if keypress = “C” then
low 14
else
input p14
endif

goto start[/code]

I’m using these values for the pulsin if-then statements.

N 1119 - 1169 0 1169 - 1218 1 1218 - 1268 2 1268 - 1317 3 1317 - 1365 4 1365 - 1415 5 1415 - 1464 6 1464 - 1515 7 1515 - 1563 8 1563 - 1614 9 1614 - 1662 A 1662 - 1712 B 1712 - 1761 C 1761 - 1811 D 1811 - 1860 E 1860 - 1910 F 1910 - 1959

Hi,

It seems like the 40µS-ish (µS not uS … :wink: ) tends to get shorter when the main puls gets longer? :confused:

But as long as the values of the main pulse from the receiver are stable and don’t varies to much (about +/- 2µS ?) it should be ok.

Just more curious than anything…

Don’t make me do Alt+0181 just for that… :stuck_out_tongue:

Jim

Since your using a reciever and transmitter that is already FCC approved I dont see why you cant sell this as product. If you wanted to. You in no way modified the radio system therfore its still approved.

paul

Yeah I know, but it’s a grey area at best. I think I’ll pass. :wink:

I did some testing and worked with Nathan… I know what the cause is. The overhead to get into the pauseus command after exiting the pusleout command is the culprit. The more complex the arguments for the command the longer it takes to get into the command. Takes less time to load a constant argument than a variable one, and it takes less time to load a variable than to calculate an expression. 8) Here is how I implemented the build PPM function.

makepulses: pulsout 15,800 pauseus ((cha1*2)-800) pulsout 15,800 pauseus ((cha2*2)-800) pulsout 15,800 pauseus ((cha3*2)-800) pulsout 15,800 pauseus ((cha4*2)-800) pulsout 15,800 pauseus ((cha5*2)-800) pulsout 15,800 pauseus ((cha6*2)-800) pulsout 15,800 pauseus ((cha7*2)-800) pulsout 15,800

So I broke some rules there. I need to do the math and send the results to variables, then do the above routine. There will be some overhead but once it’s calculated it should be constant in all the values, therefore making it possible to subtract it out. Yehaa! Mystery solved. 8)

Ah, that sounds like a good solution for the 40µS-ish issue! Good thing you found it.

Oh yes he does, You don’t want to know how often I use Alt+134 since I met the guy :wink:

Great found on the 40"u"S mistery Jim! Can you say anything about the time it takes to read all 7 channels?

Xan

:laughing: :laughing: :laughing:

Highly appreciated that you take your time for that :wink:

A keyboard with macro/programmable keys are very useful. At work we uses something called XKEYS. Very handy and cool too. 8)

Oh, and now he want me to buy expensive hardware to!

Hi XÃ¥n,

The frÃ¥me rÃ¥te for receiving Ã¥ll chÃ¥nnels is Ã¥bout 23mS. This comes from the Ã¥irmod’s own microprocessor Ã¥nd is not Ã¥lterÃ¥ble. There mÃ¥y be some hÃ¥rdwÃ¥re Ã¥vÃ¥ilable in the future thÃ¥t will simplify this. We will see whÃ¥t cÃ¥n be done. :slight_smile:

I hope that the read time can be short enough to add it to the main program. We could always go Zenta style and throw in another ATOM but I don’t have the shiny helmet to cover all the ATOM’s! :slight_smile:

Ånd don’t tell me he tried to sell you the hårdwåre ås well! :stuck_out_tongue:

Xan

I was thinking more along the lines of a little bitty PIC or Atmel board that can attach to the receiver to get the data. Some channels could be read directly by the Atom Pro, such as the joysticks (4 channels) if it’s more convenient, and some could be read from the co-processor via bidi ttl serial com. Atom says “what’s the status” the co-processor says “xxxx xxxx” etc. Most rover scenarios would not require it, but those pesky hexapods probably would.

LOL I have enough trouble just typing, let alone kicking around a foot pedal too. :wink:

I was thinking along this line as well and will try to help out. Alternativly I was thinking about trying out some of the Digi XBEE cards. I actually have purchased a couple different versions of these. My first attempt may be to use the version 1.x ones in transparent mode and on the remote, you simply send it out using serouts and on the robot simply receive the information with serin or hserin…

Before I left work several years ago with RSI problems in my hands, I was using one of these:
kinesis-ergo.com/contoured.htm
It also had a foot pedal and the bright side of it was no one else wanted to use my computer!

Kurt