Conducting low altitude flights (or any flights for that matter) in complex terrain with a plane is very challenging. I would like to summarize some features that we plan on experimenting with in quadplane. This post will serve as a reference for future more detailed conversations on these topics.
- Hybrid SRTM/Rangefinder Terrain Follow
- As of now as far as we have tested, Plane does not support the use of a rangefinder for terrain following. For obvious reasons, it is unlikely that using a rangefinder exclusively in plane for terrain following is a good idea.
- Rctestflight built this functionality for his ground effect plane https://www.youtube.com/watch?v=3heh9swH2Zw&list=PLXvxJNOIXBsMyYPykdtoWRj1m5DRn4CNx but I have not seen his code make it into public circulation
- SRTM data is not reliable in steep terrain and it can have errors in excess of +/-30m. Geophysical data collection missions require low altitude flights <50m agl, thus it is very risky to fly low altitude missions in complex terrain. There is significant commercial interest in these types of surveys in the mineral exploration space; especially since the alternative is using a manned helicopter (expensive and dangerous).
- We have been using copter for years to conduct these surveys as copter supports rangefinder only terrain following, however copters are slow and struggle to compete with manned missions on productivity due to their slowness and short endurance. (Yes hybrids help with endurance but find me one that is not over $40k, isn’t brutally loud and lasts more than 50 flight hours and I’m in)
- We would like to develop a hybridized terrain following system that utilizes the existing SRTM terrain following functionality, but pulls in a downward and forward pointing rangefinder for adjusting for errors in SRTM. This topic requires its own forum topic and will be elaborated on accordingly.
- Evasive maneuvers
- The best example of good evasive maneuvers from my past is the maneuvers performed by the Sensefly Ebee. The Ebee had a simple single beam laser that would trigger a max power climb (effectivly the takeoff sequence) if the drone got within a set distance of the ground or top of the canopy. It even had an evasive maneuver set for dealing with aggressive birds of prey (pretty silly in my opinion but allegedly it was an organic demand)
- Plane does not currently support evasive maneuvers to my knowledge. It would be helpful to have a simple max power climb sequence when a collision with terrain or obstacles was imminent. Obviously this maneuver would not work for every edge case but would solve the majority of our concerns in flying low altitude surveys in the mountains. There may be additional maneuvers like a chandelle or quadplane transition climb that would be appropriate in some cases. Maybe it is worthwhile to study the auto GCAS system in the F35 for inspiration: Auto GCAS: Collision Avoidance System | Lockheed Martin
- As part of this exercise, we have submitted a pull request to allow for the independent addressing of the LW20 lightware range values (first return, last return, filtered first return, and filtered last return) AP_RangeFinder: Added extra drivers for LW20 filtered first and last returns by shaneIntel · Pull Request #26882 · ArduPilot/ardupilot · GitHub
- In the case of terrain following, the drone needs to know its height above terrain (filtered last return), but for the sake of an anti-collision system, filtered first return (top of canopy) would be a value more appropriate for use. SRTM data is sufficient in most cases but having a backup with a rangefinder would give added security especially considering that SRTM is least accurate in the most complex terrain. We understand that there is a more elegant way of accessing the various LW20 values but as a matter of expediency, we have added new rangefinder objects for accessing each return independently. The param based selection will be our next step.
- Obstacle avoidance is a more complex task in high speed forward flight. Cell towers, windmills, etc are particularly problematic because a climb over them would be practically impossible in most cases. In the long run I think it may be possible to categorize obstacles as “fly-over” or “fly-around” obstacles. The FAA publishes a database of obstacles in the US. Maybe this database could be loaded into the drone like the SRTM data in the future? https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/dof/
- Minor RTL fixes in for terrain
- The FLIGHT_OPTIONS bitmask allows for a “Climb to RTL_ALTITUDE altitude before turning toward home in RTL”
- This flag holds the aircraft heading prior to turning for an RTL. It seems to me that it would be more desirable to have a tight orbit loiter climb to altitude prior to RTL. Back to an ebee reference; I believe this is how the ebees were configured.
- Rally points that sequence to RTL rather than land
- Currently Rally points override the landing location. It would be nice to have a rally point behavior that upon arrival sequences an RTL back to the actual home point
- This would allow for placement of rally points downslope so that an RTL will always trigger a turn away from terrain.
- Maybe a better solution would be to do a loiter climb to altitude upon RTL and set the loiter direction by continually interrogating the srtm data to determine which direction is downslope.
- Target ground speed in Plane
- Geophysics, mapping and photo missions are dependent on targeting ground speeds for consistent sample spacing. Massive tailwinds and steep downhill descents result in massive increases in groundspeed. These ground speed variations can become an issue in data collection missions and are particularly problematic with lidar mapping sensors.
- Adding some maximum ground speed limits to plane would be very helpful in improving data quality in high winds and steep terrain. Obviously stall speeds would have to be considered. As of now, users can choose to fly with gps or airspeed; a target ground speed would blend the two.
- As for downhill descents, once the aircraft goes to zero throttle there is not much that can be done to slow the craft down other than add reverse thrust which would consume excessive battery power.
- Adding a provision for speed brakes would be an industry standard solution. SpeedBrakes for the Aviation Industry - Precise Flight Speed brakes could potentially also be used to expedite vtol transitions in quadplanes.
- Presumably adding flaps would also work? But typically flaps are designed for lowering stall speeds and increasing lift. Would want to hear feedback from any aero guys to confirm this hunch.
- We are currently in the process of developing a wing that will support servo driven speed brakes. It will need code to support the functionality. This can easily be done in lua for testing.
There is a lot to chew on here. This post is an effort to memorialize user feedback and ideas for future features in plane. We plan on tackling some of these issues throughout this year and would appreciate feedback on how to best address these problems. I look forward to working on these enhancements with the community.