MavLinkMultirotorApi: correctly set the HIL_SENSOR fields_updated field #2549

TSC21 · 2020-04-08T09:58:24Z

Fixes the reported in #2477 (comment).

The interface with the PX4 simulator module was changed to allow that different sensor sources get processed at different rates, which what you expect from a real system. In this case, since the sensor sources are not being sent at different rates, I basically just set the fields_updated bitmask correctly so it can be interpreted in the simulator module and the sensor data can be parsed.

FYI @bys1123, @Jaeyoung-Lim, @LorenzMeier.

TSC21 · 2020-04-08T10:32:28Z

@madratman @rajat2004 @saihv FYI and review. Thanks!

AirLib/include/vehicles/multirotor/firmwares/mavlink/MavLinkMultirotorApi.hpp

bmalhigh · 2020-04-08T17:33:47Z

@TSC21 - Thanks for making the fix!

Couple of questions for my understanding --

Is this change backwards compatible with old versions of PX4?
How often does the PX4 simulator interface change?

Thanks again!

TSC21 · 2020-04-08T17:40:05Z

@TSC21 - Thanks for making the fix!

Couple of questions for my understanding --

Is this change backwards compatible with old versions of PX4?

How often does the PX4 simulator interface change?

Thanks again!

Hi @bmalhigh!

Yes it is;
This was a breaking change, which doesn't usually happen, but was seen as required to guarantee we can get sensors at different rates.

To guarantee both above, I would suggest we could align on helping you setup and CI integration test pipeline with PX4 SITL that is synced with our latest stable release but also with our upstream master. What do you think?

bmalhigh · 2020-04-08T18:10:35Z

Hi @bmalhigh!

Yes it is;

This was a breaking change, which doesn't usually happen, but was seen as required to guarantee we can get sensors at different rates.

To guarantee both above, I would suggest we could align on helping you setup and CI integration test pipeline with PX4 SITL that is synced with our latest stable release but also with our upstream master. What do you think?

@TSC21 - Thanks for the clarification.
w.r.t. how to prevent such breaks in future -- I agree with the principle/desire to setup CI integration. We need to investigate this bit more w.r.t. what guarantees it will provide, amount of effort needed as well as the timeline for this. Taking this offline with few folks.

@guadacasuso - FYI on this discussion about CI

madratman · 2020-04-08T22:25:28Z

LGTM, and works fine in linux. Thanks for the quick action @TSC21. We'll make a new linux release ASAP @Jaeyoung-Lim

bys1123 · 2020-04-09T07:54:57Z

Tried on windows, looks like the accel didn't connected.

ERROR [px4_work_queue] setting sched params for wq:lp_default failed (134)
INFO  [ecl/EKF] 2451375: GPS checks passed (WGS-84 origin set)
INFO  [mavlink] mode: Normal, data rate: 4000000 B/s on udp port 18570 remote port 14550
ERROR [sensors] Accel #0 fail:  TIMEOUT!
ERROR [sensors] Sensor Accel #0 failed. Reconfiguring sensor priorities.
WARN  [sensors] Remaining sensors after failover event 0: Accel #0 priority: 1
WARN  [sensors] Remaining sensors after failover event 0: Accel #1 priority: 0
WARN  [sensors] Remaining sensors after failover event 0: Accel #2 priority: 0
ERROR [sensors] Accel #0 fail:  TIMEOUT!
ERROR [sensors] Sensor Accel #0 failed. Reconfiguring sensor priorities.
WARN  [sensors] Remaining sensors after failover event 0: Accel #0 priority: 1
WARN  [sensors] Remaining sensors after failover event 0: Accel #1 priority: 0
WARN  [sensors] Remaining sensors after failover event 0: Accel #2 priority: 0
ERROR [sensors] Accel #0 fail:  TIMEOUT!
ERROR [sensors] Sensor Accel #0 failed. Reconfiguring sensor priorities.
WARN  [sensors] Remaining sensors after failover event 0: Accel #0 priority: 1
WARN  [sensors] Remaining sensors after failover event 0: Accel #1 priority: 0
WARN  [sensors] Remaining sensors after failover event 0: Accel #2 priority: 0
ERROR [sensors] Accel #0 fail:  TIMEOUT!
ERROR [sensors] Sensor Accel #0 failed. Reconfiguring sensor priorities.
WARN  [sensors] Remaining sensors after failover event 0: Accel #0 priority: 1
WARN  [sensors] Remaining sensors after failover event 0: Accel #1 priority: 0
WARN  [sensors] Remaining sensors after failover event 0: Accel #2 priority: 0
ERROR [sensors] Accel #0 fail:  TIMEOUT!
ERROR [sensors] Sensor Accel #0 failed. Reconfiguring sensor priorities.
WARN  [sensors] Remaining sensors after failover event 0: Accel #0 priority: 1
WARN  [sensors] Remaining sensors after failover event 0: Accel #1 priority: 0
WARN  [sensors] Remaining sensors after failover event 0: Accel #2 priority: 0
ERROR [sensors] Accel #0 fail:  TIMEOUT!
ERROR [sensors] Sensor Accel #0 failed. Reconfiguring sensor priorities.
WARN  [sensors] Remaining sensors after failover event 0: Accel #0 priority: 1
WARN  [sensors] Remaining sensors after failover event 0: Accel #1 priority: 0
WARN  [sensors] Remaining sensors after failover event 0: Accel #2 priority: 0
ERROR [sensors] Accel #0 fail:  TIMEOUT!
ERROR [sensors] Sensor Accel #0 failed. Reconfiguring sensor priorities.
WARN  [sensors] Remaining sensors after failover event 0: Accel #0 priority: 1
WARN  [sensors] Remaining sensors after failover event 0: Accel #1 priority: 0
WARN  [sensors] Remaining sensors after failover event 0: Accel #2 priority: 0

