I noticed that Digikey is now selling Honeywell's newest aerospace-grade IMUs, which cost $1,328 each (note that's just for the IMU; it's not a full autopilot). How do the specs of these aerospace IMUs compare to those we use here? Are they worth the extra money?
In terms of overall approach, the Honeywell IMU seem very similar to modern autopilots such as Pixhawk 2.x and 3.3: they both have MEMS sensors with internal environmental isolation and temperature compensation.
As for the sensors themselves, I'm no expert on specs, so I'll just post the basics here, comparing the Honeywell sensor to the Pixhawk 3.
On the face of it, the Invensense and ST sensors in the Pixhawk 3 appear at least as good, if not better. But I imagine that there are some other factors that may be more important, such as gyro drift and vibration filtering. The Honeywell specs in drift are shown here:
Meanwhile the Invensense ICM-20602 sensor in the Pixhawk 3 gives its drift in different units: ±4mdps/√Hz. I really don't know how to compare those.
Finally, I'm sure that a lot of the performance depends on the software running on the Pixhawk boards, be it PX4 or APM, both of which use GPS to augment the raw IMU data to compensate for drift, along with a lot of other smart filtering.
So for those IMU experts out there: how do you think these two approaches compare? Are aerospace-grade IMUs worth the extra money?
Comments
It would be best if someone who has actually experience in installing one of these in a model gives us some insight. I have seen many models ( heli/planes) using pixhawk but never one of these.
> Meanwhile, let's bring this thread back on topic. What do you think of the intrinsic performance of the Honeywell IMU vs our stuff?
Yes, a great topic, one that I am also particularly interested in too. With closed source companies it's always hard to tell, typically only history can help with a verdict. But then again this is Honeywell ... Direct "physical" spec comparison can help though, am interested into looking at this closely.
In general have to agree with Rob's comments. IMO It's not so much that glitches cannot happen with professional aerospace companies, we all know guaranteed 100.0% error free production cannot exist, see Boeing 787, NASA, etc ... But it's the attitude of the professionals that makes the difference.
Closer to home Freefly Systems or ProfiCNC are good examples of professional companies doing the right thing. In the first case Freefly discovered an issue on their ALTA, one that a hobby grade company would have likely ignored and swept under the rug. Instead they issued an immediate recall with free fix.
With the Cube aka Pixhawk 2.1, an issue was discovered where there was the very unlikely possibility that a short could occur if one screw was over-tightened. Similarly a Service Bulletin was immediately issued describing and addressing the problem, a fix for current board owners was provided, and production for all boards forward was immediately changed to fix the problem.
Thanks, Oliver. The buzzer issue was fixed in the PX4 code update. Once we get an issue report in the PX4 tracker, we'll do the same with the LED issue if that can be confirmed in testing. This is the normal process; indeed, I'd argue that the open source community (APM and PX4) are way faster than the aerospace industry in pushing such fixes out. (And because we have so many more users, we get more issue reports)
Meanwhile, let's bring this thread back on topic. What do you think of the intrinsic performance of the Honeywell IMU vs our stuff? (Calling Pixhawk 2.1 or 3.0 "hobby-grade" is not really accurate anymore, but there are clearly differences between mil-spec and consumer electronics grade gear)
Chris this is not a flight stack issue, it's a hardware issue regardless of what stack is supported. To my knowledge there's actually been two to date, the first having to do with the buzzer too close, reported here late last year. To my knowledge this has not been acknowledged or addressed by HobbyKing or 3DR. One fix is to disable the buzzer.
The LED issue Rob mentions was just discovered a few days ago and only discussed yesterday evening on the Ardupilot Dev call. One suggested fix for that one is to disable the LED.
Rob, that's news to me. Can you please link to the issue report with the PX4 code? I've seen no such reports with PX4 (the only officially supported code) to date.
When (or rather if) Honeywell discovered a problem with their IMU, they would issue a recall.
Compare that to known examples from other manufacturers who have discovered major issues with flight controllers, they delete user comments from their discussion board and reviews, and hold a clearance sale until the stock is all gone.
This is the type of thing that separates the professionals, from the hobby companies.
Interesting comment Rob!
Any comparison between these systems, must consider not just the raw performance specs of the chips, but also the MTBF of them, amongst other details. And not only the details of the chips themselves, but the quality of the systems engineering and production control of the entire hardware device that they are assembled into.
Quite a few mistakes have been made on "open-source hardware" over the years. The latest discovery for example, is current in the on-board LED on the Pixhawk Mini causing interference with the on-board magnetometer. Even worse, is when the OEM does not discover the problem themselves. And even worse than that, is when they don't inform their users, nor fix the problem.
As a professional aerospace electronics company, I imagine Honeywell would not do that. That alone, is worth the price tag. Actually, I'm surprised that the Honeywell IMU sells for so little.
-
2
-
3
-
4
-
5
-
6
of 6 Next