Wii nunchuk, RF and RC

These three posts have been moved into this new thread from big JME's thread radio control system http://www.picaxeforum.co.uk/showthread.php?t=14221&page=14
---------------------------------------

G'day big JME,

This is a rather long post and i notice your last post was about 10 months ago. Just wondering if you got it all up and running?

I found this thread because i am thinking of working on a similar project. I am not ready to start my own thread yet because wont have time to work on it as a full project but i do want to start playing around with sub sections of the larger project!

Firstly i noticed you were going to use xbee... then in a later post you had changed. I couldn't find the post where you changed your mind could you tell me why pros cons??

The project i am considering....
I basically want to try and fly a small RC plane using picaxe and a wii nunchuck. Last night i got a 18m2 chip to read data from the nunchuck then serout it to a second 18m2 which controlled two servos using the variables sent from the first 18m2. i got it working as a tilt pan application using both joystick and accelerometer although it is a bit jittery. i think the issue is that i have servo control picaxe running at 4Mhz and the picaxe reading i2c from nunchuck operating at 8Mhz then sending data at 4Mhz.

So thats what i have done..

and

This is the general plan.
-One nunchuck (transmitter)
-One 20X2 picaxe chip for i2c read of nunchuck and serout (transmitter)
-One 20X2 picaxe chip for serin and servo control (receiver)
-Two xbee 2mW chip antenna modules (one at each end)
-Other general electronics

I am thinking i will use the accelerometer to control the throttle and allierons. And the joystick to control elevator and rudder.

From doing a bit of reading i think the 20X2's should work better together as they can operate at up to 64Mhz i think i might try at 16Mhz and they can control servos at the same speed rather than having to drop back to 4Mhz.

I have seen people working on similar projects with arduino but i don't understand there code.

my main question is whats wrong with using xbee?

Cheers
Joel

---------------

After a little bit more of my own research the issue with Xbee seems to be the latency???

I do have another idea though!

What about picaxe to PPM?? I am thinking if i can get one picaxe to read the nunchuck, then send the data via PPM to the trainer port of my RC transmitter then i don't need to mess around with the second half of the project. I have done a quick search on the forum and Google and it seems like it will be achievable.... but would require the use of a scope to analysis the output of my transmitter to know how the data should be sent. Unfortunately i don't have a scope. maybe its time to invest?

I have a spektrum transmitter, which i think uses similar standards to JR. If anyone can point me in the direction of one the protocol spektrum uses, and two anyone who has been successful in this type of application i would love some guidance.

maybe i should start a new post? (This is it)

-----------

Hi All. Thought I would give an update on this post. I think I will start a new one tomorrow.

So today I had a play around with a picaxe to ppm. As above it was my new idea to save playing with RF. I was able to get the 18m2 chip to send pulses out and using a mono 3.5 jack my laptop and a oscilloscope program I could generate the signal required.

I was hoping to send ppm data to a spectrum DX5e using the trainer port. This requires 8 high pulses minimum .7ms and max 1.7ms with stop pulses of .3ms. The range between .7 and 1.7 is the stick position nothing to full. The lead in is 22.5ms - the 8 pulses depending how long they are.

I tried a simplified version of this using 8 pulsout and 8 pause commands. In each block of code I left 7 pulses at .7ms and one at 1.7ms. I believe this worked ok in its simple form. The problem is when I put a serin line of code the program spent too long waiting, receiving then doing and the lead pulse was too long. I'll post some code tomorrow.

On the plus side I did get the servos working without jitters. I read in the manual that the 18m2 could handle 16Mhz and the servo command also works at 16MHz on M2 parts. To get the servo too move equally I used b8=b2*10/15+75.

So unless anyone has any ideas to overcome my PPM problem I think I am on the search for a Tx and Rx capable of operating at 16Mhz T4800 accurately with a range of 100- 500m

Thanks.

So hopefully I start getting some hits on this. It might be attractive to put some code up so here goes. I am new at this so the code could probably be refined. I wrote the receiver side of the code but used picaxester's code and edited it for the i2c communication with nunchuck. http://www.picaxeforum.co.uk/showthread.php?t=11865&highlight=wii

Here is a link to a DropBox video:
http://dl.dropbox.com/u/11486703/Movie Nov 01, 10 19 54 AM.mov

here is the receiver code so far:
and transmitter (much of this code is from picaxester):

Two immediate thoughts come to mind, by the way I know nothing about PPM/RC but I hope it will help.

1 A simple solution to this type of question is to use another PICAXE to do the serial part and one to do the other pulsing bit

2 Use background serial recieve, x parts certainly support this, the PICAXE you are using i've never tried and might not support it (not got editor installed on this pc to check). With this you can simply check if a byte has been recieved into the buffer.

