Data conversion onboard or at the ground station?

[skogsvargen]

As a first step in my autopilot project i have designed an Air speed and Altitude module.

When i implemented the pressures to speed and altitude i thought "why am i doing this?". The autopilot does not care if it is flying at 3000 feet or 437 mV. If i do all conversions that requires floating point maths in the ground station and then back to "sensor units" before i send them to the UAV i will save valuable resources onboard.

In some situations it will be a problem with nonlinear values. A decent rate will for example not be the same at all altitudes, but for all "hold" modes (Altitude hold and speed control) i guess it will work. Also comparing my IAS with a GPS SOG will of cource be a problem.

What is your view on the subject? Is it worth the CPU needed to do the calculations in air?

/Magnus

[Tom Harper]

Magnus,

Anything you can do on the ground unburdens the processor. Can you give us some details of your airspeed and altitude module?

[poynting]

Generally, it just makes the math more intuitive in the autopilot code. It's alot easier to read if(airspeed>10mph) than if(airspeed>345mv). It also makes the control loop equations and gains make more sense, but if you're careful, all of your scaling could be on the ground.

Also, if you want this to run fast on the aircraft, you would generally not use floating point, but fixed point instead. That is, unless your autopilot processor is very over-powered, but if that were the case I imagine you wouldn't be asking this question.

[Unterhausen]

If you are processor limited, by all means use native units. You can certainly cause all sorts of problems that way. Some calculations are a real pain if you can't use floating point.

[JettPilot]

With the power of processors today, I cannot immagine why you would want to do those conversions on the ground. Sounds like a really bad idea to me :mad: ... It would be much easier and better just to use a processor that can handle the math on the plane, they are cheap and small...

JettPilot

[skogsvargen]

I am using an ATMEGA44 so power is not really an issue. Especially since the Altimeter/IAS board has it's own CPU. Still,when i'm doing the floating point maths the program eats memory quick since i need to square root calculations to get speed from pressure. I am not that good at integer maths, but if someone can give me an hint on how to do pressure to speed calculations in integer math i would be greatful.

I will try to post the schematics of this first module as soon as i get the hang of my cad program, but basically its two MPX pressure sensors one 4115 for absolute pressure and one 5010 for differential pressure. The 4115 is amplified to give me 12 bit resolution between 0 and 6000 feet. The 5010 is sampled with the ATMEGAs internal 10 bit AD. I am using the internal ref (1,1V) which makes it possible to meassure speeds up to 56 m/s (approx. 100 knots).

At the moment the board communicates over a serial line, but the goal is to make it work as an I2C slave. This way I can have all my sensors on a I2C bus.

I have also built a servo failsafe and controller. It receives 8 servo control signals over a serial line (maybe I2C later) or the R/C receiver and takes an R/C control signal to switch control.

It would be interesting to see if there is an interest in developing a protocol that would make it possible to attach sensors and control boards in a standard way... I thing i'll get back to that!

/Magnus

[LukeZ]

Another potential problem with offloading some of your computations to the ground station is that you are then reliant on your communications link. Which may or may not be a problem, depending on the application. But as you've chosen to keep it all onboard, you don't need to worry about it.

Sounds like you're doing good work. Keep us posted.


Luke

[Unterhausen]

calculations are still done on the aircraft. The part about doing the calcs on the ground station is pre-processing things that have real-world units into the units that are used on the aircraft.

I'd have to think about things like speed that have a non-linear term in them. You could linearize them over the small range of speeds. An ATMega will do a few floating point calcs without any problems, but I suspect you could overload it fairly easily with a full-blown autopilot.

[skogsvargen]

No i can't rely on a working downlink. What i ment was that i only need real world units when a human is looking at the values. the AP would be flying the plane in local units.

What i am doing right now is switching from Bascom to GCC for development. This way i can produce more efficient code and hopefully have place for the floating point math. My design is based on that every sensor board has its own processor to do sampling conversion and communications. So I think i will be ok if I just can get inte C-programming.

If anyone can share som c-code for unit pressure/speed/altitude conversion it would be a good start.

/Magnus

[LukeZ]

I have a very small C code file posted on my site here (http://www.kansasflyer.org/index.asp?nav=Avi&sec=Alti&tab=Code). It has altitude formulas. There is a tutorial to explain my process, but I didn't really post that much code-wise. I may be able to provide you with some more meaningful stuff if you let me know what you're looking for exactly.

Luke

[skogsvargen]

Thanks, I looked at the code and it will definitly savef me some time. I am also looking for an implementation of the pressure to speed formula, not as hard since i have decided to work with floating point math, but if you would like to share it i'm grateful. In my tests with Basic it was very hard to get any god speed readings at low speeds (below 10 knots) with my sensor since the differential pressure is so small. On the other hand i will only be using the 0V to 1V range, but amplifying the signal will not help much. My plane will have stalled long before i go under 15 knots anyway :)

/Magnus

[LukeZ]

Magnus,

Try this. This converts a differential pressure (in kPa units) into kilometers per hour. You could also just pass pascals and discard the "multiply by 1000" bit. But kPa is what I've been dealing with in my code.

If you want to see some examples of this formula with numbers, you can look here (http://www.kansasflyer.org/index.asp?nav=Avi&sec=Asi&tab=Theory&pg=10).

- Not sure how well this code will paste - if you want me to send you a C file, pm me.


Luke


/************************************************** ************************************************** ****
* Function Name: DeltaP_To_KPH *
* Return Value: Airspeed in kilometers per hour *
* Parameters: DeltaP - current differential air pressure between static and pitot (kPa) *
* Description: Here we calculate current airspeed in kilometers per hour (KPH) * *
************************************************** ************************************************** ****/
unsigned float DeltaP_To_KPH(unsigned float DeltaP)
{

DeltaP = sqrt( ((2 * DeltaP * 1000) / 1.225) ); // DeltaP is now equal to velocity in meters/second
// Since DeltaP is passed to us in kPa we multiply by
// 1,000 to get Pascals.

DeltaP *= 3.6; // Convert to KPH - 3600 seconds in an hour,
// 1000 meters in km, so 3600/1000 = 3.6 multiplier.

// Since this is an unsigned function, we discard negative values
if (DeltaP < 0)
DeltaP = 0;

return DeltaP; // Of course by now it's no longer DeltaP but KPH
}

[skogsvargen]

Worked almost unchanged in AVR-GCC. All i had to do was to remove the Unsigned keyword from the float type. I still have to learn have to access the A/D but now i'm making progress. Thanks!

I also got confirmation that my Gyros, accelerometers and GPS was shipped from Sparkfun today so you can expect more questions shortly. :)

Magnus the C-hacker

[LukeZ]

"C-hacker", ;)

Good for you! C is not that bad, if you already know any other languages. Yes, even Basic would count as good experience. The good thing about learning C is that you will then be pretty much able to program in several other languages, such as JavaScript and even PHP to an extent, which are very similar.

In my experience, it's figuring out how to even get the programmer interfaced with your microncontroller, and learning all the quirks of memory allocation and such, that is more difficult than the actual job of writing your program, once you get down to it.


Luke

[skogsvargen]

Thank's Luke. I have allready programmed the AVR chips in Basic so the PC->Programmer->cpu is working and i think i'm getting the hang of the AVR architecture.

My native language is Pascal (Delphi) and i have done some work in Java so the transition to C shouldn't be to bad.

Once I have the Altitude/IAS board working with the C program I will let you know.

[LukeZ]

I'll be looking forward to it. Nice to see others making so much progress on their projects. This forum has really taken off this year!


Luke