Plane 3.8.5 released

I’m disappointed seeing that still no Lidar as primary height source in Auto mode .

1 Like

You could always submit a PR with this functionality?

Congrats on the release Tridge and Team!

@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.

3 Likes

@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!!!

1 Like

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?

@tridge idge.

How about lidar assisted Vtol landing? :slight_smile:

https://discuss.ardupilot.org/t/does-quadplane-take-advantage-of-rangefinder-in-vtol-landing/28426

1 Like

yes, we have that already. I’ve replied to the original question

1 Like

@tridge Lidar as primary height source in Auto mode would also allow to users to develop alternative landing strategies

1 Like

yes, for complex landing approach it could make sense. Right now we only use it on the final part of landing.
What lidar are you thinking of using?

1 Like

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?

@tridge, actually I’m using a Leddar One but I have also a LightWare LW20 and a TFmini.

1 Like

Thank you to Tridge and all the Devs for all their hard work… they are the backbone of this community.

1 Like

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.

1 Like

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 :slight_smile:
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.

Thanks Tridge and all the Devs, especially for supporting dual airspeed sensors.

In the meantime, we did a couple of flights with two airspeedsensors on our VTOL-plane.

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.

Regards Rolf

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?

Can I ask if the BLHeli ESC telemetry improvements made it to Plane 3.8.5 ?