The ArduPilot development team is delighted to announce the release of 3.8.5. This fixes includes only a very small number of changes to maximise stability. We will separately be announcing the start of the 3.9.0 beta release series soon which includes major changes.
The changes in 3.8.5 over 3.8.4 are:
fixed an issue where the external safety button can activate in flight on some boards, causing them to crash. A new parameter BRD_SAFETYOPTION is added which controls the behaviour of the safety button. The default is to de-activate the safety button when armed.
fixed default orientation of ICM-20948 compass for Here GPS
added support for dual airspeed sensors, allowing for basic failover to a 2nd sensor if a first sensor fails, or for testing a new sensor against an existing sensor
added support for the SDP33 airspeed sensor. This is still considered experimental. There are reports of it underestimating the aircrafts speed at higher altitudes.
add support for the MS5525 airspeed sensor on multiple I2C addresses. Two new values of the ARSDP_TYPE are introduced (4 and 5) for specific I2C addresses. This allows you to deconflict the MS5525 from a MS5611 barometer on the same bus.
fixed a bug when switching from fixed wing flight to QSTABILIZE in tailsitters which could cause zero throttle for 2 seconds. Thanks to Marco for reporting this bug.
@lucamax the main reason I haven’t put effort into Lidar as primary height for AUTO is that very few lidars are reliable above 50m, and planes usually fly higher than that.
What I did put a lot of effort into is the terrain following using SRTM terrain data. That is available now, and works very well. It works at heights that planes tend to fly at.
@tridge Thanks a lot to you and the dev team. You guys are awesome. Any plans on adding support to the eagle tree airspeed sensor. I can help in testing the code on the hardware.
Thanks once again!!!
that shouldn’t be too hard. I had one of those a long time ago, but stopped using it as it wasn’t very good on temperature drift.
I assume you mean the V3 version?
any news on more than one I2C led light as i have 2 here GPS in side a fuse to keep them dry and i have fitted one external led but only the first GPS led works this has been fix on chopper do we have eta on this ?
Thanks All
Yes, @tridge .
The reason for opting to use Eagle tree V3 was support to higher velocity measuring capability. Any other sensor with that velocity measuring capability directly compatible with AP?
Of those the LW20 has the longest range. It can do 100m sometimes (in good lighting conditions), but the reliable range measurement across all light conditions is around 50m. Note that when turning the range is reduced (as the distance from the sensor to the ground is increased). So when doing turns for landing approach you may lose lidar height. To cope with that we would use the Lidar to adjust an offset from barometric height instead of using lidar directly.
We can add support for lidar height in AUTO in the future, and it is something I’d like to add, but it’s not a high priority for me at the moment.
I do not like much the idea of barometric offset , I would prefer a function that over a certain bank angle, selected by user, use another height source, Gps or Baro.
User could also solve the turns Lidar error with an hardware solution , a little gimbal for roll axis i.e. .
About priority, I can only hope for your goodness
But as I wrote before it would allow a big step forward for some users.
Thanks @tridge for the release. Stability improvements are always welcome.
I do not think it is a good idea to switch between height sources. Even when you only feed those to the Kalman filter not use directly, you could end up in a limit-cycle oscillation. Estimating the barometer offset is a better approach in my mind.
For further comparisons, it would be nice, to get both sensor datas via mavlink telemetry. Will it be possible to send both airspeedsensor datas like other sensors by mavlink to the groundcontrolstations ?
(Today, only primary sensor datas choosed by ARSPD_PRIMARY are visible on Missionplanner)
What algorithms are used for detection which sensor fails ?
Do you have to set ARSPD1_USE and ARSPD22 _USE to 1 ? Currently we only enable the ARSPDx_USE of the sensor by which the forwardtranistion is measured as completed.
I’ll put another ping in for Lidar controlled height in plane. We have an aerial survey coming that we want to do at 10m agl. We’ll obviously need a quickly tuned TECS.
Seeing both airspeeds in a GCS would be very good for sanity checking.
Great job on the new release had it out on a nano talon I just built with a MRO pixracer in it. all functions that I use work great, will be hooking up a lidar lite v3 here in an hour or so to test. I was wondering if there would ever be the possibility of having a takeoff flight mode that acts the same as the takeoff command does when planning a mission?
