I've been thinking a lot lately about how cool it would be to implement inertial dead reckoning on ArduCopter for a gps-free loiter mode of sorts. I just wanted to get some discussion going from people who have studied this or have tried implementing it, as I know it is difficult.
To begin with, this is a good read about getting position from accelerometer data: http://perso-etis.ensea.fr/~pierandr/cours/M1_SIC/AN3397.pdf
So my thoughts are that we could integrate the acceleration reading from the accel, subtracting out the acceleration due to tilt angle (we can do this since we have a nice filtered angle reference, or gyro integration). This, once filtered nicely, should give us a pretty good reading of lateral velocity. Once that was accomplished, we do one more integration, and obtain lateral position. Since all we really need for position hold is a relative position, we could experiement with resetting the position integration at some time interval (or every time the sticks are released) to keep our drift error down. How cool would this be if it actually worked?!!
I am thinking to buy an ArduIMU v3 just to play around with this to see if I can get a robust measurement.
Please chime in on this! If this worked even remotely well, there may no longer be a need for optical flow, or even sonar (as we could get relative Z position too)!
-Jamie
Comments
http://instk.org/blog/?p=107
The above blog is dedicated to inertial navigation, and the specific link is to a post describing a novel approach to these problems of drift.
Most of my efforts towards improving dead reckoning have been in pursuit of low cost position or velocity reference sensors which can supplement the inertial data. The two areas which seem the most promising are optical flow/optical odometry & "Acoustic Doppler velocimetry"
Another thought is that in some cases, the vehicle attitude may be able to give clues about velocity. A plane performing a prop hanging maneuver or traditional helicopters being good examples.
@Biggles from Monday - Yes, that's true, but the equipment on the pre-ring laser gyro transport category aircraft had very low gyro rate biases/offsets by design. VG/DG (vertical gyros/directional gyro) technology relied on precision bearings or air/nitrogen gas bearings to reduce drift to acceptable navigation levels. MEMs gyros and accelerometers can have significant biases or offsets. MEMS-equipped Standby Instrument Systems used today can provide pitch, roll and heading but not lat/long.
Hi guys!
I think we should back to talk about INERTIAL dead reckoning :)
I'm currently implementing my own vertical velocity damping mechanism.
The main idea is to reduce vertical position drift of the quad in STABILIZE mode. This drift occurs of air pressure fluctuations over the flight space. I'm trying to compensate this negative effect by applying "damper" depending on vertical speed. The value of damping should be dependent on input_throttle(implemented) and weight/lift_power ratio of the every particular quad (not implemented yet). The weight/lift_power ratio can be calculated via "take off throttle" (the value of throttle at the take off moment). Also we can use this weight/lift_power ratio to calculate Alt_Hold.P parameter automatically for every single quad ;) .
Please take a look at my implementation:
Arducopter.pde : update_throttle_mode()
g.rc_3.servo_out = g.rc_3.control_in + get_z_damping(g.rc_3.control_in) + angle_boost;
Attitude.pde
static float Z_offset = 0;
static int16_t get_z_damping(int16_t in_throttle)
{
static float Z_integrator = 0;
static float Z_accel_prev = 0;
static float Z_accel = 0;
int16_t output;
float damper = 0;
#define THR_DAMP_THRESHOULD 0
#define DAMP_DOWN_GAIN 2.5
#define DAMP_UP_GAIN 0.5
#define INTEGRATOR_WEIGHT_REDUCER 0.85
Z_accel = get_world_Z_accel() - Z_offset;
Z_integrator += (Z_accel + Z_accel_prev)/100; // /100 = 2*dt_50Hz
Z_accel_prev = Z_accel;
if(Z_integrator >= THR_DAMP_THRESHOULD)
{
// Copter is going DOWN
damper = Z_integrator * DAMP_DOWN_GAIN ;
}
else if(Z_integrator < -THR_DAMP_THRESHOULD)
{
// Copter is going UP
damper = Z_integrator * DAMP_UP_GAIN;
}
Z_integrator = Z_integrator * INTEGRATOR_WEIGHT_REDUCER;
output = (float)in_throttle * damper;
//NM
//Serial.printf("\naz_int %d", output);
return output;
}
float get_world_Z_accel()
{
//NM
Vector3f accels_rot = ahrs.get_dcm_matrix() * imu.get_accel();
//Serial.printf("z %1.4f\n", accels_rot.z);
return accels_rot.z;
}
static void init_z_damper()
{
Z_offset = 0;
for (int16_t i = 0; i < NUM_G_SAMPLES; i++)
{
delay(5);
read_AHRS();
Z_offset += get_world_Z_accel();
}
Z_offset /= (float)NUM_G_SAMPLES;
}
The DAMP_DOWN_GAIN should be exactly dependent on weight/lift_power ratio. The INTEGRATOR_WEIGHT_REDUCER involved to reduce drift of integration caused by noisy data from accelerometers. Of course it reduces the accuracy of integration, but keeps integrated value near zero while no vertical accelerations occur. My current implementation works! It keeps quad from abrupt flips and reduces vertical drift well. The next step is to combine data from accelerometers and barometer to gain the accuracy of climb calculation. Please comment my idea, any suggestions and objections are welcome.
Er, I meant carrier phase data.
Re: differential GPS, don't you need one that processes carrier wave data rather than just code data from the satellites? Or do these new dual band micro antennas setups do that?
Wow! <20mm is great (<100 is enough) if it is possible to implement in a small equipment like APM. Now we are speaking about meters. Recalc rate is limited by the controller's clock (APM) ? Good luck in your work.
Michael Oborne (creator of the mission planner) has been looking at RTK a bit. We certainly don't have a problem getting information from the ground station to the copter (we have 3dr radios, etc). The issue seems to be something to do with getting the data from the ublox into the right format.
Yip, the survey GPS systems (RTK Systems) works on the following basis: You have a base receiver setup over a known point. This remains static during the survey. The X, Y and Z of this receiver is known(for discussion purposes). It receives sattelite signal(GPS, GLONASS, ect) and transmits a correction message to the roving receiver. Various formats of this message exists - RTCM ver xxx is the most common. The rover receiver (non static receiver) uses the message from the base to achieve a RTK (real time kinematic) fix. This is usually youre 10mm+10ppm accuracy fixes.
Yes, the hardware weighs much more since it is ruggedised and has battery solutions that can last 8 hours plus. It might weigh up to 3kg, but if you carry it around for 7-8 hours it feels like 300kg. Today's (common) survey systems receive L1 and L2 signals(and a few more). The GPS in your car receives only L1. L1 (1575.42 Mhz) and L2 (1227.60 MHz).
The fellas from Trimble have released some good micro(L1, L2) antennas and have some good smallish L1&L2 OEM receiver chips (Expensive - a common demand and supply issue).
A Japanese crowd developed a opensource project called openrtk that uses off the shelve receivers (like ublox 6T) to get a RTK fix(sounds great, but has limitations - good paper on GPS). The challenge is getting a correction from a base station to the rover receiver(Update rate 1Hz). Some goverments have networked bases and supplies the correction via a NTRIP caster(Internet)....Sorry, I'm waffeling.
Short answer - yes, it can be done (<20mm in the air). I'm working on a heavy lift hex to prove the principle.
A problem I see with using GPS as a primary accurate sensor is the update rate(true 1-10hz recalc rate).
As I know topographists are using GPS and they have accuracy less then 1 cm. Last year I had an opportunity to see this with my eyes, making land measurements. What is the reason we have accuracy at meter level? It is the antenna? The GPS signal is there "in the air". It's true their equipment has a few kg not 20g.
I would think that this is something the military put billions and billions of dollars not to mention manpower int into. If you think about it, it was probably near the top of wish list for several decades at least. The advent of GPS Makes it a hell of allot easier though.
I mean think about, when they made the shift from bombers to ICBM's, They had to send Missile 2000 miles or more and have it hit within 15 miles of it's target. That's no easy task. Not to mention subs. I imagine the Subs got much easier as they mapped the sea floor. That with an occasional ping off a known "landmark" fed into the computer would help keep them on track.
Please believe me when I say that I'm not trying to associate drones with weapons, I only bring it up because when I was thinking of any other applications that might have spurred research in this area. And that is the main one I can think of.
On the subject of GPS and the military though, It wasn't until Clinton was in office that they started allowing the public to have accurate GPS data. Before that I think there was like a 50ft margin of error in Public GPS Data. It also kind of makes me wonder if certain "secure" areas have the same kind inaccurate GPS data. Say around the White house or something.
-
1
-
2
-
3
of 3 Next