Moving MAVLink from 0.9 to 1.0 wire protocol.

[Peter Hollands]

Folks,

I'm intending to move our MAVLink implementation from using the 0.9 protocol to the 1.0 protocol.

If anyone is using the 0.9 protocol in some way already, and thinks that the 1.0 protocol will be a problem for them,
please let me know asap.

Details about the improvments to the 1.0 protocol are shown below.

Best wishes, Pete

From the mavlink website:-

Upgrading from 0.9.0 to 1.0.0

• Q: Is the upgrade easily done? - Yes, v.1.0.0 is almost fully API-compatible with v.0.9.0. Only a few messages have changed, all protocol-functions like the message parsing (mavlink_parse_char) are fully compatible.
• Q: What are the main benefits from upgrading? - 1. MAVLink now uses the little-endian wire encoding, which makes is a lot more efficient on most platforms. It still supports little and big endian platforms. 2. It now checks the packet format of each message, so if two communication partners have different formats for the same message it will detect this mismatch. 3. It now has support for smaller message buffers. 4. The parameter protocol now supports 32 unsigned and signed integer and float values. 5. MAVLink now supports IEEE 754 double precision floating point numbers. 6. All messages are tested with an automatically generated test suite, making the protocol even safer to use. 7. Some messages have been cleaned up to better suit actual flight use. 8. MAVLink comes per default now with C/C++ and Python support.
• Q: Is the new version to be used soon? - Yes, QGroundControl is fully ported to it and ArduPilotMega and PIXHAWK already are porting their software. Soon all adopters will have ported to the new version, simply because it is not too much effort.

[Claudio Carbone]

There are these new Invensense fusion platforms (6000 and 9000) that do all the sensor calibration and rotation matrix calculations by themselves at a maximum of 200 Hz.
Raw data output supported up to 400 Hz.

the 9000 is single chip, the 6000 has external magnetometer.

What about ditching the actual multiple sensor setup for one of these new toys?
I think I saw one of the new ardu-something go for it.
Any news on how it behaves?

Claudio
-- Sent from my LG Optimus 2x with K-9 Mail.

[Peter Hollands]

Claudio,

I'm not aware that any of the core design team are currently evaluating new gyros / acclerometers or IMU chips at the moment.

It would be very interesting to compare the performance of an ArduXXX that uses the Inversense MPU 6000 against that of the UDB4 for aerobatic flight (which is where IMU calculation get tough). The Inversense 6000 is designed to use it's internal fusion calculations for applications such as games consoles, and smart phones, where centripetal forces are not significant over time. It is not clear to me yet, how the ARDUXXX use of the Inversense 6000 is allowing for centripetal forces if they use the internal fusion firmware. I Perhaps someone else on the forum can illuminate some light on what features of the Inversense 6000 are actually being used at the moment by the Ardu team. 

It is also interesting to note that last orders at Inversense for the current gyros in the UDB4 are scheduled for March. So we will need to check with Sparkfun to see how well stocked they are on the current gyros. If Sparkfun pre-order some gyros then we could easily see the current UDB4 design being fine for another 6 months. Order after that, will have to use the next generation gyros from Inversense (still to be evaluated). The EOL document is recommending the digital  ITG 3050 (I2C interface).

Bill is currently doing some super R&D for the project related to new mathematics. Once he's done with that, and has implemented the maths in the Quad software, later this Spring, I suspect we will start looking at latest gyro technology again.

In the meantime, there are many more exciting developments, that seem to be more fun and innovative to pursue.

Best wishes, Pete

[William Premerlani]

Hi Peter,

Thanks for responding to Claudio's question about the new Invensens IMUs. I agree with your comments. Here are a few more of my own comments.

First, the short answer to Claudio's question: I am having too much fun improving the performance of the MatrixPilot IMU through innovation and clever math solutions to turn the job over to Invensense.

Now the longer answer. I am skeptical of the 6000 and the 9000, I doubt that Invensense has implemented some of the innovations the UDB team has made specifically for aircraft applications over the course of the project. Just to mention a few:

- Wind estimation

- Magnetometer alignment

- Sustained rotations

And there are several more ideas in our pipeline, such as exact compensation for acceleration effects, white paper attached.

In order to implement these innovations, it is necessary to have access to a high bandwidth stream of raw gyro and accelerometer data, so there is no point to switch to a "canned" solution.

For aviation applications, it is axiomatic that an IMU must perform compensation for centrifugal effects. In order for the 6000 or 9000 to account for acceleration effects, it will need GPS information. I will assume that there is some way to feed that information in, but I have not had time to look at the spec sheet.

Claudio mentioned that the 6000 or 9000 provides samples up to 400 Hz. The UDB presently takes 8000 samples per second per channel, and still uses only about 10% CPU for all calculations. This has led to very low raw drift rates, and enabled "dead-reckoning" computations. Basically, we recognize that because the critical calculations involve integrating gyro and accelerometer data, we are using an "integrate and dump" technique that I have no way of knowing if the 6000 or 9000 are using. But if they are not using that technique, they will not perform as well as the UDB IMU for navigation.

Even assuming that the 6000 and 9000 have GPS inputs, unless you also connect a magnetometer, the 6000 and 9000 would have to do wind estimation in order to compensate for the error that wind introduces into the IMU yaw drift computations.

Finally, as I discovered during recent research into magnetometer alignment, if you use an external magnetometer, you either have to align its axes exactly with the axes of the gyros, or you need to use some sort of inflight magnetometer alignment algorithm. I am dubious that the 6000 and 9000 does this.

The point is, I think we are getting better performance with the UDB than what we might get with the 6000 or 9000, and certainly we are having more fun with our own DIY IMU.

Best regards,

Bill Premerlani

[Claudio Carbone]

Points taken.

Claudio
-- Sent from my LG Optimus 2x with K-9 Mail.

[Claudio Carbone]

In order to conduct some tests on the udb I have to strap it to a machine that is located indoors where gps reception is void.

The dcm calculations would perform anyway, but corrections wouldn't.
So what would be the best way to trick it into believing it is receiving a GPS signal?

I could easily fake a nmea stream if that could help.

Let me know.
All the best

[Peter Hollands]

Claudio,

I sometimes edit this routine.

http://code.google.com/p/gentlenav/source/browse/trunk/libDCM/gpsParseSTD.c#333

That is for em406a.

Best wishes Pete

[Claudio Carbone]

Thanks Pete.
So I could just type my fake coordinates instead of passing the real ones?
Will this also get the state machine to believe it has a gps fix?

 

What is the real format these variables should have?
Apart from the declaration, I mean. Should I convert normal numbers in q15?

Should I leave the GPS plugged?

 

Claudio

[Peter Hollands]

Claudio, I will send a fuller answer tonight or tomorrow. Pete
(From phone)

[Peter Hollands]

Claudio,

To answer your question and needs more fully, I need to understand more about what you are trying to achive inside the building.

one option: some people just make an extended GPS (serial) cable, and then put the GPS outside the window, while they are working / developing inside.

Do you need the yaw gyro to be corrrected for drift. In which case, do you have a magnetometer attached ?

If heading is coming from the magnetometer for yaw gyro drift correction, then do you need any heading or velocity in the GPS?
Do you really need the GPS at all ? Do you actually just need the UDB to move to stabilized mode without GPS, and only using the magnetometer (for testing purposes only). In this case, no centripetal forces will be accounted for, but that may not matter if the UDB is largely just on your desk. So in this case, what you need is a different initialisation state sequence in order to be able to move to stabilized mode, without really receiving GPS.

I remember now, that my use case for overiding the GPS was rather different. I wanted to test out the camera targetting with the UDB on my desk. In fact the GPS units do work in my house, and I just wanted to inject an artificicial GPS Course over the Ground, and GPS speed over the ground. So the interrupts from the serial stream of the GPS were all working, along with the parsing of the GPS messages, and all I wanted to do, was overide the real data with my own. That is easier to do. By having the GPS running artificially, I could stop the yaw drift (in the days when yaw drift was larger), and test the camera targetting angles. Also, in those days we had no magnetometer support.

