Intertial Navigation: Why don't we have it?

[dwallersv]

Wanted to started a discussion on this, and if my initial thoughts about it are correct, maybe get DJI to add this to the firmware.

A first-pass pondering of what is necessary to support pure inertial navigation functionality is that we have what we need: A sensitive, fairly precise 3-axis gyro, and 3-axis accelerometer (really the same actual sensor).

This is all that is needed to sense translations and rotations in 3-space, given an initial location.

Now, why do I bring this up?

There have been a spate of stories on the board recently of aircraft being lost due to inexplicable erratic behavior. In almost all cases, when the AC goes out of control it's experiencing one or some combination of auto switching to ATTI mode, loss of GPS and satellites, confused compass readings vs. heading and course, and other failures that all affect self-navigation by the aircraft, as well as information necessary to hold position.

Both of these requirements can be met with inertial navigation alone. Given location current speed vector, the IMU presents all the necessary data to calculate position continuously.

The solid-state IMU in our aircraft is certainly not accurate enough to rely on for very long for navigation. There are sufficient errors and noise in the measurement that these will accumulate fairly quickly and the actual location of the aircraft will be so far off as to render it just as lost as with no Nav input,

However, this is not the point. It is certainly precise enough for a few minutes. The time it takes to accumulate significant errors also is a function of how much and how fast its position is changing. Therefore, if it stops and hovers in place, while it will drift around a little bit over time, it will stay in the same area (say, 20m circle, a popular DJI radius ), for a long time. Perhaps longer than a full battery could hover -- we'd have to do a more detailed analysis using the specs for the IMU hardware to really know, but I don't need to do that to estimate with high certainty that its an eternity in terms of dealing with an emergency.

So, all that said, why doesn't the firmware fall back on the IMU as a backup nav system when GPS and the compass fail? The calculations are not difficult or complex. Certainly this is easy to code. It certainly could save drones in many of these situations, stopping and hovering in place when the error occurs switching to the new INS mode, alerting the pilot.

Then, they can fly the bird away from the interference -- if that's the problem -- and regain normal GPS navigation. Or, they can bring it home. Given the known error parameters for the IMU, the AC can even estimate the accumulating error while its flying, and draw a circle around the AC on the map display showing where its estimated to be.

Again, all this is really simple software, and would save many situations where the aircraft as it stands now goes out of control and sometimes is a total loss.

What do you all think?

 

[Philltayl]

Wanted to started a discussion on this, and if my initial thoughts about it are correct, maybe get DJI to add this to the firmware.

A first-pass pondering of what is necessary to support pure inertial navigation functionality is that we have what we need: A sensitive, fairly precise 3-axis gyro, and 3-axis accelerometer (really the same actual sensor).

This is all that is needed to sense translations and rotations in 3-space, given an initial location.

Now, why do I bring this up?

There have been a spate of stories on the board recently of aircraft being lost due to inexplicable erratic behavior. In almost all cases, when the AC goes out of control it's experiencing one or some combination of auto switching to ATTI mode, loss of GPS and satellites, confused compass readings vs. heading and course, and other failures that all affect self-navigation by the aircraft, as well as information necessary to hold position.

Both of these requirements can be met with inertial navigation alone. Given location current speed vector, the IMU presents all the necessary data to calculate position continuously.

The solid-state IMU in our aircraft is certainly not accurate enough to rely on for very long for navigation. There are sufficient errors and noise in the measurement that these will accumulate fairly quickly and the actual location of the aircraft will be so far off as to render it just as lost as with no Nav input,

However, this is not the point. It is certainly precise enough for a few minutes. The time it takes to accumulate significant errors also is a function of how much and how fast its position is changing. Therefore, if it stops and hovers in place, while it will drift around a little bit over time, it will stay in the same area (say, 20m circle, a popular DJI radius ), for a long time. Perhaps longer than a full battery could hover -- we'd have to do a more detailed analysis using the specs for the IMU hardware to really know, but I don't need to do that to estimate with high certainty that its an eternity in terms of dealing with an emergency.

So, all that said, why doesn't the firmware fall back on the IMU as a backup nav system when GPS and the compass fail? The calculations are not difficult or complex. Certainly this is easy to code. It certainly could save drones in many of these situations, stopping and hovering in place when the error occurs switching to the new INS mode, alerting the pilot.

Then, they can fly the bird away from the interference -- if that's the problem -- and regain normal GPS navigation. Or, they can bring it home. Given the known error parameters for the IMU, the AC can even estimate the accumulating error while its flying, and draw a circle around the AC on the map display showing where its estimated to be.

Again, all this is really simple software, and would save many situations where the aircraft as it stands now goes out of control and sometimes is a total loss.

What do you all think?

I think that owners should learn to 'FLY' the things.

 

[dwallersv]

I think that owners should learn to 'FLY' the things.

Do you have anything useful to contribute to the discussion?

 

[Philltayl]

Do you have anything useful to contribute to the discussion?

