The UAV development board is back in stock at SparkFun.SparkFun also plans to eventually carry 12" cables for the GPS connection, which could be used for the UAV development board, as well as for Chris Anderson's ArduPilot. Sparkfun also plans to eventually carry 12" servo cables for connecting from the board to the RC receiver.Presently, there is C code available for getting you started with the UAV development board. There are two separate programs. One is for simply making sure that the board is working, used at SparkFun to test the boards before they ship. This one is available both at SparkFun and on this website, and is the program that is in the board when it is shipped. There is also a program that I call "GentleNav", available on this website only. It is a port of the program that I have been using for a couple of years on my previous hardware platform. It performs pitch stabilization and/or RTL for an electric sailplane.By the way, there is a "feature" of most GPS radios that you should be aware of if you plan to use both programs. If you command GPS radios to switch baud rate or between NMEA and binary formats, they only listen at the new baud rate and in the new format. If you run the "GentleNAV" program, it will switch to binary format with an NMEA command. If you then run the self test program, which trys to communicate in NMEA format, the GPS radio will ignore all commands, and the self test will indicate a failed GPS. If you plan to switch back and forth, you should revise the self test program to have it send the GPS command in binary format to switch to NMEA. With older GPS radios that I have used, they eventually default back to NMEA. The EM-406 somehow seems to forever remember the commands to switch, it will never switch back. I eventually plan to revise the self test program. In the meanwhile, it might be a good starting point for you to revise the self test program to send a binary command to the GPS to switch to NMEA format, its not hard to do.You should also be aware that the status light on the EM-406 only works when the radio is in NMEA mode. At least I haven't figured out how to make it light in the binary mode, it just goes out. It resumes operation when you switch back to NMEA.Presently, I am working on two projects related to the UAV development board. First, I am finishing up the documentation for the "GentleNav" firmware. Its taking longer than I thought. I will post a blog when it is done.Second, I am working with Paul Bizard to develop theory and implementation for "artificial horizon" firmware for the UAV development board. It will combine gyro, accelerometer, and GPS information into a stable, responsive, accurate representation in matrix format of the orientation of the plane that it is mounted in. We believe we have a method that will work, but we have a few more details to work out. We will publish the theory when we have something we are satisfied with, and tested code some time later. What we have in mind is an algorithm that will maintain the 3X3 direction cosine matrix that describes the relative orientation of the plane and ground. Each entry in the matrix is the cosine of the angle between an axis on the plane and an axis on the ground.Best regards to everyone, and acknowledgements to Chris Anderson, Paul Bizard, and all the staff at SparkFun for their help.Bill Premerlani
Hello Bill.
Which one is a better option for developing an autopilot for a UAV. Your Dev board or Chris's Ardupilot. I need to start complete autopilot development (as an amateur) for a quadrotor and would like to know which one is the BEST solution. I would like to try out any autopilot first on a fixed wing to gain some experience. What fixed wing model do you recommend?
After all is said and done, I will eventually develop my own control algorithm down the road so stuff like maximizing onboard computing power (to process real time Kalman filtering algorithm, etc.) will certainly be a KEY factor in design.
Any tips from you will be tremendously appreciated. Thanks.
Have a nice day.
Syed
Bill,
you seem so...entusiastic :)
Thank you very much for your reply...let me specify some terms you used in your reply.
Generally speaking the offset you said is also referred as bias (please correct me if I say bullshit... :) ) and gain should be the more famous "sensitivity"...Just to make sure I didn't confuse terms...
So..
this is exactly what I meant: The gains vary somewhat from unit to unit, but not so much over time for one unit.
Is the same Problem I faced after I bought my sensor board....
I spent...really...weeks having headache due to the reason that the datasheet doesn't report exactly the sensitity of sensor (accelerometers and gyros) but just a stitiscti avarage.
Later I was disappointed discovering the those values weren't ok for my unit...so I bought a player and built a rough "turntable" which I used for tuning sensivity and offset of sensors...
But you gave mw a good hint! You revealed me that the code doesn't take much care about that due to the routine itself.. and the error is negligible.
It would be not ok fur kalman code...
It woulb be really interesting developing a routine, that by iteration and using pure mathematics "auto tunes" those values...
I googled around but I didn't found any suitable example...(and maybe they are too difficult to be implemented in a microcontroller)..
By the way. thanks to Curt may you reveal some "news" about the new design?
Are going to switch PIC over ATMEL?
Will the architecture remain the same?
:) : ) :)
We are working on a "new" design. It will be out probably at the end of 2010, or early in 2011. We plan to offer and support both boards.
There is still a lot more we can do with the existing board. It looks like the main limiting factor is the amount of ROM. Right now we have used up about half of it. It looks to me that we can continue adding firmware though most of 2010 before we run out of program space.
With regard to CPU loading, there is plenty of margin left on the existing board. Presently, we are at about 6% loading with the clock set for 4 MIPS. We could raise the clock frequency, using the internal fast RC clock, up to 30 MIPS.
Bill, I have been following the UAV Dev Board development for a while now. I am in the process of designing my own board but have lost interest due to time restraints. I want to purchase your board for now so I can start learning more of the programming. Are you planning on coming out with a "new" design within the next year? I dont want to buy the current model if a newer more powerful will be offered.
There are two aspects of the calibration process: offsets and gains.
There is some variation in the offsets, and offsets must be accounted for in the gyro signals especially, so our software (MatrixPilot), computes the offsets for all 3 gyros and accelerometers as part of the initialization process. This is similar to what is done in some commercially available heading-hold gyros for helicopters. So, you have to hold your airframe motionless and level during the first few seconds of the initialization process.
As far as the gains are concerned, the firmware assumes the nominal gains. The actual gains are within about 5% of the nominal gains. The algorithms that we are using do not require the gains to be exactly right. So far, the performance we have seen is rather good.
Although hardly anyone uses it, there is an option for you to manually adjust the gains. With the DCM algorithm, there is a rather simple way to do that. Its a method I used to verify the nominal gains in the first place: I load the roll-pitch-yaw demo with drift compensation turned off. Then, I put the board on a swivel chair and rotate it 10 times, and then look at error at the end, and adjust the gains accordingly. Then, once you know the gains, you can use them in MatrixPilot.
The gains vary somewhat from unit to unit, but not so much over time for one unit.
Another thing you have to watch out for is variation of offset with change in supply voltage and/or the A/D reference voltage. The best thing to do is use a regulated power supply for both. If not, you should include a reference voltage as one of the inputs, and compensate for supply variation.
As far as variation of offset with respect to temperature, we have not had any problems, we simply ignore any temperature changes. The DCM algorithm is pretty good at compensating for offset shifts due to temperature.
Hi Bill,
I would have a question.
Since one year I sticked with accelerometers and gyro bought from Sparkfun and I m really comfortable developing software and firmaware in assembly and C (for PIC micro).
As far as I know I had really serious problems at the beginning developing an IMU reading sensor data due to the need of calibration of such sensors.
Now I m going to have your UAV dev 2 board and giva it a try but I still wonder how you (sparkfun in this case) ships the board with a firmware with calibration data already hardcoded into the pic.
as far as I know MEMS technology produces sensors with not constant behavoiur and a calibration is needed.
Comments
There was a recent discussion about UAV DevBoard and ArduPilot. Take a look here.
Best regards,
Bill
Which one is a better option for developing an autopilot for a UAV. Your Dev board or Chris's Ardupilot. I need to start complete autopilot development (as an amateur) for a quadrotor and would like to know which one is the BEST solution. I would like to try out any autopilot first on a fixed wing to gain some experience. What fixed wing model do you recommend?
After all is said and done, I will eventually develop my own control algorithm down the road so stuff like maximizing onboard computing power (to process real time Kalman filtering algorithm, etc.) will certainly be a KEY factor in design.
Any tips from you will be tremendously appreciated. Thanks.
Have a nice day.
Syed
you seem so...entusiastic :)
Thank you very much for your reply...let me specify some terms you used in your reply.
Generally speaking the offset you said is also referred as bias (please correct me if I say bullshit... :) ) and gain should be the more famous "sensitivity"...Just to make sure I didn't confuse terms...
So..
this is exactly what I meant:
The gains vary somewhat from unit to unit, but not so much over time for one unit.
Is the same Problem I faced after I bought my sensor board....
I spent...really...weeks having headache due to the reason that the datasheet doesn't report exactly the sensitity of sensor (accelerometers and gyros) but just a stitiscti avarage.
Later I was disappointed discovering the those values weren't ok for my unit...so I bought a player and built a rough "turntable" which I used for tuning sensivity and offset of sensors...
But you gave mw a good hint! You revealed me that the code doesn't take much care about that due to the routine itself.. and the error is negligible.
It would be not ok fur kalman code...
It woulb be really interesting developing a routine, that by iteration and using pure mathematics "auto tunes" those values...
I googled around but I didn't found any suitable example...(and maybe they are too difficult to be implemented in a microcontroller)..
By the way. thanks to Curt may you reveal some "news" about the new design?
Are going to switch PIC over ATMEL?
Will the architecture remain the same?
:) : ) :)
It sounds really interesting...
Thank"!!!!!!!!!!!!!!!!!
Cheers
Dave
We are working on a "new" design. It will be out probably at the end of 2010, or early in 2011. We plan to offer and support both boards.
There is still a lot more we can do with the existing board. It looks like the main limiting factor is the amount of ROM. Right now we have used up about half of it. It looks to me that we can continue adding firmware though most of 2010 before we run out of program space.
With regard to CPU loading, there is plenty of margin left on the existing board. Presently, we are at about 6% loading with the clock set for 4 MIPS. We could raise the clock frequency, using the internal fast RC clock, up to 30 MIPS.
Best regards,
Bill
There are two aspects of the calibration process: offsets and gains.
There is some variation in the offsets, and offsets must be accounted for in the gyro signals especially, so our software (MatrixPilot), computes the offsets for all 3 gyros and accelerometers as part of the initialization process. This is similar to what is done in some commercially available heading-hold gyros for helicopters. So, you have to hold your airframe motionless and level during the first few seconds of the initialization process.
As far as the gains are concerned, the firmware assumes the nominal gains. The actual gains are within about 5% of the nominal gains. The algorithms that we are using do not require the gains to be exactly right. So far, the performance we have seen is rather good.
Although hardly anyone uses it, there is an option for you to manually adjust the gains. With the DCM algorithm, there is a rather simple way to do that. Its a method I used to verify the nominal gains in the first place: I load the roll-pitch-yaw demo with drift compensation turned off. Then, I put the board on a swivel chair and rotate it 10 times, and then look at error at the end, and adjust the gains accordingly. Then, once you know the gains, you can use them in MatrixPilot.
The gains vary somewhat from unit to unit, but not so much over time for one unit.
Another thing you have to watch out for is variation of offset with change in supply voltage and/or the A/D reference voltage. The best thing to do is use a regulated power supply for both. If not, you should include a reference voltage as one of the inputs, and compensate for supply variation.
As far as variation of offset with respect to temperature, we have not had any problems, we simply ignore any temperature changes. The DCM algorithm is pretty good at compensating for offset shifts due to temperature.
Best regards,
Bill
I would have a question.
Since one year I sticked with accelerometers and gyro bought from Sparkfun and I m really comfortable developing software and firmaware in assembly and C (for PIC micro).
As far as I know I had really serious problems at the beginning developing an IMU reading sensor data due to the need of calibration of such sensors.
Now I m going to have your UAV dev 2 board and giva it a try but I still wonder how you (sparkfun in this case) ships the board with a firmware with calibration data already hardcoded into the pic.
as far as I know MEMS technology produces sensors with not constant behavoiur and a calibration is needed.
But this is not the case, right?
Cheers