ibrhm0v · 2020-05-12T21:33:51Z

I started to face problems after #2549 followed by #2556 with px4 v1.9.0 and AirSim v1.2.2 on Ubuntu 18.04LTS, all builded from source. I also packaged AirSim in shipping mode.

I usually connect AirSim to SITL with tcp 4560 and leave controlIp empty. Then I connect my own GCS (I face same behaviour on QGC, as an additional information QGC cannot connect through the default 14550 as it says the binded port is already in use) through 14540 (local) to 14580 (remote/SITL). Prior to these PRs I used to run flight over SITL as well as HITL. Despite getting the errors as @madratman in comment.

My settings.json file is as follows: (please do not mind the distance sensor details as I updated the code and sensor settings a bit.)

 {
  "SettingsVersion": 1.2,
  "SimMode": "Multirotor",
  "PawnPaths": {
    "DefaultQuadrotor": {"PawnBP": "Class'/Game/Blueprints/BP_FlyingPawn.BP_FlyingPawn_C'"} },

"DefaultSensors": {
    "Barometer": {
         "SensorType": 1,
         "Enabled" : true
    },
    "Imu": {
         "SensorType": 2,
         "Enabled" : true
    },
    "Gps": {
         "SensorType": 3,
         "Enabled" : true
    },
    "Magnetometer": {
         "SensorType": 4,
         "Enabled" : true
    },

    "DistanceFront": {
         "SensorType": 5,
         "Enabled" : true,
	 "MinDistance": 0,
	 "MaxDistance": 100,
	 "X": 1, "Y": 0, "Z": 0,
	 "Roll": 0, "Pitch": 0, "Yaw" : 0
    },
  
    "DistanceBelow": {
         "SensorType": 5,
         "Enabled" : true,
	 "MinDistance": 0,
	 "MaxDistance": 100,
	 "X": 0, "Y": 0, "Z": 0,
	 "Roll": 0, "Pitch": -90, "Yaw" : 0
    },
    
     "Lidar": { 
         "SensorType": 6,
         "Enabled" : true,
         "NumberOfChannels": 4,
         "PointsPerSecond": 10000
    }

},

  "OriginGeopoint": {
    "Latitude": 39.9334, 
    "Longitude": 32.8597,
    "Altitude": 889
  },

   "Vehicles": {
    "PX4": {
      "VehicleType": "PX4Multirotor",
      "Model": "MyDrone",
      "SerialBaudRate": 921600,
      "SerialPort": "*",
      "UseSerial": false,
      "UseTcp": true,
      "TcpPort": 4560,
      "ControlIp": "",
      "ControlPort": 14590,
      "UdpIp": "",
      "UdpPort": 14600,
      "VehicleCompID": 1,
      "VehicleSysID": 142,
      "LocalHostIp": "127.0.0.1",
      "params": {
          "NAV_RCL_ACT": 0,
          "NAV_DLL_ACT": 0,
          "LPE_LAT": 47.641468,
          "LPE_LON": -122.140165,
          "COM_OBL_ACT": 1
                }
    }
}
}

My problem now is; as soon as I start the simulation everything in the garden is rosy. But in few seconds the connection is lost with no messages on the SITL command shell. And the drone rolls over and falls, then it takes off few meters and repeats this roll over-fall-takeoff cycle forever

MavLinkMultirotorApi: correctly set the HIL_SENSOR fields_updated field

bf0e198

TSC21 mentioned this pull request Apr 8, 2020

[Proposal] Create a new branch for AirSim compatibility PX4/PX4-Autopilot#14615

Closed

rajat2004 mentioned this pull request Apr 8, 2020

Communication Error when adding Lidar and using PX4 #2527

Closed

rajat2004 reviewed Apr 8, 2020

View reviewed changes

AirLib/include/vehicles/multirotor/firmwares/mavlink/MavLinkMultirotorApi.hpp Show resolved Hide resolved

Jaeyoung-Lim mentioned this pull request Apr 8, 2020

Plan for a new Linux release? / PX4 Master compatibility #2477

Closed

madratman merged commit 73f60f2 into microsoft:master Apr 8, 2020

TSC21 deleted the fix/hil_sensor_bitmask_set branch April 9, 2020 08:35

madratman mentioned this pull request Apr 9, 2020

[px4] bug-fix: MavLinkMultirotorApi::sendHILSensor() #2556

Merged

lovettchris mentioned this pull request May 1, 2020

WARN [mc_pos_control] Offboard activation failed with error: Activation Failed PX4/PX4-Autopilot#14786

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MavLinkMultirotorApi: correctly set the HIL_SENSOR fields_updated field #2549

MavLinkMultirotorApi: correctly set the HIL_SENSOR fields_updated field #2549

TSC21 commented Apr 8, 2020 •

edited

Loading

TSC21 commented Apr 8, 2020

bmalhigh commented Apr 8, 2020

TSC21 commented Apr 8, 2020

bmalhigh commented Apr 8, 2020

madratman commented Apr 8, 2020

bys1123 commented Apr 9, 2020

ibrhm0v commented May 12, 2020

MavLinkMultirotorApi: correctly set the HIL_SENSOR fields_updated field #2549

MavLinkMultirotorApi: correctly set the HIL_SENSOR fields_updated field #2549

Conversation

TSC21 commented Apr 8, 2020 • edited Loading

TSC21 commented Apr 8, 2020

bmalhigh commented Apr 8, 2020

TSC21 commented Apr 8, 2020

bmalhigh commented Apr 8, 2020

madratman commented Apr 8, 2020

bys1123 commented Apr 9, 2020

ibrhm0v commented May 12, 2020

TSC21 commented Apr 8, 2020 •

edited

Loading