Aircraft heading not updating with MatrixPilot 3.3

[pgiacalo]

The heading of the black aircraft silhouette in mavelous is not updating correctly on a MacBook Pro running OS X 10.8.2.

The nose of the plane is always pointed towards the top of the screen. This was checked on 3 browsers (Firefox, Chrome, and Safari) with the same result.

Checking the following URL show the yaw values correctly updating, going from 0 to +3.14 and then from -3.14 to 0 as the plane yaws around through a full circle. However, the view does not update the plane's heading.

http://127.0.0.1:9999/mavlink/ATTITUDE

[wiseman]

And this is with MatrixPilot v3.3, correct? If it's easy to try arducopter/arduplane, that would be a good test. Can you paste the response you get from the http://127.0.0.1:9999/mavlink/ATTITUDE URL? Thanks!

[pgiacalo]

Yes, sorry, with the MatrixPilot 3.3 running on the UAV Dev Board (UDBv4). Here is a response from the ATTITUDE URL you mentioned above.

{ "ATTITUDE": { "msg": { "pitchspeed": -0.0015339851379394531, "yaw": 0.13805827498435974, "rollspeed": -0.009203910827636719, "time_boot_ms": 180450, "pitch": 0.20727916061878204, "mavpackettype": "ATTITUDE", "yawspeed": 0.004601955413818359, "roll": 0.06289321184158325 }, "index": 725, "time_usec": 180400000 } }

[pgiacalo]

Here's a quick video showing the issue

http://www.youtube.com/watch?v=9UsjRJnXduA&feature=youtu.be

[wiseman]

Thanks for the video, Phil. I was thinking I'd try running MatrixPilot myself, but it doesn't look like there's any way to do a software-in-the-loop simulation (that is, no UAV Dev Board)--is that right?

[wiseman]

Actually, if you can send me some of your mavlink logs that will probably help. To tell mavproxy to log mavlink messages, give it an --aircraft flag when you start it, like "--aircraft=UDB'. That will create a directory called UDB and save the logs under it.

[pchickey]

I suspect the root of this problem is that MatrixPilot uses the ATTITUDE method where ArduCopter uses the VFR_HUD method. In ArduCopter, the ATTITUDE message heading field is populated with float ahrs.yaw, and the VFR_HUD message heading field is populated with an integer ahrs.yaw_sensor (modulo a transformation to the correct units, I guess?). Based on everything I can tell about the AHRS code, these should be equivelant and are just exposed as different types for some reason.

Not being at all familiar with MatrixPilot, my first guess would be that the VFR_HUD message doesn't have heading implemented correctly. It would be nice for MatrixPilot to fix that bug to be more conformant with the Mavlink spec, but I don't fault MatrixPilot on this one - the Mavlink spec is quite large and occasionally redundant, as it is here.

So, the best bet may be to switch the droneview.js code to subscribe to the ATTITUDE heading rather than the VFR_HUD heading.

On Wed, Nov 14, 2012 at 3:49 PM, John Wiseman notifications@github.comwrote:

Thanks for the video, Phil. I was thinking I'd try running MatrixPilot myself, but it doesn't look like there's any way to do a software-in-the-loop simulation (that is, no UAV Dev Board)--is that right?

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/issues/22#issuecomment-10391475.

[wiseman]

Patrick, thanks for catching that we're actually using VFR_HUD instead of ATTITUDE in mavelous to get heading--I think I was confusing this with the roll display issue.

[wiseman]

And now I notice in the video Phil linked to, both altitude and airpspeed, which also come from VFR_HUD, are bad.

[pgiacalo]

Thanks for working on this, guys. Just to catch up...   Yes, you'd need to have a UDB board to run MatrixPilot (so far as I'm aware).   Question: I also noticed that the data returned from the ATTITUDE URL did not include a heading field. Can I perform another simple test like yesterday -- by hitting a different URL -- to get the heading data? What is the URL? Or would it be better to start mavelous with the "--aircraft=UDB" option to get data to send you.   I'd like to work with you guys to run whatever tests you suggest to demonstrate conclusively that there's an issue with MatrixPilot. Once we've done that, I can take it back to the MatrixPilot team. I can run tests tonight if you'll give me the procedure.     Thanks again.      

