Plane 3.8.3 released

This is a minor release with a number of important bug fixes and some small feature additions.

The most important general fixes are for an I2C device detection bug and fixing the implementation of MANUAL_RCMASK.

There are quite a number of small fixes in lots of areas, plus big improvements to the handling of tailsitter transitions.

Another significant change is to the handling of transitions from RTL to QRTL when Q_RTL_MODE=1. We now transition to QRTL at a distance which is the maximum of RTL_RADIUS and a distance calculated based on a new Q_TRANS_DECEL “transition deceleration” parameter. That allows you to tune the amount of deceleration you want in the transition according to how much drag your quadplane has. This also means it automatically accounts for wind speed and approach speed in calculating the transition point.

We have also added a new Q_OPTIONS parameter which is a bitmask of option flags to control quadplane behaviour. We have three options so far. The first is to allow for keeping the wings within LEVEL_ROLL_LIMIT degrees during transitions, for users that prefer transitions to be kept level. The 2nd and 3rd options are to treat NAV_TAKEOFF as NAV_VTOL_TAKEOFF and NAV_LAND as NAV_VTOL_LAND in quadplane missions, so that you can use GCS software that doesn’t know
about the VTOL takeoff and land commands.

Other changes include:

  • allow vertical takeoffs in GUIDED mode with Q_GUIDED_MODE=0
  • fixed a bug in implementation of MANUAL_RCMASK
  • eliminate airspeed positive bias after offset zero
  • prevent quadplane controller windup on the ground
  • added Q_MAV_TYPE for setup of VTOL vehicle type for QGC
  • improved performance of FlightAxis SITL
  • support LOITER_TO_ALT in quadplanes
  • fixed a bug in TECS related to descending quadplane transitions
  • added Q_OPTIONS for controlling roll during transitions and allowing for fixed wing takeoff and landing
  • fixed a race condition in IMU logging
  • fixed a race in i2c device probing
  • log critical messages while disarmed
  • added IST8310 compass on FMUv3 I2C
  • probe for QMC5883 by default
  • avoid double detection of AK09916 compass
  • smooth out tailsitter transitions in both directions
  • fixed use of RTL_RADIUS for QRTL threshold and added Q_TRANS_DECEL
  • fixed course unlocking with rudder in CRUISE mode

We hope you have as much fun flying this release as we had producing it.

Happy flying!

6 Likes

Tridge

Thanks as always for your excellent work on ArduPlane. Can you tell me which files were modified regarding “fixed a race in i2c device probing”? I’m currently experiencing problems detecting an MS4525DO digital AirSpeed sensor on I2C.

And so that you can teach this fisherman to fish and not just ask for fish, how do I search a master branch for an expression in a file? Always a fan of self-help, I see how to find file by typing in elements of a file name, but how do I search a branch or subdirectory of a branch for a specific expression?

Thanks,
Kelly

sure, this was the patch:

I usually use “git grep EXPRESSION”, but there are actually many ways to do this. It depends what tools you use. I use the command line on Linux.
Cheers, Tridge

Hi Tridge, just did a test flight with the 3.8.3 firmware on a quadplane.

Works:

  • Q_OPTIONS was set to 0 and NAV_TAKEOFF worked as NAV_VTOL_TAKEOFF as expected
  • Q_TRANS_DECEL was set to 5 m/s/s, with our airspeed of 15.1, it’s logged as transitioning at about 25 meters (NTUN.WpDist) from the RTL point as expected.
  • Transitions to quadplane flight occurs exactly at correct waypoint (the one before NAV_VTOL_LAND)
  • Rest of flight otherwise shows no regressions from 3.8.2
    Attached log here, one more

Doesn’t work:

  • Not sure if this is a regression (first time testing), but using Absolute Altitude as an altitude reference does not seem to work. The values we entered for absolute altitude for waypoints in Mission Planner were treated as Relative waypoints in Ardupilot. I can see the same effect in SITL if I try to use absolute altitude (this time using APM Planner, and the misseditor module).

In this log - the takeoff height was supposed to be around 60m Absolute (aircraft is 30m Abs on the ground) - the aircraft climbs past that (reached much more than 30m relative altitude). This is the waypoint file used, and this is the relevant TLOG.

Have I made a mistake somewhere (parameter perhaps?) when trying to use absolute altitude?

Thanks for the report!

the waypoint file you linked to has relative altitude waypoints. The 3rd column is ‘3’ for all waypoints, which is global position, relative altitude. For global position, absolute altitude it would need to be a zero.
Note that VTOL takeoff and land (and normal wheeled takeoff as well) only ever use relative altitude for the takeoff height. Waypoints can be absolute or relative.
I suspect the issue is with the GCS (MissionPlanner in your case?). Maybe check carefully in the waypoint editor in MP to check you have it setup with absolute altitude?
Also, I don’t think MP supports doing a mixture of absolute and relative altitude in a mission. ArduPilot does support it, but I think MP always sets all waypoints the same.
Cheers, Tridge

Wow, that’s really strange. Mission Planner even prompted me with “Absolute Altitude selected, are you sure!” before I wrote the waypoints to the aircraft. When I changed the waypoint file manually to set all non-takeoff and land waypoints to frame ‘0’, it behaved as expected during a SITL flight.

I noticed this effect as well - because one of my intended landing points in Papua New Guinea is lower than my takeoff location, the aircraft prematurely enters the LAND_FINAL phase in SITL. Did CanberraUAV use absolute altitude for the Outback Challenge, and did you ever have to work around any of these problems?

@tridge I think I discovered why this is the case. I used mavmission.py to get the waypoints out from my .BIN file - and I think that program might have a bug. I just bench tested this - I uploaded this waypoint file, armed the aircraft and downloaded this log file afterwards, and after using mavmission.py I got this waypoint file. The difference is that mavmission.py seems to save all waypoints in the relative altitude frame - either that or the aircraft interprets it as relative altitudes?