Question about altitude in MAVLink message GLOBAL_POSITION_INT

[Philip Giacalone]

Hi all,

I have a question about the altitude (alt) reported by the UDB in MAVLink GLOBAL_POSITION_INT messages. 

The MAVLink documentation (https://pixhawk.ethz.ch/mavlink/#GLOBAL_POSITION_INT) says that the reported altitude (alt) is the WGS84 altitude and not the AMSL value. 

But when I look at the data in the MAVLink message from the UDB, the altitude appears to be the AMSL value. 

As I understand it, to calculate the WGS84 value, one must add the AMSL altitude given in the GPS message to the GEOID separation that is also given. I'm wondering if we're doing this in MatrixPilot. 

For example, at my home location, the NMEA messages look like this:

  $GPGGA,032558,3636.008326,N,12138.817488,W,1,09,0.8,33.0,M,-28.0,M,,

The numeric values near the end (33.0,M,-28.0) are the AMSL altitude and the GEOID separation values in meters. So the WGS84 altitude should be 5 meters, correct? 

However, the UDB is reporting the following altitude (around 36 meters) in the GLOBAL_POSITION_INT message. 

  MAVLINK_MSG_ID_GLOBAL_POSITION_INT - time_boot_ms:723100 lat:366000840 lon:-1216469736 alt:36030 relative_alt:-5000 vx:-1 vy:-23 vz:9 hdg:2000

Since the altitude reported is much closer to the AMSL value than to the WGS84 value, it leaves me wondering what it represents.

BTW, I'm seeing the same behavior in MAVLink messages from the Pixhawk, with those alt values also much closer to the AMSL than to WGS84. Maybe the MAVLink documentation is just out of date with the code? Or maybe I'm misunderstanding something about this...

Thanks!

Phil

[Peter Hollands]

Hi Phil,

I am probably the developer that originally did the first cut on sending that MAVLink message in the code a few years back. And it has had little change since then.

As you can see the code is relying on using IMULocation relative to the origin. (As this is meant to be a location based on fusion of sensors).

Depending on what is driving your need to use WG84 altitude instead of Altitude above Mean Sea Level (AMSL), I think that your question potentially would need re-considering the model of how IMUlocation derived,

and compared against our waypoints. Both IMUlocation and Waypoints are to some extent modelled as  a flat plane that intersects the origin (the bootup location). Curvature of the earth is not directly taken into account in the model.

However, set against that, is that our fused IMULocaitonZ (altitude relative to bootup location) is always being reset over time, to map to the GPS Mean Sea Level Altitude (at the moment). 

e.g. from the ublox parser .....

alt_sl_gps.WW   = alt_sl_gps_.WW / 10;          // SIRF provides altMSL in cm, UBX provides it in mm

Best wishes, Pete

--
--
---
You received this message because you are subscribed to the Google Groups "uavdevboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Philip Giacalone]

Thanks, Pete. 

I appreciate the pointer into the code. Also, I agree that it's better to report the IMU fusion altitudes than the GPS values, since those are updated more frequently and are more accurate. 

I'm working on an interesting project with Tom P. that involves tracking objects from air-to-air, ground-to-air, and air-to-ground. This obviously requires a common reference frame. WGS84 was a logical choice, since it's the GPS basis and is also pretty easy to deal with mathematically. 

Recent flight testing has shown that altitude differences between objects creates significant tracking errors, particularly when the objects are relatively close to each other. This led to the question about the basis for the altitudes in MAVLink GLOBAL_POSITION_INT messages. Although the MAVLink documentation says they are WGS84 altitudes, that is not actually the case (that applies to APM/Pixhawk, too, from what I can tell). 

Anyway, now that you've identified the basis for MatrixPilot altitudes as GPS/AMSL, I can simply offset those values by the local geoid separation to obtain the WGS84 values. Does that seem reasonable? 

A few more questions about MAVLink in MatrixPilot, if you don't mind. 

What is the best way to increase the rate of GLOBAL_POSITION_INT messages sent by the UDB? For flight testing our system, we'd like to get that rate as high as possible, in order to reduce latency. Other MAVLink message types are not important to this testing, btw. 

Also, are there any max message rate limitations in MatrixPilot code? I'm wondering what max rate can be achieved, outside of radio/hardware limits. APM has hard-coded packet rate limitations, so I'm wondering if MatrixPilot does, too. 

Thanks again, Pete!

Best regards,

Phil

[Mark Whitehorn]

Hi Phil,

Sounds exciting...

I've used mavlink to log messages at up to 200Hz in the mw4 branch. I'm not aware of any message rate limiting in the MatrixPilot implementation of mavlink.  To send messages faster than HEARTBEAT_HZ would require some new coding effort.

What throughput is achievable with you 900MHz radios? That might be a limiting factor, depending on how much data you need to send for each update. Are you sending air-air, or linking through a GCS?

73, Mark

Mark Whitehorn
kd0...@gmail.com

[Philip Giacalone]

Hi Mark,

We're testing air-to-air currently at a range under 1,000 feet. We'll have to see what max rates we can achieve with the radios. We're using 3DR 90Mhz radios currently at 57,600 baud and are seeing a high percentage of lost packets -- with disappointing tracking and latency results. A new set of RFD900 radios is expected to arrive soon. Reports about the range and performance of these radios is excellent. 

A message rate of 200 Hz would be more than fantastic. Reliable delivery at 30 Hz would likely be enough to meet our objectives. How do I setup MatrixPilot to send at these higher rates? 

Also, Is there something special about mw4 branch that allows these higher MAVLink rates, as compared to the trunk or other branches?

Our current interest is primarily in GLOBAL_POSITION_INT messages, so the total bytes per message is not very large.

Thanks for your help!

Best regards.

Phil

[Mark Whitehorn]

Phil,

Assuming this aspect of trunk hasn't changed while I wasn't looking, servoPrepare.c:dcm_servo_callback_prepare_outputs() calls MAVLink.c:mavlink_output() at HEARTBEAT_HZ.

mavlink_output sends each message at the rate specified for its type in  mavlink_options.h, but it obviously can't do anything faster than HEARTBEAT_HZ without some changes to the code . That happens to be 200Hz in mw4 though. I used that facility back when I was analyzing raw IMU data from my Polaris catapult launches.

Unfortunately, trunk and 4.x have diverged so much that it would take someone much smarter than me to merge them.

And yes, the amount of data should not be prohibitive at 57.6Kbaud. I think I was using just 115.2K to OpenLog with the 200Hz IMU data in addition to the standard SUE+mavlink set.

73, Mark

[Peter Hollands]

Phil,

I think the easiest way forward for you would be simply to send that message at 40HZ by a simple one line change to the MAVLink.c code.

I already know that the raw IMU data (gyros, accelerometer and magnetometer) already can run at 40HZ withthout data loss at 57K to OpenLog,

so I would expect the GLOBAL_POSITION_INT to be able to run at 40Hz just fine in terms of the overall bandwidth use of the 57K baud.

Today the code is at this location and is as follows:-

// GLOBAL POSITION INT - derived from fused sensors

// Note: This code assumes that Dead Reckoning is running.

spread_transmission_load = 6;

if (mavlink_frequency_send(streamRates[MAV_DATA_STREAM_POSITION], mavlink_counter_40hz + spread_transmission_load))

{

...... BLOCK OF CODE to Calculate temporary variables ......

mavlink_msg_global_position_int_send(MAVLINK_COMM_0, msec, lat, lon, alt, relative_alt,

-IMUvelocityy._.W1, IMUvelocityx._.W1, -IMUvelocityz._.W1, //  IMUVelocity  normal units are in cm / second

mavlink_heading); // heading should be from 0 to 35999 meaning 0 to 359.99 degrees.

// mavlink_msg_global_position_int_send(mavlink_channel_t chan, uint32_t time_boot_ms, int32_t lat, int32_t lon, int32_t alt,

//   int32_t relative_alt, int16_t vx, int16_t vy, int16_t vz, uint16_t hdg)

}

All you have to do, to run this at 40Hz is to comment out the yellow block of code above which is deciding how often to send the message. i.e.

// if (mavlink_frequency_send(streamRates[MAV_DATA_STREAM_POSITION], mavlink_counter_40hz + spread_transmission_load)

The main code of mavlink telemetry downlink (the code above) is called at 40Hz in MAVLink.c by this line of code.

Mark's mw4 MAVLInk code is driven generically at HEARTBEAT speeds to he can achieve up to 200HZ rates in within his standard MAVLink code.

(Mark's code has a maximum frame-rate of 200HZ. Standard MatrixPilot frame rate is 40Hz). The 200Hz frame rate is vital for quadcopters etc.

Best wishes, Pete

[Philip Giacalone]

Hi Pete,

Another question about the MAVLink GLOBAL_POSITION_INT messages. I'm noticing that every reported altitude (alt) value ends with the digits '860'. So I'm seeing values like 33860, 30860, 29860. Seems strange. Any thoughts on why? 

Thanks,

Phil

[Philip Giacalone]

Thanks, Pete. 

I'll be following your advice and giving that a try soon. Will report back...

Best regards

Phil

[Philip Giacalone]

BTW, the UDB4 is sitting perfectly still during these simple tests that examine the MAVLink contents. 

[Peter Hollands]

Phil,

Yes, you are correct in that something is not quite right. The altitude is showing as about 120 millimeters (12 centimeters) centimeters below the relative altitude.

So after take off in the simulator I have a value like 91880 mm. i.e. 91.88 meters.

It will need some investigation by someone.

Best wishes, Pete

P.S. I took a guess tonight that mavproxy "status" command would accept pattern filtering. It does !. That means you can filter on a subset of raw mavlink messages. Handy.

Here is some MAVProxy output from MatrixPilot-SIL ...

Before Takeoff:-

STABILIZE> 32090: GLOBAL_POSITION_INT {time_boot_ms : 92475, lat : 270672300, lon : -824445190, alt : -120, relative_alt : 0, vx : 0, vy : 0, vz : -7, hdg : 0}

STABILIZE> status GLOB*

STABILIZE> 32189: GLOBAL_POSITION_INT {time_boot_ms : 104850, lat : 270672300, lon : -824445190, alt : -120, relative_alt : 0, vx : 0, vy : 0, vz : -7, hdg : 0}

STABILIZE> 32090: GLOBAL_POSITION_INT {time_boot_ms : 92475, lat : 270672300, lon : -824445190, alt : -120, relative_alt : 0, vx : 0, vy : 0, vz : -7, hdg : 0}

STABILIZE> status GLOB*

STABILIZE> 32189: GLOBAL_POSITION_INT {time_boot_ms : 104850, lat : 270672300, lon : -824445190, alt : -120, relative_alt : 0, vx : 0, vy : 0, vz : -7, hdg : 0}

Note full autonomous mode (Auto Mode) is wrongly interpreted as TRAINING in the following lines (in my development environment).

After take off and in autonomous mode:-

TRAINING> status GLOB*

TRAINING> 757: GLOBAL_POSITION_INT {time_boot_ms : 328600, lat : 270663660, lon : -824450770, alt : 91880, relative_alt : 92000, vx : -1223, vy : 952, vz : -25, hdg : 3400}

waypoint 4

status GLOB*

TRAINING> 814: GLOBAL_POSITION_INT {time_boot_ms : 335725, lat : 270670950, lon : -824445190, alt : 91880, relative_alt : 92000, vx : -349, vy : 1388, vz : -10, hdg : 7300}

waypoint 5

status

TRAINING> Counters: Slave:0 MasterIn:[5895] FGearOut:0 FGearIn:0 MasterOut:111 

MAV Errors: 0

None

896: ATTITUDE {time_boot_ms : 345950, roll : -0.00968325417489, pitch : 0.0134223317727, yaw : -2.64141893387, rollspeed : -0.042951464653, pitchspeed : 0.00230097025633, yawspeed : -0.0161056518555}

896: GLOBAL_POSITION_INT {time_boot_ms : 345975, lat : 270660870, lon : -824446270, alt : 91880, relative_alt : 92000, vx : 1316, vy : -472, vz : 2, hdg : 20800}

448: GPS_RAW_INT {time_usec : 345900000, fix_type : 3, lat : 270661125, lon : -824446258, alt : 9131, eph : 5, epv : 65535, vel : 1456, cog : 20645, satellites_visible : 4}

448: HEARTBEAT {type : 1, autopilot : 10, base_mode : 221, custom_mode : 3, system_status : 4, mavlink_version : 3}

5: MISSION_CURRENT {seq : 5}

5: MISSION_ITEM_REACHED {seq : 4}

62: PARAM_VALUE {param_id : ASPD_P_KI_LIMIT, param_value : 0.0, param_type : 6, param_count : 62, param_index : 61}

448: RAW_IMU {time_usec : 346000000, xacc : 0, yacc : 0, zacc : 0, xgyro : 0, ygyro : 0, zgyro : 0, xmag : 0, ymag : 0, zmag : 0}

448: RC_CHANNELS_RAW {time_boot_ms : 345900, port : 220, chan1_raw : 1450, chan2_raw : 1425, chan3_raw : 1600, chan4_raw : 1525, chan5_raw : 1700, chan6_raw : 0, chan7_raw : 0, chan8_raw : 0, rssi : 255}

448: SERIAL_UDB_EXTRA_F2_A {sue_time : 304648214, sue_status : 7, sue_latitude : 270661125, sue_longitude : -824446258, sue_altitude : 9131, sue_waypoint_index : 5, sue_rmat0 : -14366, sue_rmat1 : 7872, sue_rmat2 : 212, sue_rmat3 : -7872, sue_rmat4 : -14368, sue_rmat5 : -130, sue_rmat6 : 122, sue_rmat7 : -216, sue_rmat8 : 16382, sue_cog : 20645, sue_sog : 1456, sue_cpu_load : 5, sue_voltage_milis : 0, sue_air_speed_3DIMU : 1456, sue_estimated_wind_0 : -32, sue_estimated_wind_1 : -17, sue_estimated_wind_2 : -2, sue_magFieldEarth0 : 0, sue_magFieldEarth1 : 0, sue_magFieldEarth2 : 0, sue_svs : 4, sue_hdop : 5}

448: SERIAL_UDB_EXTRA_F2_B {sue_time : 304648214, sue_pwm_input_1 : 2900, sue_pwm_input_2 : 2850, sue_pwm_input_3 : 3200, sue_pwm_input_4 : 3050, sue_pwm_input_5 : 3401, sue_pwm_input_6 : 0, sue_pwm_input_7 : 0, sue_pwm_input_8 : 0, sue_pwm_input_9 : 0, sue_pwm_input_10 : 0, sue_pwm_output_1 : 2962, sue_pwm_output_2 : 3012, sue_pwm_output_3 : 2443, sue_pwm_output_4 : 3073, sue_pwm_output_5 : 0, sue_pwm_output_6 : 0, sue_pwm_output_7 : 0, sue_pwm_output_8 : 0, sue_pwm_output_9 : 0, sue_pwm_output_10 : 0, sue_imu_location_x : -12, sue_imu_location_y : -128, sue_imu_location_z : 92, sue_flags : 2528, sue_osc_fails : 0, sue_imu_velocity_x : -472, sue_imu_velocity_y : -1316, sue_imu_velocity_z : -2, sue_waypoint_goal_x : -20, sue_waypoint_goal_y : -160, sue_waypoint_goal_z : 75, sue_memory_stack_free : 0}

447: SYS_STATUS {onboard_control_sensors_present : 0, onboard_control_sensors_enabled : 0, onboard_control_sensors_health : 0, load : 50, voltage_battery : 0, current_battery : 0, battery_remaining : 0, drop_rate_comm : 0, errors_comm : 0, errors_count1 : 0, errors_count2 : 0, errors_count3 : 0, errors_count4 : 0}

896: VFR_HUD {airspeed : 14.5600004196, groundspeed : 14.5399999619, heading : 208, throttle : 22, alt : 91.8799972534, climb : 2.0}

waypoint 6

waypoint 7

Flight battery warning

height 100

height 110

height 120

height 130

waypoint 8

height 140

status GLOB*

TRAINING> 1067: GLOBAL_POSITION_INT {time_boot_ms : 367350, lat : 270669690, lon : -824448700, alt : 147880, relative_alt : 148000, vx : 1009, vy : -535, vz : -433, hdg : 21100}

height 150

height 160

height 170

waypoint 9

height 180

height 190

waypoint 10

[Philip Giacalone]

Pete,

I've commented out the one line you suggested above and also modified the mavlink_options.h file to reduce the traffic from other mavlink messages. 

With these changes, I'm able to received 35 mavlink position messages per second over 3DR radio. The radios are only a few feet apart on my desktop, but this is an encouraging start. 

Flight testing to follow...

Here are the contents of my mavlink_options.h file, for reference.

Best regards,

Phil

// Common data rates

#define MAVLINK_RATE_RC_CHAN                0   // RC_CHANNELS_SCALED, RC_CHANNELS_RAW, SERVO_OUTPUT_RAW |

#define MAVLINK_RATE_IMU_RAW                0   // ATTITUDE_CONTROLLER_OUTPUT, POSITION_CONTROLLER_OUTPUT, NAV_CONTROLLER_OUTPUT. |

#define MAVLINK_RATE_POSITION               1 //was 20   // LOCAL_POSITION, GLOBAL_POSITION/GLOBAL_POSITION_INT messages. |

#define MAVLINK_RATE_RAW_SENSORS            0 //was 2   // IMU_RAW, GPS_RAW, GPS_STATUS packets.

// Fixed data rates

#define MAVLINK_RATE_HEARTBEAT              1 //was 4

#define MAVLINK_RATE_SYSTEM_STATUS          1 //was 4

// Matrixpilot specific data rates

#define MAVLINK_RATE_SUE                    1   // SERIAL_UDB_EXTRA data rate on channel EXTRA1

#define MAVLINK_RATE_POSITION_SENSORS       0   // Using channel EXTRA2

// Send VFR_HUD message at position rate, 1=yes, 0=no.  Needed for correct mavproxy state

#define MSG_VFR_HUD_WITH_POSITION           1

#define MAVLINK_FRAME_FREQUENCY             40

#define MAVLINK_WAYPOINT_TIMEOUT            120 // Dependent on frequency of calling mavlink_output_40hz. 120 is 3 second timeout.

// 19200,38400,57600,115200,230400,460800,921600

// Fixed 19200 for non free running clock

//#define MAVLINK_BAUD                        19200   // now using SERIAL_BAUDRATE in options.h

//#define MAVLINK_BAUD                        115200

// Include code to remove rounding errors on PID values when using QGroundControl

// 1 = Yes, 0 = No

#define QGROUNDCTONROL_PID_COMPATIBILITY    1

#define MAVLINK_EXTERNAL_RX_STATUS          1

[Philip Giacalone]

This change was made to my local copy of Bill's helical turns branch. This is what I plan to fly, unless someone sees a problem. 

Best regards,

Phil

[Tom Pittenger]

I don't see any reason to have the SUE packet enabled.

[Philip Giacalone]

Ok, thanks. I'll disable it. 

[Tom Pittenger]

Pete,

I'm adding a new command to matrixpilot.xml and upon using /tools/MAVLink/mavlink/mavgenerate.py it modifies *a lot* of files and adds and removes some commands throughout. I converted using v1.0. What am I doing wrong? I've attached a pic of the diff that gets generated from it. The file I added via the new command was /matrixpilot/mavlink_msg_position_and_attitude.h as seen in the diff.

[Philip Giacalone]

Hi all,

A flight test was completed today with MatrixPilot modified per Pete's instructions to produce higher mavlink message rates. Mavlink position messages were received via 3DR radio at 20 to 30 messages/second. The message rated varied over a range of 0 to 150 meters. 

The increased message rates gave is better results and were encouraging to see. It's going to get more interesting when the RFD900 radios arrive. Hopefully those will further improve message deliveries. 

Best regards,

Phil

[Peter Hollands]

Tom,

 It is possible that the MAVLink generation files were updated in trunk at the time of the branch being made, but that no one had yet re-generated .h header files. I am still investigating that myself.

 My theory is that you may have updated or created one new message, and then re-generated the mavlink header files, and because they had not been re-generated before with the new generation tools,

then many of the mavlink messages (.h files) may  changed as a result.

Robert and I have had some discussion about that yet, but we are still digging into it.

At the same time, it is high time we updated our core mavlink libraries from the main mavlink repositories, and that is my primary focus now with regard to MAVlink on helical turns branch.

Best wishes, Pete

[Tom Pittenger]

Pete,

You had mentioned you're about to do some work on this branch with regard to MAVLink. Should I wait for you or should I try and fix on my own? If waiting, what is your timeline?

-TomP

[Peter Hollands]

Tom,

Just for ref:

Sue is the best for core developers if fundamental problem occurs during flight. E.g. If it reboots the offending instruction is identified,  or if brownout from poor power it is recorded ( assuming enough power for open log or wireless transmission) Also SUE has all elements of DCM ...

Also flan.py primarily still uses SUE over mavlink. No Sue, No Flan.

So my own preference is to leave Sue on. You could cut back from HZ to 1st if bandwidth is tight.

Best wishes, Pete

[Tom Pittenger]

Bandwidth is indeed right. We are not logginh the data so the sue packet is just being ignored anyway. For now all we are concerned with is getting attitude and gps position ASAP. We are creating a custom packet to optimize that.

[Peter Hollands]

Tom,

I'll work on bringing over  a fresh MAVLink update to Helical turns tomorrow morning (Thursday morning UK time).

Let's see how far I get.

Best wishes, Pete

[Robert Dickenson]

Hi Peter,

Are you basing your work on the https://github.com/mavlink/mavlink repository?

I very recently did a partial merge from this to my working trunk, however for now it was only the 'non-functional' differences (largely copyright headers etc). If this is the same version you are working from, i'll aim to commit my 'cosmetic' updates soon, in order to keep the diff between trunk and helicalTurns as small as possible.

[Philip Giacalone]

Thank you, Pete. Wonderful news. 

FYI. Things are coming together to help our project along: 

  - Increased Mavlink message rates from the UDB

  - A Mavlink update

  - A new/custom Mavlink message type, and 

  - New RFD900 radios

All this is happening in parallel, thanks to the combined efforts of the good folks right here.

Best regards,

Phil

[Peter Hollands]

Robert,

Yes, I will pull the latest version using from the following git repositories:-

https://github.com/mavlink/mavlink.git

https://github.com/tridge/MAVProxy.git

I shall initially create a like for like update. i.e. All the mavlink source and mavproxy source will be in the Tools directory (as is now).

I am planning to do a large initial commit of those files in the Tools directory. That will not effect the source code of the main autopilot at all, as those files are not used directly in compilation.

I shall then generate the .h headers and python code for our project and do a second commit, after testing that MatrixPIlot compiles and flies. 

(This will be my second time through this, as I did it all once at the weekend, so I should be able to get it  to work correctly).

Later, we can decide on how best to script up the /Tolls/MAVLink code so we do not necessarily have the mavlink and MAVproxy code in our repository, but just pull a specific version with a script.

On that point, the MAVProxy official package (at http://tridge.github.io/MAVProxy/ ) has a "--dialect" option. So we will be using 

something like:- 

python mavproxy.py --master=localhost:14550 --dialect matrixpilot

 Using the dialiect command ensures that even the standard packaged mavproxy, will attempt to find out specific and unique matrixpilot mavlink messages (from matrixilot.xml.

I have tested that, and it correctly finding the SERIAL_UDB_EXTRA over MAVlink messages.

All of the above relies on the environment variable, PYTHONPATH, having a path to the top directory of the mavlink code. 

I usually add the top directory of the MAVProxy folder to the PYTHONPATH as well.

Best wishes, Pete