I'm not sure whether I should post it here, but I feel that the problem I have been struggling with might be of interest for those of you who would like to squeeze out more functionality from SFE's Razor 9DOF.
The starting point of the story is the AR7212, a 12 channel receiver with autopilot extensions for the Spektrum DX7. More at: http://www.mcselec.com/index.php?option=com_content&task=view&id=261&Itemid=57. Although the AR7212 board has dedicated ports for thermopile sensors I became interested in feeding in Euler angles directly from a suitable module - mainly because I don't like sensors on the outer skin of gliders like Alpinas, etc. The AR7212 is AT1280/2560-based and thus has 4 UARTs. I use two of them for the Spektrum satellites, one for a sensor gadget called Unilog (very popular in Germany and approved for competition. It brings in barometric altitude, temperature, airspeed, battery voltage, system current and more). The forth for telemetry. So I was missing two further ports, one for GPS and one for the Euler angles.
I can imagine that the way I solved it is not new and that I just miss the technical term for it. Here it is at the HW side: Connect GPS TX to RX of the Razor. Connect the Razor's TX to the AR7212-RX (UART1). Connect the AR7212-TX to the telemetry radiomodem (HAC UM9600). This way you have 3 gadgets on one port.
Here is the drawback: The bottleneck of such a "serial chain" is that the whole is limited by the comm speed of the slowest device - in my case the UM96.
The solution was GPS + Euler angle data compression. I ported Doug Weibel's/JJulio's Razor implementation of Bill Premerlani's DCM to Bascom and did the following changes:
''**************************** Changed in Bascom *******************************
''(1) No free running ADC interrupting the program, instead: Single ADC and
'' averaging is done when main loop is not busy with DCM, GPS, KIX. Sampling
'' of the three analog sensors (gyros) occurs around 7 times per 20 ms cycle,
'' 16 times when KIX and GPS processing is disabled (for comparison). Timebase
'' from 16-bit Timer1 at 1µs resolution. Code philosophy: "Let it flow (nobody likes
" work interrupts;-)), but know the time precisely". Well - at least Bascom doesn't
" like very much interrupting.
''(2) General overwritables instead of local variables. This needs more care
'' during coding but saves the processor from avoidable stack pushs and pops.
''(3) Bascomized variants of Arduino commands for ADC and I2C operations.
''(4) 1D equivalents for Matrix operations as described in AN#176 at MCSelec
'' (Mini Matrix Algebra)
''(5) Kixline support for GPS and Euler Angles as described in AN#174 at MCselec
'' (Kixlines - Tetrasexagesimal number compression to speed up serial communi-
'' cations)
''(6) AR7212x compatibility (AN#172)
''
''******************************************************************************
The result is that we have a 50 Hz stream of Euler angles plus 2 Hz GPS plus speed extraction for centrifugal acceleration correction from the 9DOF razor - without any HW change. The code mods
taken together with the DCM part occupy 50% of the 328 flash.
The GGA + RMC excerpt (not localized - but for the whole planet) takes 25 chars when kixlined at
"full" GPS accuracy (20 cm resolution) - compression to around 20%. It includes the full set of information except geoid hight. When "localizing" latitute, longitude, altitude, and just including heading and speed over gnd, the compression goes down to 10% of NMEA.
I'm not sure whether another AN should follow - but anybody interested can have this portation.
Thanks to Bill (Premerlani) for really great stuff !!! - followed by a question: Is there any reason why not taking:
speed = Sqr (sog^2 + (dAltitude/dt)^2) instead of sog = speed over ground
for centrifugal accel correction? The GPS altitude is drifty and noisy - but at speeds around 20-30 m/s it should be better than nothing..
Regards,
Natalius
PS: Here is how the whole looks:
AR7212 + Razor 9DOF + Unilog + HAC UM96 + EB-85A is the flying sausage in the middele. Keen to see it in the air next weekend.
Replies
the configuration crashed last weekend - the sausage is gone. While on Saturday we tested the basic AR7212 functionality - and it worked even forgetting about a range test - just perfectly - on Sunday we tested the DCM-autopiloting with the Kixrazor. The sad part is that I lost an LDXXL - the good part is that I know the kixline documented reason why.
It was a death spiral - faster and and more rapid you can imagine on an MPX EZ* - the LDXXL is not a performance glider, just a glider for the average pilot. I don't consider myself as an average pilot - well some say in my club that my flying style is like paying mortgage;-) - but nevertheless I was able to rescue things in an experimental emergency in many cases.
Not in this case. So what was the reason? Kixed flight log revealed that Bill Premerlanis's DCM was working perfectly fine but that I myself had build the most idiotic way to do autotrim in the air. The last one (in the panic) just "stabilized" death spiralling.
Cest la vie,
Natalius
Perhaps it is easier to imagine one's aircraft flying within a stationary volume of air, with the ground moving at a constant velocity below.
Andrew.
Another point I forgot to cover...
Recently several people have asked if it would be possible to do the DCM computations without measuring the speed at all.
So, Paul Bizard did some simulations where the speed used in the centrifugal compensation calculations was a constant, assumed speed. It turned out that although there was some error, DCM based control was still very stable. So, obviously, the accuracy of the speed estimate in the centrifugal compensation is not all that critical.
What Paul found out was that if you want to simply assume a constant speed, it is best to err on the high side. He found that if you did that, the errors that were made as a result actually improved the stability of the controls. In the case of neutrally stable planes with ailerons, the improved stability made the aircraft much more resistant to going into a "death spiral" due to pilot error. What would happen was that the errors made in the centrifugal compensation, if you overestimate speed, tend to turn the plane out of a spiral, and back toward a straight line.
If you underestimate the speed, there is not as much resistance to the spiral, but Paul found that there was enough, in any case, to make the stabilized flight characteristics very pleasant.
In all cases, the pitch accuracy is rather good, since it does not depend much on the centrifugal effects.
Best regards,
Bill
Well done. Very good. Very impressive. Sounds like you are having lots of fun.
Regarding your question about what speed to use in the calculation of centrifugal effects...
The short answer is, you should include vertical velocity.
Now, the long answer....
FIrst, I should refer you to something I wrote a couple of months ago regarding a technique for estimating wind speed without a pitot sensor, because it is relevant to your question.
Also, a few months ago, I realized that it is 3D air speed, not 3D ground speed, that should be used in centrifugal calculations. It seems strange, but it is true, and has been independently verified. So, we have implemented a method for estimating airspeed and wind speed.
Back to your question: The correct speed to use in the centrifugal calculation is the square root of the sums of the squares of the three components of the air speed vectors.
The older versions of the UAV DevBoard firmware (MatrixNav and Aileron Assist) use speed over ground for centrifugal calculations. We ignored the vertical component of speed over ground for two reasons:
1. We intended for the planes to be flying mostly level most of the time.
2. The vertical component of ground velocity (daltitude/dtime) includes thermals and slope lift, and that does not contribute to centrifugal effects.
The latest version of the UAV DevBoard firmware (MatrixPilot), is evolving. It currently uses the air speed vector for centrifugal calculation. I am not sure whether it uses the vertical component of the air speed vector or not, but if it does not, we will eventually revise it to use all 3 components of the airspeed vector.
There have been literally 1000s of flight hours logged with the various versions of MatrixNav, Aileron Assist, and MatrixPilot, with great results, so I don't think the various approximations we have made along the way have caused any problems. Some pilots have been hovering their planes vertically with firmware that the team has been developing lately.
For more information, take a look at the uavdevboard website and discussion group.
Best regards,
Bill