Dont be afraid of RF, if you have serial comms doing what you need, you could have it working within minutes with an xbee or similar (eg XRF). The latency comes from a 3 byte wait to commit a "send" it than packs lots of other stuff around your packet and broadcasts it 3 times (series 1 xbees). To improve the 3 byte wait simply run at a higher baud rate, you can turn off 3 repeats if required. What might be better is a different RF solution, how many transmissions a second do you need and how large are the messages?

Miles
________
buy easy vape

Thanks Miles,

Unfortunately i don't have any X or X2 parts. But will order them next time i need a few bit and pieces. I was thinking the 20X2 does that also support the background serial input. That may solve half of my problem and i will give it a go once i get some other chips.

I have Xbees (series two i think) in the post so i will try some code with them. i have played around with 433Mhz Tx and Rx a few years ago. I could get it to work but only for about two meters range. I was testing with a bread board and someone told me breadboards effect Rx Tx?? is this true.

To be honest i am not sure how many transmitting a second in need. any ideas on how i work this out? i am sending 6 x b variables as fast as possible all in the same string. I don't know much more than i have put in my code unfortunately.

Also i thought about using multiple picaxe chips, one pulsing, and one sending serial data. I don't know alot about this but i saw someone suggest using an and gate.

the problem i can foresee is that the pulsing timing needs to change dependent on the high parts of the serial data. http://www.mftech.de/ppm_en.htm. i.e. the carier pwm isnt just high for .7 low for .3 there are alot o calculation to then set the lead in time to (22.5ms - (sum(8 pulses) + 8*(.3ms)). anyway If we can try and use a septate thread for PPM http://188.65.57.204/showthread.php?t=16665 as i don't think its a simple solution for this project but one i might pursue in the future.

I don’t think you should be concerned about Xbee latency (it can be much less than ZigBee and Bluetooth) as it’s not in the control loop. Even 'open-loop' 35MHz RC equipment provides an adequate response rate for controlling model helicopters.

However, if you wanted to send aircraft IMU data to a control PC and then send back control commands, then latency could become an issue.

joely87 said:

i have played around with 433Mhz Tx and Rx a few years ago. I could get it to work but only for about two meters range. I was testing with a bread board and someone told me breadboards effect Rx Tx?? is this true.

Click to expand...

Yes, bread board (or ANY conductor) can effect RF. The problem is capacitance and lead length. The connection to the RF output must be the CORRECT length. Breadboard is likely to be too long.

To be honest i am not sure how many transmitting a second in need. any ideas on how i work this out? i am sending 6 x b variables as fast as possible all in the same string. I don't know much more than i have put in my code unfortunately.

Click to expand...

'Standard' RC equipment works within a 20mS frame rate. So, ALL your servo values should update every servo every 20mS.
The new 2.4Ghz systems (eg Spectrum) work slightly differently and there is no latency between channels. It is much better than the older system and DOES have marked effect on more sensitive models such as helocopters where response is everything. Even a few tens of mS can have a noticeable effect on performance. (first hand experience)

Observe a flight such as this one:-
http://www.youtube.com/watch?v=5pHYoNKX2D4

Time how long it takes to do a manouver from say a hover to inverted and then tell the 'naysayers' that a few 10's of mS isn't a significant percentage of response time

Latency IS a BIG issue. Anything over 10mS WILL be noticed.

Just looked, 20x2 appears to support it, look at HSERSETUP page in the manual.

If you are sending 6 bytes each time and as beanie suggests (sounds like he knows) then you'll need a serial speed at a bare minimum of 4800 to squeeze 100 transmissions a second, you'd be wise to run at much higher than this to allow you to actually process some code in between.

One way you can do this is you have your normal pile of code and an interupt routine. The interupt get's fired every xx period of time (and interupts your normal program) often enough that you guarantee to catch the first byte or two into the PIC (swine has only 2 byte buffer). You'd need to interupt 100's of times a second however there's a great feature on a picaxe, if you turn on automatic background mode the axe does this for you and stuffs the data into the scratchpad. You can then look at a far more leisurely pace if there's anything in there by checking the HSERINFLAG is equal to 1 (something arrived).

All sounds complicated, took me a few days to get what on earth it was all about, is worth the effort though. This feature alone I think makes the X parts so good value.

Miles
________
Chrysler 300 letter series specifications

Thanks to the three of you,

I think this is all fairly achievable. I had a bit of a read up on HSERSETUP last night and I can almost get my head around it. I will wait for some 20X2s to arrive then have a crack at it. I think HSERSETUP will solve the PPM problems as well like you said. I was thinking about some code last night.

I am not letting my self tinker with any more electronics for two week as i have my Honours Thesis due it 13 days!! So if i don't reply to this forum it is because I a starting hibernation.

I started this post then spent a few hours writing pseudo code for PPM from an idea i had. PICAXE is addictive! especially when you have a thesis to write. i posted the code on my other thread http://www.picaxeforum.co.uk/showthread.php?p=149248#post149248

Thanks all
Joel