Hi guys,

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.




You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Hi all,

    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
    why.it
    This domain may be for sale!
  • A volume of air moving at a constant velocity is an inertial frame of reference.

    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.
  • T3
    Natalius,

    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
  • T3
    Hi Natalius,

    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
This reply was deleted.

Activity

DIY Robocars via Twitter
RT @chr1sa: Just a week to go before our next @DIYRobocars race at @circuitlaunch, complete with famous Brazilian BBQ. It's free, fun for k…
yesterday
DIY Robocars via Twitter
How to use the new @donkey_car graphical UI to edit driving data for better training https://www.youtube.com/watch?v=J5-zHNeNebQ
Nov 28
DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
Nov 26
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
Nov 25
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Nov 23
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord: https://discord.gg/EPsZHkg9Nx) https://t.co/PNDewvJdrb
Nov 23
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
Nov 23
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar https://www.youtube.com/watch?v=9yy7ASttw04
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge https://t.co/nZQTff5…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉 https://t.co/NtKnO…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch http://indyautonomouschallenge.com/stream
Oct 23
More…