So after speaking with Kurt working with him for a while on the RC control of the Phoenix using the t7C transmitter it seems I am kinda in a rough spot as to how to use the T7C transmitter for a heli.
I have been pondering a couple ideas as to what really is a good method I’m biased towards one right now and that’s the home brew transmitter/receiver using the Xbee due to serial communications being much much faster then reading pulsin’s
Ps3 remote + bluetooth bluesmirf <-- I have been told that the ps3 blue tooth needs something like a full host to operate? I’m not experienced enough in Bluetooth to give anyone a full explanation on this.
Buy an additional Bot Board put it on top of the one I currently have on the phoenix and use it to process the pulsin commands and spit it out via serial to the first botboard. I believe Zenta did this for his, but it makes the robot too tall, I would think a smaller Adruino would be cool like the Nano to read it and output via serial. You could write some code for this and let more users use a method to convert RC pwm to a faster buffered format without tying up the cpu (20ms * Number of channels ) Unless you know asm like Kurt.
Buy an additional Bot Board buy some gimbals and a Xbee module and make a transmitter… maybe have a serial display or something? bunch of cool buttons. Mount the Xbee module on the phoenix change the code “All this has been done before so I’m sure I can get assistance on this one and code examples”
a wireless ps2 remote and done.
An additional Bot Board Xbee and a ps2 remote… not sure how the case would look for this thing , although the ps2 hard wired device has documentation on it, and it was already written for the Phoenix control, i would just be making the Xbee send the data over serial to the other board.
Some additional notes… The phoenix could potentially have no brains and a simple serial receiver module like the Xbee or the Bluesmirf making it a bit lighter…All the processing power could be held in the transmitter… It seems like I’m leaning towards the Xbee modules… I need some nudges here what does everyone think?
Hi, It is difficult to say what is the best solution. Obviously I went with the XBee solution, which I am happy with. There are many variations of what you can do and choose how much processing power you wish to use at each end. I choose the approach of keeping most of the smarts at the different robots, such that the remote does not have to know anything about robots. But could have instead choose to put some of the smarts in the remote and/or could have put many of the standard messages in the remote as to save program space on the robots…
I looked a little at PS3 or Wii type controls as this could be interesting, especially the wii with the nunchuck installed. But these would require a completely different UI to know how properly make use of the data they give you. Also as you said it would require a complete BT type of implementation, which is too heavy weight for most micorcontrollers…
The 2) method would work OK. I have at times thought it would be great if someone built a simple inexpensive board to do this. Could be a small Arduino, or maybe a Nano 18 or… Sometime I may try my Nano18 with a RC control and see how well it handles it. Could maybe use I2c to have it talk to other controller…
Another method is to hack your RC receiver and try to get the input from one IO line. I did it with the Hitec6, have seen stuff up on the web for others. This way all of the inputs are on one IO line and I have a simple assembly language function that simply measures, the transitions on 1 IO line. The version I wrote used the hardware capture to get the exact timings.
Update: There are websites that show you how to this for some Futaba receivers. Example: diydrones.com/profiles/blogs/705 … Post:38393
Wireless PS2 is great for playing around. I don’t think it gives you near as fine of control as the RC style of joysticks, but it is easy to get working…
As you mentioned, the Phoenix could simply have an SSC-32 in it, with something like a Bluetooth serial connector on it and you could have all of the smarts elsewhere, such as in a remote control or on a PC or…
Again not sure what the best approach is for you, but it is fun trying out different things…
So I read the PPM document How cool! I remember you talking about this a while ago although it didn’t click.
It looks like PPM stays low as long as the servo PWM pulse is from 500ms to 2000ms then a clock, then channel 2 3, 4, 5, 6,7 exct! Although since I don’t know ASM would the existing ASM code you wrote be able to be modified?
Totally cool news if that’s the case I’ll go start hacking up my receiver when I get home… Besides assembly can it be written in basic?
So how difficult would it be if you changed your code to read 7 channels? and does it just populate the values in an array sorta like the assembly feature you had sent me?
–Aaron
ps I’m thinking the guys at basic micro make your PPM feature a function called PPMRead or perhaps KurtRead… I would make it expandable so the user can choose the # of channels to read
You could actually probably do it in basic as well, either as interrupts or simply doing a query of the values…
It would also not be difficult to configure it for specific types receivers. What is needed is to see the actual pulses being generated by your receiver. With more channels, my guess is that it could maybe have two of these timers and potentially would need to intercept both… Not sure, as I don’t have one, but will see what you find.
So I have an iron, I have a Bus Pirate “I can measure frequency with this” I also have a logic analyzer although It would be nice if I had my DSO Quad oscilloscope soon to be shipped from china!
I can sure attach 2 wires to this device and make it nice looking, plenty of room inside the case to have some pins sticking out.
I’m looking at this chip that’s the top photo, directly to the right of the servo pins, I’m going to take a guess but that appears to be the shift register? so what I need to do is use an Oscope and find the signal pin going into the shift register since a pin tells the shift register to shift, not sure if this is the clock pin, but some other pin.
is this about right?
Actually you wouldn’t need clock… you would need the data line that causes the shift register to change states… hopefully that makes sense… I looked at the PPM document you sent me. Obviously PPM is much better to work with 2 wires vs 7, probably a lot better to write an assembly bit of code that plays nicer.
Looking at the attached document, why I think you don’t need clock is it looks like you measure the time the signal line goes high, ignore when it goes low then stop the timer when it goes high again, and immediately start a new timer and do this for the number of channels you have. It’s probably my incorrect terminonogy but I’m thinking a clock line as a line thats a square wave and has a specific frequency.
Damn I hope I’ll be able to attach a data line without trying to attach it to some ridiculously small point that will break off later, so I think I’ll be able to find the input line on an area that isn’t microscopic!
do you have photos of yours Kurt?