---

From: John Wiseman notifications@github.com To: wiseman/mavelous mavelous@noreply.github.com Cc: Philip Giacalone philip_giacalone@yahoo.com Sent: Wednesday, November 14, 2012 4:10 PM Subject: Re: [mavelous] Aircraft heading not updating with MatrixPilot 3.3 (#22)

Patrick, thanks for catching that we're actually using VFR_HUD instead of ATTITUDE in mavelous to get heading--I think I was confusing this with the roll display issue. — Reply to this email directly or view it on GitHub.

[pchickey]

In the ATTITUDE message the heading is called yaw.

Can you show us a sample result of the VFR_HUD URL? My guess is that MatrixPilot is either sending bad values for the VFR_HUD fields, or no VFR_HUD mavlink messages at all.

Once you narrow that down a bit I suggest you file a bug with the MatrixPilot developers to look into their implementation of the VFR_HUD message.

[pgiacalo]

One other thing... The MatrixPilot documentation says that MAVLink wire protocol 1.0 is supported. Protocol 0.9 is not.

[pchickey]

I did a very quick grep and I'm not at all familiar with the MatrixPilot source or build, but the first sanity check is for whether MatrixPilot is being built with support for the VFR HUD message turned on? Looks here like it can be disabled via macro: http://code.google.com/p/gentlenav/source/browse/trunk/MatrixPilot/MAVLink.c#1627

Also, looks like airspeed and groundspeed are always sent as 0.0 - We need airspeed in the VFR_HUD message for the airspeed indicator tape on the PFD to work properly.

[pchickey]

Mavelous supports Mavlink 1.0 only (no support for 0.9) so we should be good there.

[pgiacalo]

Ok, same version, great. Thanks for the URL. I'll run that test soon/tonight and post the results.

[wiseman]

BTW, Phil, http://127.0.0.1:9999/mavlink/* should show all the mavlink messages coming from MatrixPilot.

[pgiacalo]

Ok, the VFR_HUD response is {} We're getting zippo...

Thanks for the mavlink/* URL. Here's what that returns.

{
  "RAW_IMU": {
    "msg": {
      "xgyro": 0, 
      "zmag": 0, 
      "ygyro": 0, 
      "xmag": 0, 
      "zacc": 0, 
      "xacc": 0, 
      "yacc": 0, 
      "zgyro": 0, 
      "mavpackettype": "RAW_IMU", 
      "ymag": 0, 
      "time_usec": 450750000
    }, 
    "index": 1271, 
    "time_usec": 450650000
  }, 
  "SYS_STATUS": {
    "msg": {
      "onboard_control_sensors_present": 0, 
      "load": 90, 
      "battery_remaining": 0, 
      "errors_count4": 0, 
      "drop_rate_comm": 0, 
      "errors_count2": 0, 
      "errors_count3": 0, 
      "errors_comm": 0, 
      "current_battery": 0, 
      "errors_count1": 0, 
      "onboard_control_sensors_health": 0, 
      "mavpackettype": "SYS_STATUS", 
      "onboard_control_sensors_enabled": 0, 
      "voltage_battery": 0
    }, 
    "index": 1286, 
    "time_usec": 450650000
  }, 
  "META_LINKQUALITY": {
    "msg": {
      "master_in": 14284, 
      "mav_loss": 2593, 
      "mavpackettype": "META_LINKQUALITY", 
      "master_out": 318, 
      "packet_loss": 18.276007893994926
    }, 
    "index": 319, 
    "time_usec": 450650000
  }, 
  "ATTITUDE": {
    "msg": {
      "pitchspeed": 0.0, 
      "yaw": 1.1001518964767456, 
      "rollspeed": 0.0, 
      "time_boot_ms": 450825, 
      "pitch": 0.11524031311273575, 
      "mavpackettype": "ATTITUDE", 
      "yawspeed": -0.0053691864013671875, 
      "roll": 0.0261735487729311
    }, 
    "index": 2572, 
    "time_usec": 450650000
  }, 
  "GLOBAL_POSITION_INT": {
    "msg": {
      "vx": -4067, 
      "lon": -900157565, 
      "time_boot_ms": 450850, 
      "hdg": 15200, 
      "relative_alt": 2782000, 
      "vy": 9243, 
      "lat": 376415190, 
      "mavpackettype": "GLOBAL_POSITION_INT", 
      "alt": 2783400, 
      "vz": -1189
    }, 
    "index": 2573, 
    "time_usec": 450650000
  }, 
  "GPS_RAW_INT": {
    "msg": {
      "fix_type": 3, 
      "cog": 6453, 
      "epv": 65535, 
      "lon": -900162048, 
      "time_usec": 450650000, 
      "eph": 5, 
      "satellites_visible": 4, 
      "lat": 376413040, 
      "mavpackettype": "GPS_RAW_INT", 
      "alt": 277875, 
      "vel": 10192
    }, 
    "index": 1270, 
    "time_usec": 450650000
  }, 
  "HEARTBEAT": {
    "msg": {
      "custom_mode": 0, 
      "system_status": 4, 
      "base_mode": 216, 
      "autopilot": 3, 
      "mavpackettype": "HEARTBEAT", 
      "type": 1, 
      "mavlink_version": 3
    }, 
    "index": 1286, 
    "time_usec": 450650000
  }, 
  "PARAM_VALUE": {
    "msg": {
      "param_index": 62, 
      "param_count": 63, 
      "param_type": 6, 
      "param_id": "ASPD_P_KI_LIMIT", 
      "mavpackettype": "PARAM_VALUE", 
      "param_value": 0.0
    }, 
    "index": 62, 
    "time_usec": 134400000
  }, 
  "RC_CHANNELS_RAW": {
    "msg": {
      "chan4_raw": 0, 
      "chan2_raw": 1533, 
      "chan6_raw": 983, 
      "time_boot_ms": 450650, 
      "chan1_raw": 1483, 
      "chan5_raw": 819, 
      "chan3_raw": 1906, 
      "chan7_raw": 1638, 
      "mavpackettype": "RC_CHANNELS_RAW", 
      "chan8_raw": 0, 
      "port": 235, 
      "rssi": 0
    }, 
    "index": 1270, 
    "time_usec": 450650000
  }
}

[pgiacalo]

Pat's link above to the MatrixPilot code led me to a mavlink_options.h file. There's a flag called MSG_VFR_HUD_WITH_POSITION that is currently turned off!! Blush.... I'll rebuild, reprogram the UDB and try the test again. Stay tuned.

[pgiacalo]

Ok, some VFR_HUD values are being returned with zero for the heading regardless of the actual value. And of course the browser is not updating the heading.

{ "VFR_HUD": { "msg": { "throttle": 0, "groundspeed": 0.0, "airspeed": 0.0, "climb": 109.0, "mavpackettype": "VFR_HUD", "alt": 3243.0, "heading": 0 }, "index": 3947, "time_usec": 569400000 } }

[pgiacalo]

Just tried the earlier suggestion to subscribe to ATTITUDE in droneview.js. But it's still not working to update drone heading shown in the browser.

Here are the code changes tried to droneview.js

$(function(){ window.Mavelous = window.Mavelous || {}; Mavelous.DroneView = Backbone.View.extend({

initialize: function () {
  var mavlink = this.options.mavlinkSrc;

// this.model = mavlink.subscribe('VFR_HUD', this.onHeadingChange, this); //original this.model = mavlink.subscribe('ATTITUDE', this.onHeadingChange, this); //changed 11/14/2012 this.drone = document.getElementById('droneicon'); },

onHeadingChange: function () {

// this.rotateDrone(this.model.get('heading')); //original this.rotateDrone(this.model.get('yaw')); //first change 11/14/2012 // this.rotateDrone((this.model.get('yaw')) * 360/6.28); //second change 11/14/2012 },

rotateDrone : function ( angle ) {
  var rotate = 'rotate(' + (angle) + 'deg);';
  var tr = new Array(
      'transform:' + rotate,
      '-moz-transform:' + rotate,
      '-webkit-transform:' + rotate,
      '-ms-transform:' + rotate,
      '-o-transform:' + rotate
  );
  this.drone.setAttribute('style', tr.join(';'));
}

}); });

[pgiacalo]

FYI. I've posted a message to the UAV Dev Board group to look into the VFR_HUD implementation in MatrixPilot 3.3.

Thanks again for your help, guys. I'll post back here with progress info.

[pgiacalo]

Just getting back to you with an update. I've been testing the MatrixPilot code and have modified the logic to send the following VFR_HUD message with fixed values to mavelous.

{ "VFR_HUD": { "msg": { "throttle": 80, "groundspeed": 220.0, "airspeed": 200.0, "climb": 109.0, "mavpackettype": "VFR_HUD", "alt": 3243.0, "heading": 270 }, "index": 3947, "time_usec": 569400000 } }

Even with these non-zero values arriving at mavelous, the drone graphic in the browser is still always pointing north. I had expected it to point west, since the heading is now set at 270. I also tried setting is at 27000, since I wasn't sure if the angle should be multiplied by 100, but it still points north.

Are values required in some other mavlink messages in order to update the heading?

Thanks, Phil

[pchickey]

That packet looks right from here so it's difficult to say what your issue may be. Can you add a console.log(rotate); under the definition of var rotate in the body of rotateDrone in droneview.js, and send us the results?

[pgiacalo]

Finally back to close the loop on this. The problem was on my side and has been resolved. I've been using mavelous happily ever since. Here's a posting that talks about a recent flight test of 3DR 915 MHz radios with the UAV Dev Board and the mavelous ground station.

http://groups.google.com/group/uavdevboard/browse_thread/thread/65b7ef07276b22bc

Thanks again for the great software.

[wiseman]

Glad it worked out for you Philip. If you have any feedback on features you miss most and end up using QGC for, let us know.

John

On Sun, Dec 2, 2012 at 2:43 AM, Philip Giacalone notifications@github.comwrote:

Finally back to close the loop on this. The problem was on my side and has been resolved. I've been using mavelous happily ever since. Here's a posting that talks about a recent flight test of 3DR 915 MHz radios with the UAV Dev Board and the mavelous ground station.

http://groups.google.com/group/uavdevboard/browse_thread/thread/65b7ef07276b22bc

Thanks again for the great software.

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/issues/22#issuecomment-10928232.

[pgiacalo]

Thanks again, John.

Yes, it would be great if there was a dynamic data plotting feature. A way to select one or more Mavlink fields to yield a graph. Something like this would be useful.

http://www.highcharts.com/demo/dynamic-update

---

From: John Wiseman notifications@github.com To: wiseman/mavelous mavelous@noreply.github.com Cc: Philip Giacalone philip_giacalone@yahoo.com Sent: Sunday, December 2, 2012 10:42 AM Subject: Re: [mavelous] Aircraft heading not updating with MatrixPilot 3.3 (#22)

Glad it worked out for you Philip. If you have any feedback on features you miss most and end up using QGC for, let us know.

John

On Sun, Dec 2, 2012 at 2:43 AM, Philip Giacalone notifications@github.comwrote:

Finally back to close the loop on this. The problem was on my side and has been resolved. I've been using mavelous happily ever since. Here's a posting that talks about a recent flight test of 3DR 915 MHz radios with the UAV Dev Board and the mavelous ground station.

http://groups.google.com/group/uavdevboard/browse_thread/thread/65b7ef07276b22bc

Thanks again for the great software.

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/issues/22#issuecomment-10928232.

— Reply to this email directly or view it on GitHub.