www.aerialrobotics.eu/altigps/altigps-en.pdfwww.aerialrobotics.eu/altigps/altigps-it.pdfWorks as a GPS translator or standalone.17x28mm.the output is ASCII, NMEA or binary.Contrary to the other solutions, this is the ALTITUDE SENSOR, not just a pressure sensor.The whole job of callibrating, calculating reverse formulas and sensor testing has been done.The idea is that you might have hard time trying to fit altimeter and all associated arithmetic inside current ArduPilot. Nothing easier than parsing ASCII or plugging the module as GPS translator.PLS contact me on kbosak@box43.pl for details.
I have read this. Agree. They need an altitude reference so instead of calibrating to 0 altitude they calibrate to GPS altitude. Nice, but in deep turns with 2G accelerations the GPS behaves so bad that it floats all around by 20m. This continuous baro-GPS coupling is good for long flights with moderate dynamics. For high dynamics typical to small planes, baro-only is more reliable.
Usually I would prefer to be able to make 20 flights all starting at the same field and get the same altitude result, regardles on what GPS claims to be the ground level.
"Q: Can you explain the alti to pressure and pressure to alti mapping?"
Unfortunately, no. This is a commercial product, invested in the research by myself.
It is expected to provide income for UAV research.
"Do you mean that you first set up a table (for example by precalculation) that give the absolute pressure as a function of altitude."
I used specifically developed floating point formula that approximates the whole exponential-based expression so that the fit error withing the whole alti range doesnt exceed around 10cm. The table approach usually needs and interpolation that given the uC resources, was estimated to give some 50cm error and most importantly would eat a lot of uC space. My flopoint formulas give smooth derivative of residual error fit, and thus are better for anything that makes feedback control loop. All this is theoretical, however, as the pressure noise is usually higher than numerical noise from interpolation artifacts, and the most limiting factor for feedback control loop is update rate.
"For ground calibration, you need a pair: alti to pressure and pressure to alti mapping."
Q: Can you explain the alti to pressure and pressure to alti mapping?
Do you mean that you first set up a table (for example by precalculation) that give the absolute pressure as a function of altitude.
Then you measure the absolute pressure using the pressure sensor (corrected for the different factors that are mentioned). You then use the measured pressure as an index into the table that was precalculated above. You offset by the AGL zero point.
BTW sensor die temperature is withing 2-3 deg agains air temperature, but it lags the airtemp somwheat.
The die temperature correction for the sensor pressure output is done in realtime.
In the troposphere region, a pair of PV=nRT - derived exponential formula is used.
For ground calibration, you need a pair: alti to pressure and pressure to alti mapping.
Above troposphere, a corresponding set of equations is used for tropopause region. Plus there is some math in order to guarantee smooth transition between the two. The sensor is barely working at that altitude, for sure (at limits of its spec).
The code is directly derived from more complex project.
The code is corrected for sensor die temperature which is a major factor for presure sensor drift. The altitude formula is not corrected for air temperature as the drift is negligible agains typical pressure variation due to weather change. The device always choses ground level as 0 level reference (this gives approx. AGL measurement over flatland).
"The whole job of callibrating, calculating reverse formulas and sensor testing has been done."
Q: What formulas do you use? What do you mean by reverse formulas?
Do you correct for air temperature, sensor die temperature, baselevel barometric pressure in millibars? Do you have a groundlevel set switch that sets zero ground level (relative level)?
Have you done a PV = nRT implementation?
Comments
Usually I would prefer to be able to make 20 flights all starting at the same field and get the same altitude result, regardles on what GPS claims to be the ground level.
UFO_MAN
Unfortunately, no. This is a commercial product, invested in the research by myself.
It is expected to provide income for UAV research.
"Do you mean that you first set up a table (for example by precalculation) that give the absolute pressure as a function of altitude."
I used specifically developed floating point formula that approximates the whole exponential-based expression so that the fit error withing the whole alti range doesnt exceed around 10cm. The table approach usually needs and interpolation that given the uC resources, was estimated to give some 50cm error and most importantly would eat a lot of uC space. My flopoint formulas give smooth derivative of residual error fit, and thus are better for anything that makes feedback control loop. All this is theoretical, however, as the pressure noise is usually higher than numerical noise from interpolation artifacts, and the most limiting factor for feedback control loop is update rate.
"For ground calibration, you need a pair: alti to pressure and pressure to alti mapping."
Q: Can you explain the alti to pressure and pressure to alti mapping?
Do you mean that you first set up a table (for example by precalculation) that give the absolute pressure as a function of altitude.
Then you measure the absolute pressure using the pressure sensor (corrected for the different factors that are mentioned). You then use the measured pressure as an index into the table that was precalculated above. You offset by the AGL zero point.
Something like that?
UFO_MAN
The die temperature correction for the sensor pressure output is done in realtime.
For ground calibration, you need a pair: alti to pressure and pressure to alti mapping.
Above troposphere, a corresponding set of equations is used for tropopause region. Plus there is some math in order to guarantee smooth transition between the two. The sensor is barely working at that altitude, for sure (at limits of its spec).
The code is directly derived from more complex project.
The code is corrected for sensor die temperature which is a major factor for presure sensor drift. The altitude formula is not corrected for air temperature as the drift is negligible agains typical pressure variation due to weather change. The device always choses ground level as 0 level reference (this gives approx. AGL measurement over flatland).
"The whole job of callibrating, calculating reverse formulas and sensor testing has been done."
Q: What formulas do you use? What do you mean by reverse formulas?
Do you correct for air temperature, sensor die temperature, baselevel barometric pressure in millibars? Do you have a groundlevel set switch that sets zero ground level (relative level)?
Have you done a PV = nRT implementation?
UFO_MAN
-
1
-
2
-
3
of 3 Next