I just did...........

 

[Richard R]

Wanted to started a discussion on this, and if my initial thoughts about it are correct, maybe get DJI to add this to the firmware.

A first-pass pondering of what is necessary to support pure inertial navigation functionality is that we have what we need: A sensitive, fairly precise 3-axis gyro, and 3-axis accelerometer (really the same actual sensor).

This is all that is needed to sense translations and rotations in 3-space, given an initial location.

Now, why do I bring this up?

There have been a spate of stories on the board recently of aircraft being lost due to inexplicable erratic behavior. In almost all cases, when the AC goes out of control it's experiencing one or some combination of auto switching to ATTI mode, loss of GPS and satellites, confused compass readings vs. heading and course, and other failures that all affect self-navigation by the aircraft, as well as information necessary to hold position.

Both of these requirements can be met with inertial navigation alone. Given location current speed vector, the IMU presents all the necessary data to calculate position continuously.

The solid-state IMU in our aircraft is certainly not accurate enough to rely on for very long for navigation. There are sufficient errors and noise in the measurement that these will accumulate fairly quickly and the actual location of the aircraft will be so far off as to render it just as lost as with no Nav input,

However, this is not the point. It is certainly precise enough for a few minutes. The time it takes to accumulate significant errors also is a function of how much and how fast its position is changing. Therefore, if it stops and hovers in place, while it will drift around a little bit over time, it will stay in the same area (say, 20m circle, a popular DJI radius ), for a long time. Perhaps longer than a full battery could hover -- we'd have to do a more detailed analysis using the specs for the IMU hardware to really know, but I don't need to do that to estimate with high certainty that its an eternity in terms of dealing with an emergency.

So, all that said, why doesn't the firmware fall back on the IMU as a backup nav system when GPS and the compass fail? The calculations are not difficult or complex. Certainly this is easy to code. It certainly could save drones in many of these situations, stopping and hovering in place when the error occurs switching to the new INS mode, alerting the pilot.

Then, they can fly the bird away from the interference -- if that's the problem -- and regain normal GPS navigation. Or, they can bring it home. Given the known error parameters for the IMU, the AC can even estimate the accumulating error while its flying, and draw a circle around the AC on the map display showing where its estimated to be.

Again, all this is really simple software, and would save many situations where the aircraft as it stands now goes out of control and sometimes is a total loss.

What do you all think?

Actually, it would probably take some serious retooling of the firmware and maybe some additional processing power and memory to work a complete INU solution. Between keeping up with where the bird is via the GPS solution, working which direction it is facing, the attitude of the bird and if/how it is moving, there is a lot going on on that flight controller board. And it would probably be a 'lost return' investment by DJI. We have all been pretty happy with what is offered. how much more would we be willing to pay for what would essentially be a 'no-drift' atti mode? Would take a complete from the ground up software development to incorporate it. Maybe in the Phantom X?

 

[dwallersv]

Thanks for your thoughtful input, Richard!

I assure you, the calculations and the processing power necessary is trivial -- I've done this as part of a DIY project using an Arduino board and a 6-axis IMU shield. The cheapo Arduino had plenty of idle cycles left over to run a whole lot more.

Anyway, the math is very simple physics. For example, with accelerometer data, position updates are simply x = x0 + (v0)(dt) + (a)(dt)(dt)/2, where x0 is the initial position, v0 is the initial velocity, and 'a' is the acceleration in the 'x' direction during the interval (dt). This kind of math is almost free in today's modern microcontrollers.

Perform this calculation for all three axes and you are tracking position. The smaller dt, the smaller the errors. Don't know how loaded the P4 processor is, but I'd be surprised it was loaded much at all -- that would simply be too risky. I suspect there's a ton idle cycle headroom in the operation of the P4 series, for instance. After all, look at what's being rumored to be coming in feature enhancements for the P4 in a firmware update (any day now! ). If those rumors are true, there's plenty of processing headroom, and unused storage in flash to add some stuff that's much weightier than the simple calcs I'm talking about.

EDIT: Forgot the initial velocity term above when I first posted this; corrected

 

[Bendix]

A first-pass pondering of what is necessary to support pure inertial navigation functionality is that we have what we need: A sensitive, fairly precise 3-axis gyro, and 3-axis accelerometer (really the same actual sensor).

This is all that is needed to sense translations and rotations in 3-space, given an initial location.

Are those gyros and accelerometers available cheaply? How much do they weigh? I ask because although I've been out of the business for many years, in the pre-GPS days I worked on inertial navigation and guidance systems. The equipment was so sensitive that it sensed the rotation of the earth and determined your precise latitude. Longitude was a different story, but it was pretty impressive nonetheless. And very expensive and very heavy.

Later, ring-laser gyros increased the reliability and reduced costs compared to mechanical gyroscopes. So I'm not sure where the state of the art stands today, but my first instinct is to say anything beyond GPS is going to add weight and cost to an sUAS.

 

[dangerd]

