A Date with Ms. Purple (APM2)

Rob_Lefebvre January 23, 2012 at 6:44pm

@Ellison: Ok, I'm going to have to think on that one. I would have thought that if the sensors output Z=0.5, X=0, y=0 that it would be a fair assumption that the copter is level, but accelerating downward at half a g. If the output is Z=0.981sin45, X=0.981sin45, Y=0, that it would be a fair assumption that the copter was tilted 45° and not accelerating in any direction. The downward vector should always be a constant against which things are compared. No?

@Chris, I think the situation isn't really obvious to a lot of people, and I'm not sure what, if anything, can or should be done about it. This was the first time I've ever done something like this. When I bought the board, I had no idea either.

Fortunately, I'm having a heck of a lot of fun working on it, so it's all good. It doesn't hurt that I previously bought a retail stabilization system (Flymentor) which failed me, so I know that no system is perfect anyway. It seems to me that the only people who think autopilots are infallible are people who have never used one before. (That being said, I am not aware of any failure modes in DJI or MK, but I'm sure they have a weakness)

But, this situation reminds me a lot of back in the day when I used to "test" satellite systems. I got into it thinking it was a cheap way to get satellite. It quickly became more of a PITA than it was worth. Somebody told me "You don't do this to get cheap satellite, it's not worth it. You only do this if it's your hobby."

Don't buy an ArdupilotMega because it's a cheap autopilot. You do it because you want to participate in the project. At some point, we may get to the "plug and play" situation (Arduplane is there now I understand) but the copter code is not quite there yet.

That being said, I think the copter code for 1.4 is REALLY close. And just some bugs to work out on APM2.0, which is to be expected. The board had to be created before the code could be developed. How are open source developers supposed to develop code with no hardware to test on?

3D Robotics

Chris Anderson January 23, 2012 at 2:57pm

@Robert: Well put. Thanks for explaining that for others who may not be familiar with the open source hardware/community developed software process

@Ellison. I'd love to have your perspective and expertise directly to the dev team. We have some world-class folks working on this, including former Invensense engineers, so I think you'd enjoy it. If you'd like to participate, please PM me your email address and I'll add you to the dev list. (Robert is already on)

Ruben: Sorry you got the wrong impression on how the hardware/software release process works here. If you'd like, I'd be happy to buy your APM 2 board from you at the full retail price. (I need another one). Please PM me if so.

Ruben Wijnhoven January 23, 2012 at 2:04pm

I stepped over to the darkside and ordered me a dji naza. Will come back to the arducopter in half a year or so when things hopefuly are a bit more stable.

Ellison Chan January 23, 2012 at 11:44am

Chris, I don't think the GPS will provide sufficiently accurate altitude or longitude/latitude information to be able to correct the leans. It's accurate at best within a meter or worse. Most of our drone wing spans are very close to that.

Robert, it's because the force measured is a sum of gravity and inertial acceleration. So, when the craft is accelerating, the force read maybe be either greater or smaller than 9.81 depending on the direction(s) of the inertial acceleration. You may think that one can just subtract or add the difference between 9.81 and the value read by the accelerometer, but how would the controller know which vector to subtract. The problem is actually due to the General Theory of Relativity. You just can't tell the difference between the force of gravity, and force from wind or the propellers. All the gauges measure is a net force, and direction vector for that force.

Rob_Lefebvre January 23, 2012 at 11:17am

Couple things. In the real world, you'll never end up with Z=-0.981, Y=0, X=0. Just because nobodies board, or landing gear are perfectly level. In an ideal world, you're right.

But still nobody has explained why it can lose track of it's level. That level parameter is fixed. I can't understand why there would be any errors over time. If level is 0.981/0/0, and the current accelerometer vector is 0.8/0.2/0.3, then do whatever needs to be done to get back to 0.981/0/0. How could get that ever go wrong? the only reason I can see is vibration aliasing on the live accelerometer feedback? So for example, the craft is actually level, 0.981/0/0, but due to vibration aliasing, the accelerometer is *reporting* something else, so it will try to go towards a false level.

Also, if GPS velocity vectors are used to cancel out DCM errors, how does stabilize work without GPS? And what would happen if atmospheric conditions make the the GPS signal drift? Won't the DCM correction get screwed up? What if people with "leans" problem aren't caused by vibration, but in fact caused by GPS problems?

Ruben: It's the same thing as with APM1.4. I bought it not knowing that the basic functions weren't perfected. I only learned after. It's kind of a bitter pill to swallow, but that's how it works. At the end of the day, the APM2 is a stand-alone product. The software is not part of the deal. The software is a separate entity that you download from an open-source community on the network that just happens to work on this board.

Gareth Rens January 23, 2012 at 10:48am

Chris: Thanks, I will suspend the board like you have and let you know what happens :)

Ellison Chan January 23, 2012 at 10:33am

The accelerometers read acceleration or actually force. They are essentially force gauges. While sitting on a table, the only force acting on the craft is gravity. So if the craft was perfectly level, the z component would be 9.8, and x/y would be 0. So, the algorithm will level the craft by using applying motor thrust to rotate the craft in an orientation that causes the z component to go back to 9.8 and x/y to go back to zero, as best it can. Vibrations will periodically jostle the components around. The vibration problem is cause by the fact that the jostling is not symmetrical. The small differences between up/down or side to side, will accumulate every time you sample. If you sample at too high a frequency or with a higher resolution, which is what's happening with the the APM2, it will cause an increase in errors. This can be solved mechanically, foam, or a software filter. (i.e. don't sample at the frequency of the vibration)

The inertial acceleration problem is not that simple. First the acceleration differences are all one sided in the direction of movement, so it's not periodic, and doesn't cancel. This means every time the APM2 samples the error equivalent to inertial acceleration is added. The faster you accelerate the larger the error. This is why the hard flying and loiter, which flies in a circle makes things worse.

One possible way to reduce the error is to not sample the accelerometer, when the user moves the control sticks, and keep the last valid orientation before the input. But there's always going to be variations in the signal from the transmitter, so this could result in the controller never being able to do a sample because it thinks the user is always adding input. Response rates can be adjusted so that a compromise be made between user response and stabilization. Some work needs to be done. As for the loiter, you can calculate the centripetal/centrifugal forces, and cancel them out from the accelerometer readings. Them there's environmental issues like wind.

Anyways, you see, much code needs to be changed.

Ruben Wijnhoven January 23, 2012 at 10:31am

Chris,
So you experience drift. You also mention you have to land and rearm to solve this problem. Same as me. Can fly for 3min then land and rearm. Why didn't you solve this problem before you started selling the boards. Or at least give a disclaimer with the pre-order that there are still issues. The apm2 now was promoted as the super solution. Alt-hold without sonar, etc. No where these issues were pointed out. And as you claim it yourself you also experience these issues. I understand there are problems that you are trying to fix. But schouldn't there have been at least some warning about this? Now we all had verry high hopes for the new board the way it was presented. And these high hopes given by us by the marketing of the product give us te dissapointment when these sort of issues arise. And the problem is defenately not vibrations. My tilting test proved that to me.

3D Robotics

Chris Anderson January 23, 2012 at 10:24am

Gareth: all changes in sensors require changes in the software filtering. This is the normal process of dialing in a new board.

3D Robotics

Chris Anderson January 23, 2012 at 10:20am

We fly APM 2-powered quads every day, and by and large they fly great. We've seen some occasional drift issues, which we're collecting data on, but nothing that would make them unflyable (we land, reset the board, and then they're fine). Then again, we all have well balanced quads with balanced props, so vibration is not a big issue for us.

Blogs

A Date with Ms. Purple (APM2)

Comments