For those of you who bought a UAV DevBoard and who also live some place too cold to fly yet, I just finished a "roll-pitch-yaw demo" that you can use to show off your board. Firmware, documentation, and more details are available in a discussion of a direction cosine matrix estimator.Also, here is the firmware and documentation.The demo is rather impressive. It is a milestone in the project that I am presently working on with Paul Bizard. It uses mostly gyro information to compute the direction cosine matrix that specifies the relative orientation of two cartesian coordinate systems. In the demo, the cosines of the angles between the axes of the board and the vertical ground axis are output to 3 servos. Roll-pitch performance is smooth, accurate, and drift-free.The demo is fun and easy to run, does not require a GPS radio, does not require you to go outside, and will impress your friends.Bill Premerlani
Fantastic, that's what I have been testing with various gyros. I have a bunch of temperature-drift profiles for about 6 gyros types. The one I am trying to use is the LPR530. The LISY300AL is surprisingly temperature stable though. The ADXRS601 has a very predictable temperature coefficient which makes it easy to correct.
I am also decimating the sampling of the LPR530 - by about 64 samples. Additionally, I am introducing a Runge-Kutta 4th order LPF to keep the noise down. I'm still not real happy about the noise levels but I would like to see how the DCM handles it. I do have a Kalman filtered solution that I want to compare the performance against.
In any case, you're done some ground breaking work with the DCM and I'm looking forward to this whole thing working out. Once, again - thanks, and merry Christmas.
We found the LISY gyros to have more noise than the Analog Devices gyros, so we raised the sampling rate by a factor of 10, and used a decimation filter, when we switched to the LISY gyros.
Regarding temperature corrections, there have been several people who have been pleasantly surprised by the "locking" behavior of the DCM algorithm. In particular, several folks have taken boards directly from cold (typically -20C) and put them under a heat lamp, without any noticeable effect at all on the performance of the board.
What happens is that the DCM algorithm drift compensation causes the algorithm to "lock" onto the accelerometer reference signals. There is an integrator in the feedback loop that forces the lock to occur with zero error. After that, unless the offset of the gyros takes a very large, instantaneous step change, the algorithm maintains the lock, even in the face of temperature changes. So it is not necessary to do temperature corrections with the DCM algorithm.
Thanks again Bill. I am actually porting this to a 12-bit ADC platform to see how things work out, hence the questions. I've found that the ADC samples can be quite noisy on my board (what appears to be up to 5-10mV of noise on the samples). I am also intending to apply some temperature corrections before inputting to the DCM routines and then to compare the output against the Kalman filtered output to see how they fare.
The RollPitch demo was developed for the green board only. It was quickly superceded by the RollPitchYaw demo, which runs on either the greenboard or the redboard.
The RollPitchYaw demo will also serve as a RollPitch demo. You do not need to modify the firmware. Simply do not connect a GPS to the board if you want to "lock" roll and pitch only. Roll and pitch will work just fine without a GPS, and then you can see what the yaw drift is without a GPS.
Thanks Bill. I have looked at the new RollPitchYaw demo and that does make sense now. I cannot, however, find an updated RollPitch demo. Is there one? Or can I just remove the adj_accel, yaw_drift and perhaps some other functions from the imu_demo to achieve the same effect? Thanks again.
Sorry, the posting that you refer to is an old one that I forgot to update. The first version of the board, the so-called "green board", used Analog Devices gyros. The link that you followed is for one of the earliest demos for that board. The gyros eventually became unavailable, and we redesigned the board, producing the "red board", which uses the LISY gyros.
Thanks for bringing this to my attention. I have updated the links in the posting, they now point to the latest versions of the demo and the documentation.
Also, you can access all of the latest firmware, documentation, and news that has been written for the board at this google project. There has been a lot of activity since February.
I am looking at the RollPitch Demo files posted in the link above - assuming that this works with the UAV Dev Board (which uses the LISY300AL or the ADXRS401). But looking at the analog2digital.c file, I am a little confused. First of all the pin assignments don't seem to agree with that of the UAV Dev Board:-
Matt,
My new "red board" just went into production at SparkFun. The only differences between it and my previous "green board" are the gyros and the accelerometer settings. The gyros are LISY300Al and I am now using the 6g setting on the accelerometers.
I am still using the EM406 GPS. Its working fine now. I finally figured out that there was a 10 second latency when you run the EM406 in the binary mode at 4,800 baud. Apparently there is an internal communications buffer that is looking for carriage returns and line feeds when it is running at 4,800. When you run it at 19,200 baud, it appears that the buffering is turned off, and the latency disappears.
Anyway, the combination of the EM406 and the direction-cosine matrix is performing quite well.
I am going to build my own board to make custom modifications.
Are you still going to develop the board with a different GPS module? If so, have you decided what GPS to use?
Regards,
Matt
Matt,
You are quite welcome.
There is nothing that you have to change in the roll-pitch demo if you change the accelerometer gain. It will work just fine as is. What will happen is that, since I do not normalize the gravity vector, you will be changing the effective feedback gain, which will not produce any noticeable change in the demo. So, you will be just fine if you leave the firmware just as it is.
Theoretically, there are a couple of changes that you should make to keep everything the same, but it would not be worth the trouble.
For the other firmware, for roll-pitch-yaw, for MatrixNav, and for AileronAssist, there are some gains and constants that should be changed because they must be correct for the centrifugal compensation to work correctly. If you are using any of those, let me know, I will tell you what to change.
Did you build your own board? (Which is fine by me.) I am not aware of any easy way to change the g setting on my board, it is wired in.
Best regards,
Bill
Comments
I am also decimating the sampling of the LPR530 - by about 64 samples. Additionally, I am introducing a Runge-Kutta 4th order LPF to keep the noise down. I'm still not real happy about the noise levels but I would like to see how the DCM handles it. I do have a Kalman filtered solution that I want to compare the performance against.
In any case, you're done some ground breaking work with the DCM and I'm looking forward to this whole thing working out. Once, again - thanks, and merry Christmas.
Daniel
We found the LISY gyros to have more noise than the Analog Devices gyros, so we raised the sampling rate by a factor of 10, and used a decimation filter, when we switched to the LISY gyros.
Regarding temperature corrections, there have been several people who have been pleasantly surprised by the "locking" behavior of the DCM algorithm. In particular, several folks have taken boards directly from cold (typically -20C) and put them under a heat lamp, without any noticeable effect at all on the performance of the board.
What happens is that the DCM algorithm drift compensation causes the algorithm to "lock" onto the accelerometer reference signals. There is an integrator in the feedback loop that forces the lock to occur with zero error. After that, unless the offset of the gyros takes a very large, instantaneous step change, the algorithm maintains the lock, even in the face of temperature changes. So it is not necessary to do temperature corrections with the DCM algorithm.
Best regards,
Bill Premerlani
Daniel
The RollPitch demo was developed for the green board only. It was quickly superceded by the RollPitchYaw demo, which runs on either the greenboard or the redboard.
The RollPitchYaw demo will also serve as a RollPitch demo. You do not need to modify the firmware. Simply do not connect a GPS to the board if you want to "lock" roll and pitch only. Roll and pitch will work just fine without a GPS, and then you can see what the yaw drift is without a GPS.
Best regards,
Bill Premerlani
Daniel
Sorry, the posting that you refer to is an old one that I forgot to update. The first version of the board, the so-called "green board", used Analog Devices gyros. The link that you followed is for one of the earliest demos for that board. The gyros eventually became unavailable, and we redesigned the board, producing the "red board", which uses the LISY gyros.
Thanks for bringing this to my attention. I have updated the links in the posting, they now point to the latest versions of the demo and the documentation.
Also, you can access all of the latest firmware, documentation, and news that has been written for the board at this google project. There has been a lot of activity since February.
Best regards,
Bill Premerlani
yrate.input = - ADCBUF0 ;
zrate.input = ADCBUF1 ;
xrate.input = ADCBUF2 ;
vref.input = ADCBUF3 ;
xaccel.input = ADCBUF4 ;
yaccel.input = ADCBUF5 ;
zaccel.input = ADCBUF6 ;
Secondly, the Vref input seems to suggest that this code was meant to work with a gyro like the LPR530 rather than the LISY300AL.
Lastly, there doesn't seem to be any scaling to the 3.3V line which was mentioned here and there.
Can someone help me understand if I am looking at the wrong boards? Thanks.
Daniel
My new "red board" just went into production at SparkFun. The only differences between it and my previous "green board" are the gyros and the accelerometer settings. The gyros are LISY300Al and I am now using the 6g setting on the accelerometers.
I am still using the EM406 GPS. Its working fine now. I finally figured out that there was a 10 second latency when you run the EM406 in the binary mode at 4,800 baud. Apparently there is an internal communications buffer that is looking for carriage returns and line feeds when it is running at 4,800. When you run it at 19,200 baud, it appears that the buffering is turned off, and the latency disappears.
Anyway, the combination of the EM406 and the direction-cosine matrix is performing quite well.
For example, take a look at Scouser's experience.
Best regards,
Bill
Are you still going to develop the board with a different GPS module? If so, have you decided what GPS to use?
Regards,
Matt
You are quite welcome.
There is nothing that you have to change in the roll-pitch demo if you change the accelerometer gain. It will work just fine as is. What will happen is that, since I do not normalize the gravity vector, you will be changing the effective feedback gain, which will not produce any noticeable change in the demo. So, you will be just fine if you leave the firmware just as it is.
Theoretically, there are a couple of changes that you should make to keep everything the same, but it would not be worth the trouble.
For the other firmware, for roll-pitch-yaw, for MatrixNav, and for AileronAssist, there are some gains and constants that should be changed because they must be correct for the centrifugal compensation to work correctly. If you are using any of those, let me know, I will tell you what to change.
Did you build your own board? (Which is fine by me.) I am not aware of any easy way to change the g setting on my board, it is wired in.
Best regards,
Bill
-
1
-
2
of 2 Next