Seems like a good idea

 

[bungrudi]

Actually, it would probably take some serious retooling of the firmware and maybe some additional processing power and memory to work a complete INU solution. Between keeping up with where the bird is via the GPS solution, working which direction it is facing, the attitude of the bird and if/how it is moving, there is a lot going on on that flight controller board. And it would probably be a 'lost return' investment by DJI. We have all been pretty happy with what is offered. how much more would we be willing to pay for what would essentially be a 'no-drift' atti mode? Would take a complete from the ground up software development to incorporate it. Maybe in the Phantom X?

Agree.

The fact that the phantom need to 'borrow' processing power from the RC (not sure its from the RC or from the connected tablet) to 'interpolate' gimbal pitch on waypoint missions indicates that any processing resource onboard the drone is already busy as it is. At least to a safe threshold perceived by DJI engineers.
I assume the current 'event bus' onboard the drone is very noisy, and to code a robust fallback logic under such noisy events will not be easy (for them).

Even if they want to, seeing several software related saga from DJI I'd say that it would take them years to roll out a solution that wont backfire.

This is pure speculation from me after knowing DJI products for only 5 months.

 

[sar104]

The sensors are already in the IMU, but the technical challenge in terms of processing may still be significant. I guess this an active area of research.

http://onlinelibrary.wiley.com/stor...tk&s=7b0c13195ed1c7c27a7ae05110fe694f6702f024

 

[ianwood]

Two things to note here:

1. DJI does use very short period inertial positioning, probably less than 1/10th of second before it is corrected by a fixed GNSS position.

2. Extending it for any meaningful length of time, e.g a minute or more, is simply not doable. Wind, motor noise and low-costs MEMs are a few of the reasons why.

 

[dwallersv]

Well, the reason I dispute these claims of technical limitation is because I've done exactly this with a cheap processor ($20 Arduino) and a cheap 6-axis module (called a "shield" in Arduino-world) for a 2D ground vehicle. I wrote the code myself, and it was exceedingly simple.

In the case of the phantom, since there is already a barometric altimeter and code in place to use that for vertical positioning/tracking, this problem could be reduced to the exact same planar 2D effort.

Again, I'm telling all of you from direct experience engineering this myself for a hobby project that it is NOT as technically challenging, or processing intensive, as you all are speculating.

Take my direct-experience word for it or not.

In any case, it is this direct, first-hand experience that caused me to start this thread in the first place.

@bungrudi , you are mistaken regarding the reasons for processing on the tablet vs. the aircraft. It's not a matter of processing power that's the issue, it's other limited resources like flash storage for firmware, and RAM mostly.

Neither of these would be significantly impacted by adding code to calculate position from inertial sensors -- again, the calculations, and the resulting code, is tiny! It's physics at its most basic, middle-school level of sophistication.

Remember I'm not talking about relying solely on inertial nav indefinitely... This would require much much better sensors, and far more complex and sophisticated measurement and control software. Rather, what we're talking about is an emergency use of this as a backup for a few minutes at the most. My experience with far less capable hardware is this is easily doable, and more than accurate enough for what we need.

 

[sar104]

Well, the reason I dispute these claims of technical limitation is because I've done exactly this with a cheap processor ($20 Arduino) and a cheap 6-axis module (called a "shield" in Arduino-world) for a 2D ground vehicle. I wrote the code myself, and it was exceedingly simple.

In the case of the phantom, since there is already a barometric altimeter and code in place to use that for vertical positioning/tracking, this problem could be reduced to the exact same planar 2D effort.

Again, I'm telling all of you from direct experience engineering this myself for a hobby project that it is NOT as technically challenging, or processing intensive, as you all are speculating.

Take my direct-experience word for it or not.

In any case, it is this direct, first-hand experience that caused me to start this thread in the first place.

@bungrudi , you are mistaken regarding the reasons for processing on the tablet vs. the aircraft. It's not a matter of processing power that's the issue, it's other limited resources like flash storage for firmware, and RAM mostly.

Neither of these would be significantly impacted by adding code to calculate position from inertial sensors -- again, the calculations, and the resulting code, is tiny! It's physics at its most basic, middle-school level of sophistication.

Remember I'm not talking about relying solely on inertial nav indefinitely... This would require much much better sensors, and far more complex and sophisticated measurement and control software. Rather, what we're talking about is an emergency use of this as a backup for a few minutes at the most. My experience with far less capable hardware is this is easily doable, and more than accurate enough for what we need.

Did you take a look at the paper I cited above? If so, any thoughts? One observation appeared to be that the challenges are significantly greater as the degrees of freedom increase - for example, airborne vs. ground vehicle.

 

[dwallersv]

Did you take a look at the paper I cited above? If so, any thoughts? One observation appeared to be that the challenges are significantly greater as the degrees of freedom increase - for example, airborne vs. ground vehicle.

It's open in another browser tab to be read later this morning... I'll push it ahead in the queue, now that you mentioned it again