I have now sucessfully sent rmat data from William Premierlanis green UAV dev board to the PC and displayed it with the pyton code developed by Brian Wolfe. I tailored the datagrams from the UAV Dev board to fit Brians format so I didnt have to recode the Python code.
Video:
I use a FTDI board attached to the spare serial port of the UAV Dev board. I send data as ints and the python code parses the data and converts to floats by dividing the modified Q15 format by 16384
The yaw axis drifts since the GPS is stationary, however its difficult to see that on this video. The accelleration compensated axes are stable due to the correction from the accellerometers.I have another video that I will post son that shows the drift of the yaw axis better. The yaw drift is no supprise by the way, as this system isn't supposed to give correct yaw information if the plane is stationary as it uses GPS for yaw correction. (The plane may drop to the ground if the groundspeed is zero unless the course is into headwind with airspeed over stall speed).
For a helicopter a three axis magnetic compass may be used for yaw correction. In fact I have a three axis electronic compass intended for use on my four rotor helicopter laying ready for some possible later testing if I get to dig deeper into the code.
(By the way look at the bottom board, not the red one hanging down. The red board is the UHF diversity RX for the telecommand link )
I plan on doing some flight testing with telemetry soon.
You need to be a member of diydrones to add comments!
Comments
The cable that Ben has in mind sounds good, it should work, and I think his idea for using INT0 for another input will work. His backup plan for using gated time accumulation should work, too.
I am open to any ideas for email lists and code repositories. As it stands, all the firmware and documentation that I have written so far is available on http://code.google.com/p/gentlenav, though I am probably not using much of the features of the repository. If anyone wants to help me with it, please let me know, I am a newbie in that regard.
Finally, just a reminder to use the latest recommendations for the gains in rmat.c, spelled out in a recent post on the subject.
Best regards,
Bill
Thank you for the reply. I will have to look for a Windows version of your diff app.
I am working with Bill on the changes now and hope to get things sorted out later this week. At that point I would like to post the results for others as well...so yes I would be interested in whatever is the best system so we can all share code. I would personally like to see code examples of some of the work people are doing to output data to the serial port and interfaces to PC. Perhaps Bill has some ideas.
Best,
John
I just have a directory that is a copy of unmodified AileronAssist, and another directory that contains my modified version. Then I just ran the standard unix diff command (on my mac) from the command line as:
diff -ru AileronAssistRedGreen AileronAssistRedGreen-5Input
Then I manually removed the lines that described changes to unimportant files, like the workspace file and the build files.
But I'm hoping AileronAssist will end up in an svn repository somewhere, which would make this even easier. :)
I'm also thinking that it would be great if there were an email list for people who are writing / modding code for the UAV Dev Board! Bill: any thoughts? Maybe a google groups list or something? (I can help set it up if you'd like.) I bet we'd all learn a lot from eachother.
Cheers,
Ben
I'm doing mods to Bill's code for Heli apps and have been tracking changes to his AileronAssist code. I' new to the Microchip C programming environment and was wondering how you generated your diff file? If this is an automated tool, it would make things a lot easier to track.
Best,
John
I haven't tested any of this out yet, and won't be able to for at least a week or so. But in case you or someone else wants to play with it before then, here's my diff against the latest AileronAssistRedGreen directory. [5Input.diff.txt]
It attempts to add both an input channel and an output channel. It reads in from RE8 using the INT0 method, and pulses out RE0 using TMR4. I'd be surprised if there were not still some problems in my code. :) (I left a few questions in the comments in servoOut.c starting with the text FIXME.)
If this all works out, then here's what I'm thinking I might do hardware wise:
- Add a 2 pin header to RE8 and RE0.
- Cut the signal line of a 3-wire servo extension cable, and connect each of the two resulting bare ends through a 330 ohm resistor, to a 2-pin female connector.
- Connect this cable from the receiver's rudder out, through the new 2 pin header on the board, to the rudder servo.
If the new input doesn't work, I have another idea that involves sacrificing either the U1ATX or U1ARX pin to use as either T1CK or T2CK in Gated Time Accumulation mode. (Although I'm not yet 100% sure that it does what I think it does...) :)
Thanks for all your help, and for such an awesome and hackable hw/sw platform!
Ben
That will be very nice for airframes with v-tail & ailerons. It will also be nice for several other things, like parachute release. airbrakes, that can now be controlled by the flight computer.
The telemetry range was tested the other day. Not as long ground range as expected but still 1+ km. However the antennas were small verticals and I havent tested in from the air yet.
I am working on the antenna tracker for the moment so I havent got to test more on the Dev Board. The antenna tracker system can now accept serial commands to position the antenna array in az el.
Le me know if you succeed with adding more outputs / inputs by the way.
UFO_MAN
A couple of more things I forgot to mention.
Set the priority of the interrupt service routine for INT0 to 7. That is the highest priority. You need to do that, because actually that routine will be the only time critical routine in the system. All of the other interrupts in the system do not need to be serviced immediately, because the time critical steps were already performed by the hardware.
Since your code will be pre-empting everything else, make sure you don't hang the CPU! Just do the time measurement, deal with the interrupt related flags, and get out.
Regarding the wiring for INT0, all you need is signal and ground, do not connect anything to the spare VCC pin. The best thing to do is to connect at least one other PWM input channel to your radio, that will establish power and ground on the board, so all you need to do is tie the signal for the spare PWM input channel from the radio to RE8. I suggest that you solder a single header pin to RE8, and run a jumper wire from RE8 to the signal pin on your radio.
Good luck! If what you are planning to do works, then the UAV DevBoard will be able to handle 5 PWM input channels, and drive 6 PWM servos!
Best regards,
Bill
The best thing to do in response to the INT0 interrupts is to grab TMR2. That is the timer that I've set IC[1278] to use, so if you use TMR2, you will not have to do any shifting, you will be on the same time basis as the other 4 PWM input channels.
The input capture (pulse width measurement) hardware snapshots either timer 2 or 3, depending on how you set it up. I set it up to use timer 2.
The only difference between what you plan to do with INT0 and what input capture does, is that input capture automatically snapshots the selected timer to a buffer using hardware at the very instant of the interrupt event, so any latency in processing the interrupt is irrelevant.
In your case, there will be a small amount of latency (not enough to matter) between the time the interrupt event occurs and when you get to read the time. The first thing you should do in the interrupt service routine is to record the value of TMR2.
Best regards,
Bill
Thanks for the suggestions! I have it mostly coded up, but my dev board doesn't arrive at my home for a couple more days. And worse, I myself don't arrive at my home for about a week! :P So I won't be able to test until then. But I certainly will as soon as I can!
And I guess that last one wasn't a newbie question after all, but this one probably is: Where should I grab the time from during the INT0 interrupts? The other rc inputs grab from the IC[1278]BUF. Does the INT0 interrupt write the time somewhere analogous? Or should I grab from TMR1? Or is there a simple system clock value somewhere that I missed? For whatever location you suggest, will that value have the same scale as the IC1BUF time values, or will I have to shift it to account for any timer prescaler or anything else?
Thanks very much,
Ben
Your suggestion for using FLTA/INT0/RE8 as a 5th PWM input channel just might work. The idea never occurred to me to change the polarity of the detection on the fly.
The idea might work, it might not, but it is certainly worth trying out. I encourage you to give it a try. If will too, when I have some time.
I read the documentation, it did not give me any clues about it. Whether the idea will work or not is going to hinge on what happens when you change the polarity of the interrupt. In the worst case, it might generate a spurious interrupt, or it might skip one. Hopefully, that will not happen, in which the idea should work.
Here is what I think you should do each time you get an interrupt on INT0:
1. Record the time first thing in the interrupt, and do whatever pulse measurement math you need to do. Double check the polarity of the pin so that you will know which direction you are going.
2. Turn off the interrupt.
3. Clear the interrupt.
4. Change the polarity.
5. Turn the interrupt back on.
Regarding the priority of the interrupt, you can set it once and for all.
Thank you, and best regards,
Bill Premerlani
-
1
-
2
-
3
of 3 Next