Adafruit 9-DOF breakout for quads?

FireNWater

.
Anybody know if this sensor (https://www.adafruit.com/products/2472) would work in the flight controller of a quad? I use it as a telemetry downlink for my R/C airplanes, but don't know enough about the control loops for quads (yet).
.
The breakout board has a built-in microprocessor that does all of the number crunching for you. All you do is download the numbers using I2C.
.

JasonDorie

It would probably be fine, especially if the quad isn't super small, though you may actually want direct access to the gyro data for tighter instantaneous control. I found control tightened up dramatically when I fed the gyro readings directly into the control PIDs, and used the orientation data to offset it.

It's totally possible to do all that work (and more) in two cogs on a Prop. You might want to look at the new Elev8 Flight Controller - the code is in GitHub and open source. It implements a full quaternion based IMU on the prop, and will produce quaternion, matrix, and Euler angles at 250hz.

JasonDorie

Actually, if you're thinking about this as an add-on for the HoverFly Open, you could use the gyro data from the sensor on the Open, and the orientation data from the Ada IMU. That would be workable. Still not simple to implement - converting the IMU data into a control system is still a bit of work.

Duane Degn

I have one of those BNO055 boards (actually I have two but I burned out the first one).

I think it's a really cool sensor. I don't recall the refresh rate but I think it was around 100Hz.

I should have some Propeller code (Spin) for the sensor soon.

rjo__

Some code.

I think this is a better argument for using a Propeller than it is for using the BNO055.

This was a really simple project to do... took a couple of hours, mostly because recently I have been working with nearly-java
and found myself slipping into the wrong syntax frequently.

This sample uses Chris Gadd's "I2C SPIN driver v1.4od"

The data sheet from Bosch is excellent. And I found playing with the BNO055 an absolute hoot.
Really sweet engineering and a device that actually seems to live up to its hype.

The sample code exercises only a tiny fraction of the BNO055's functionality.
It is slow, mostly because of the way I am using I2C. Chris's library could be greatly hacked and it could all be put into one cog.
The quaternions are not scaled... the values seen in the serial terminal are the raw outputs. The Euler stats are scaled to the degree, although it could be further scaled down to less than a tenth.

The only testing that I have done is to look for drift while the unit is stationary... there isn't any:)

Even this limited sample should be good for orienting cameras(or Kinects, which is what I am doing next) and for land or sea bound robots. One thing that interests me is that the unit tends to lose calibration during certain kinds of motion.
What I find amazing is that it regains calibration and after returning to a stationary position, no drift seems to have occurred.
I don't know how they do it... and I could be wrong... but it looks really good so far.

Heater.

It has accelerometers built in, and magnetometers. That means when the gyros indicate it is not rotating it can use the compass direction and the downward acceleration due to gravity measured by the accelerometers to regain it's sense of direction.

With lesser sensors you have to do all that "sensor fusion" yourself in software.

I can't wait to get hold of one.

rjo__

And I can't wait to see what you do with it:)

rjo__

There is some elementary math that I neglected to absorb in my formative years... never thought I would need it... seems I do.

I've just spent an hour trying to scale the linear acceleration data... it is like a monkey at a typewriter.

JasonDorie

Drift correction is handled by the accelerometer and compass, as Heater mentioned. Unless you move the thing faster than the gyro can measure, the error will be imperceptible, and corrected as it's happening. In cases where you manage to spin faster than that, you'd get a very large initial error, but it would correct itself over the course of a few seconds.

Heater.

rjo__

And I can't wait to see what you do with it:)

Actually I have no idea.

I just got fascinated with the whole problem of sensor fusion for IMUs. Ended up porting Sebastian Madgwick's quaternion algorithms to Javascript. I know, that's crazy.

https://github.com/ZiCog/madgwick.js

The Bosch chip does all that for us. Brilliant!

rjo__

Here is the current code. Acceleration isn't fully implemented. I have x axis both linear and regular acceleration implemented in fusion mode...with what I think is correct logic.

I stopped here because I am seeing too much drift in the fused acceleration data.
For what I am doing orientation is enough and it appears to be rock solid. The corrected gravitational data is solid. Heading data is more reliable than my iPhone:)

Roll data right now goes from 90 to -90 but beyond this, the roll angle gets confused... this is probably my implementation. Beyond these limits the roll angle gets lost... can't tell 91 from 89 for example.

If this was an issue for me, it appears that logic which evaluates the gravitational vectors and uses them to correct the roll vectors would be pretty simple and should work.

It isn't an issue for me, so I haven't done that.

Pitch seems to be perfect.

NICE little board.

Rich

rjo__

oh... Bosch clearly indicates that with increasing pitch, the roll data becomes less accurate.
This is clearly true... so, when I am talking about "rock solid" I mean near primary orientation.

As with any sensor, what you want to do and how you do it has to be tempered by the strengths and limitations of the sensor. There is a lot of room for developer creativity here.

So, this isn't a black box that will solve every problem, but it is definitely a black box that is a nice step forward and should give developers a nifty new set of issues to think about.

xanadu

Good find, thanks.

rjo__

The next step would usually be to dump all the math and logic into some cogs and use pasm to speed things up. In this case, I am waiting on the next revision of the P2 and then plan to port what I have over to it.

JasonDorie