Anyway, perhaps you could add some more detail about your objectives ?

Best wishes, Pete

[Claudio Carbone]

Hi Pete,
thanks for your time.
I want to perform some characterization tests on the udb.
this means subjecting it to known forces and comparing the recorded measurements with the known path.
To achieve this I'll use a 6dof electro-hydraulic platform whose scientific name is currently escaping me. Anyway pretty similar to those used for flight simulators (6 linear actuators paired every 120 degrees)

My idea is that the USB should perform in a way as similar as possible to what it would do in open space.

So I think that injecting an array of fake GPS data would be the most accurate representation.
I can generate a reasonably accurate point cloud for a static position in nmea format. Saving this into an array on the micro would be straightforward enough.

I think that since the path is an active path but static in terms of position, corrections for centripetal accelerations should be used.
Anyway I could easily make two runs, one with and one without corrections, and see the diffs.

regarding the magnetometer:I have it mounted and connected, but I doubt I'll be able to get the udb to compensate its offset correctly as the machine is all metal and I can't move it much when it's mounted. If you have any suggestions about this I'm all ears.
Since the udb will be static with respect to the motion platform, do you believe calibrating the mag will be necessary? Fact is knowledge of absolute heading is useless: what it must know is that its heading is not changing that much (I think the platform is capable of about 20° of yaw per side but this is data I could get ahold of).

I think it's long enough for now ;)

[Peter Hollands]

Claudio,

OK. So we are talking about an arrangement of a linear actuator platform which is similar to this. ? (see link to flight simulator at liverpool university).

The idea is to mount the UDB, and run the linear actuators through a known set of movements,
and then compare the output of the UDB's Dead Reckoning data (DCM for orientation, and the IMULocationX,IMULocationY, and IMULocatationZ [possibly the velocity outputs as well... they are in SERIAL_UDB_EXTRA as well now]), and compare the error of the UDB's data with the known paths and orienations produced by the linear actuator platform.

The main issues resulting from not have the GPS are:-
1) How to correct the Yaw rate gyro when there is no GPS heading, and when there is too much metal for the magnetometer to work.
2) How to account for centripetal forces so that the gravity can be determined so as to allow the pitch and roll gyros drifts to be corrected.

If the tests are short, e.g. 15 seconds, and if gyro drift is low in your setup, then it may be that we can ignore all the issues around points 1) and 2) and just arrange for the gyros to be corrected before running the test, and not actually correct gyro drift during the test.

If I remember rightly, you were doing some research on the movement of large boats in waves, and using the UDB as some type of sensor to detect the movement of the ship in relation to waves.

I'm going to think about it a little more. And as this is going to test the deep inner workings of the IMU.

I expect Bill may want to comment.

Best wishes, Pete

[Claudio Carbone]

Hi Pete.

Yes the platform is just like that one.

Now I have a proper computer under my hands I also found the link to the one I will have access to: http://www.insean.it/en/content/sloshing-lab

I still haven't had a look at the software to program the sequences, but I strongly suspect duration of the tests is totally at the operator decision ;)

 

It's true that my main intent is to use the platform on a boat, but others noticed it and an interest is building in seeing its real performances.

So I think we will get as much as we can out of that Mistral II, besides loading it with just 500g should allow us a little more experimenting room.

 

Unfortunately designing a more truthful test is outside my reach right now, both for technical reasons as well as for time reasons.
Only way of really testing it would be an aerial platform with a more precise instrument strapped to it.
I haven't the first, I could get ahold of the second but it's not a quickie thing.

 

So for now my intent is of starting these tests by march and see what comes out.
Better tests can always be devised later.

[Peter Hollands]

Claudio and Bill,

For your interest, here is a video where I start testing the High Bandwidth Dead Reckonining of the UDB's IMU.

I did the video about a year ago.

Best wishes, Pete