According to the chip docs, roll is only +/- 90 degrees. Pitch is +/- 180. That's a limit with their implementation (it's possible to get a full +/- 180 on all axis). That said, Euler angles aren't stable, because there are multiple ways to represent the same rotation, which is why they likely limited their numbers. In your case, a roll of +180 is the same as a pitch of +180 combined with a heading of +180. Both answers are "correct".

Using the quaternions and doing all the math in that space will avoid these problems, but it's harder to wrap your brain around. The quaternion version will also have the nice benefit of displaying the same stability regardless of orientation.

Heater.

Jason,

There is a good point. As far as I can tell the Bosch chip is supposed to handle all that messy stuff internally. I have no idea how well it does. Does it use quaterion math? Does it suffer gimble lock?

Anyone have an idea?

JasonDorie

That chip outputs quaternion data, so I can practically guarantee that's what it's using internally. It's outputting Euler angles as a convenience, but they're very limited in practical use. If you go more than 90 degrees from level in any direction there are multiple solutions, and the code to deal with that gets very messy.

The Elev8-FC does all of this with quaternion math and outputs all the same data (+ altitude), so I imagine their internals are very similar. No gimbal lock issues whatsoever with quaternion or incremental matrix math. You generally only run into problems when using Euler angles, even if they came from a system using quats or matrices internally.

JasonDorie

This is an older version of the IMU in the Elev8-FC:



The lag is just the transmission / rendering time from the Prop to the PC. The internal update rate for the IMU is 250hz, though I've run it at 320hz with no issues. This is one cog reading all sensors, and one FPU cog running all the math.

FireNWater

.
It looks like this board can be added to the ELEV-8 V2 without much pain and suffering. I haven't flown my V2 yet. Would this board give the quad any new capabilities? (With the proper software mods, of course)
.

JasonDorie

Yes, I don't see why not. A prop with similar sensors is running the V3 in 6 cogs. That board would remove the need for probably one of them, though you still need to do a decent amount of math to compute the difference between your target orientation and your current one, depending on how you're doing it.

FireNWater

I haven't flown my V2 yet, but I have been flying R/C (both fixed wing and helos) for several years.
.
Does the V2 have auto-level, or does the controller basically function to maintain the last set attitude?
.

JasonDorie

V2 is a HoverFly Sport board, so it's like having a heading hold gyro on all 3 axis. No auto-level, just tries to maintain the last set orientation - very much like a heli.

FireNWater

OK, good to know. From the HoverOpen PDF, it appears there is an auto-level option when updating the firmware.
.
Does the V3 board have those options?
.

JasonDorie

The V3 board is a totally new flight controller, and includes full auto-leveling in addition to manual mode. It implements the IMU on the Prop, will soon have altitude hold, and will eventually have a GPS add-on (it's planned, not developed yet). All of it is open source, documented, and curricula and samples are being developed to help people learn the concepts in the code. The whole thing runs in 6 cogs. It's worth a look.

The HoverFly sport and open boards only have a gyroscope, so it's impossible for them to implement auto-level without additional sensors. They did have the option to do altitude hold with an ultrasonic sensor add-on, but we're never auto-leveling. It would be possible if they required an add-on accelerometer.

JasonDorie

You said "from the HoverOpen PDF" - did they say YOU could implement auto-level by updating the firmware? It wouldn't surprise me if they mentioned it as something that's left as an exercise for the reader.

Publison

FireNWater wrote: »

OK, good to know. From the HoverOpen PDF, it appears there is an auto-level option when updating the firmware.
.
Does the V3 board have those options?
.

The original V2 shipped with the HoverFly Sport. Most of the later units shipped with the HoverflyOpen. Basically the same with no upgrades and closed source.

FireNWater

.
Mine is one of the closeouts from before Christmas and has the HoverflyOpen board. I plan on installing Jason's open software once I get a few flights on it.
.

avsa242

Sorry to bring you back from the dead, old thread, but:

@_rjo (or anyone else who's used the code above and had it working)
Was your code tested with the Adafruit module or another make?
I'm trying to get one working but have so far been unsuccessful. I started trying to write a driver for these a few months back, and found you'd already written some code. I've had no luck getting a peep out of mine (Adafruit branded module).

Cheers

macrobeak

avsa242,
I really admire your excellent Github SPIN library.
If you are talking about the BNO055 module, I am glad you are turning your formidable coding talent to it.
I continue to believe the BNO055 has great potential for high-level IMU applications.
I found -rjo's drivers for the BNO055 worked quite well, and I was able to get an experimental gimbal apparatus working.
If it is the BNO055 you are interested in then I may be able to give you some pointers on implementation.

VonSzarvas

Parallax have a newer IMU too, for which a C library is available and is fully supported by Blockly (look under Sensors).

https://www.parallax.com/product/28065

avsa242

@macrobeak
Thanks...very nice of you to say! I wish I knew who started it...I just forked it a few years ago and kept going with it. Many of the objects in it were written by some of the greats, and someone re-wrote or re-formatted them in a different way. It's been a lot of fun working on it and incorporating new things into it. I'm only just now, I think, focusing on making it more consistent. It's one thing to write a bunch of drivers or other objects, but it's another thing to have them all work in a common way. I have a little more focus on that, now. I'd be grateful for any help you can give...after trying many different ways of connecting it and a few different I2C engines, I thought for sure rjo's code would be the holy grail...but I still can't talk to it...never had this kind of trouble with a sensor before. I'm missing something trivial, I'm sure.

@VonSzarvas
Thanks - I have two of those actually They're nice...just wanted to give this one a try since it does some of the math on chip...

Cheers