Comments (15)
@iNotMario, I'm not a Plane expert but I think @LupusTheCanine's comment may not be correct. I'm pretty sure that Circle mode (on plane) uses a GPS if present. It probably also works while deadreckoning but if a GPS is present surely it uses it.
According to the wiki, terrain following is not supported in Circle mode.
from ardupilot.
Log Attached... you must bunzip2 it. It's actually a .bin. Or just use SITL ... i can't get it to work under any circumstances - except for a different mode.
log_7_2024-5-2-14-59-12.bin.bz2.log
from ardupilot.
Circle is a non-gps mode therefore it cannot provide terrain following.
from ardupilot.
Circle is a non-gps mode therefore it cannot provide terrain following.
Boy, it sure could fool me - it holds the path like it's laser guided. Anyway, that being the case, we could just ignore that part of the issue.
I definitely think it's an issue that guided mode doesn't honor it. Unfortunately, i suspect there are some seriously complicating factors involving the GCS softwares and how the target coordinates are specified, but it seems to me this is an issue that could cause some costly disasters - and it's worth figuring out a way to deal with it.
from ardupilot.
According to this documentation, GUIDED should support terrain following:
https://ardupilot.org/plane/docs/common-terrain-following.html#terrain-following-flight-modes
Did you enable bit 6 of TERRAIN_FOLLOW
?
It would help if you could give us the steps to reproduce this in SITL.
from ardupilot.
@iNotMario, I'm not a Plane expert but I think @LupusTheCanine's comment may not be correct. I'm pretty sure that Circle mode (on plane) uses a GPS if present. It probably also works while deadreckoning but if a GPS is present surely it uses it.
from ardupilot.
According to this documentation, GUIDED should support terrain following: https://ardupilot.org/plane/docs/common-terrain-following.html#terrain-following-flight-modes
Did you enable bit 6 of
TERRAIN_FOLLOW
?
Both bit 0 (all) and bit 6 have been tried.It would help if you could give us the steps to reproduce this in SITL.
Well honestly, there's not much to describe, but here's a basic set of steps:
- Have Ardupilot Dev Environment (My environment is Fedora, which probably noone here is using, so set it up per the wiki)
- $ sim_vehicle.py -v ArduPlane -f quadplane -w
- Use your preferred GCS to Connect and Set:
3a) TERRAIN_ENABLE=1
3b) TERRAIN_FOLLOW=1 - Wait for Terrain Download (Use your GCS to view the terrain block information if desired)
- QLOITER to an altitude of 100ft.
- Set a waypoint on the far side of Mount Jerrabomberra, and execute.
- Plane should switch to Guided, Transition to Fixed Wing and crash directly into mountain. You can also monitor Alt Above Terrain with your GCS. Watch it slowly go to 0 - it doesn't react to it
Also, for the record re. Circle mode.
CIRCLE is bit 8 in TERRAIN_FOLLOW. Whether it's supposed to work or not, it is nevertheless listed.
QLand is bit 10 ... \o.O/ ... perhaps this param was a bit eager-beavered.
from ardupilot.
Which GCS did you test with? The MAVLink message may be using AMSL instead of AGL altitude.
from ardupilot.
QGroundControl ... However, notably, others have had issues with Mission Planner (see discussion linked in OP).
I can't seem to find any way to change that. But assuming it is sending AMSL, is it really correct to ignore the TERRAIN_FOLLOW flag? After all, i presume the AMSL would be of the destination, not of the path there, so why not follow the terrain until reaching the target at the specified AMSL?
The first thing that comes to mind is to [when TERRAIN_FOLLOW] simply convert the destination to AGL by subtracting the terrain height at that location - then executing as AGL. That would allow terrain following while still honoring the target height.
Of course, right away i find myself wondering how to handle a destination that didn't yet have terrain data - but i think that would be pretty far away...
from ardupilot.
QGroundControl ... However, notably, others have had issues with Mission Planner (see discussion linked in OP). I can't seem to find any way to change that. But assuming it is sending AMSL, is it really correct to ignore the TERRAIN_FOLLOW flag? After all, i presume the AMSL would be of the destination, not of the path there, so why not follow the terrain until reaching the target at the specified AMSL?
The first thing that comes to mind is to [when TERRAIN_FOLLOW] simply convert the destination to AGL by subtracting the terrain height at that location - then executing as AGL. That would allow terrain following while still honoring the target height. Of course, right away i find myself wondering how to handle a destination that didn't yet have terrain data - but i think that would be pretty far away...
As with many things in MAVLink and guided mode, certain cases like this becomes ambiguous on what the "right" behavior is. Whether or not it should do something is ultimately up to what the docs say, and the docs don't seem to specify.
The best near term action is to reproduce this in SITL to confirm the behavior, then perhaps go speak with the MAVLink maintains to ask for what the expected behavior is. Last thing we want is for people to crash into terrain, but the AMSL guided command may intended to be taken as-is and ignore terrain. In this case, clear documentation, and perhaps some warnings in the GCS, could reduce the risk of a crash.
from ardupilot.
So i believe the mavlink specs are defined here:
https://mavlink.io/en/messages/common.html#MAV_FRAME
From the docs, it appears to not actually say anything about the means of getting there, only the coordinate system of the destination - no matter which system is specified. I would infer this means it's specifying something only about the destination - not about the path that Plane takes to get there - and perhaps that's where the decision rests in Plane's hands.
It looks to me like the current behavior for AGL is, itself, a presumption. (A good one, IMO) If we decide that's true, then i think we should apply the assumption to the other "frames", too.
I will do a little digging into QGC and see what it's sending. You're probably right that it's not specifying AGL, i suspect 0 (AMSL) by default, but that's just a guess for now.
from ardupilot.
Thanks. I just tried mavproxy and observed that terrain following works ok with the "Fly to" right click until you fly so fast, it can't get terrain. Rather than abort the flight, it just doesn't load the data and then crashes into terrain.
./Tools/autotest/sim_vehicle.py -v Plane --console --map
graph TERRAIN_REPORT.current_height
param set TERRAIN_FOLLOW 1
mode takeoff
arm throttle
RIght click on the map west of CMAC, and click "Fly to". Enter the altitude. Note - this popup does NOT display the datum.
And, watch the plane's MSL altitude in the GUI console and watch the AGL graph. It's not flying MSL direct, it does try to follow terrain, just not well or optimal efficiency.
from ardupilot.
In my case with QGC, all terrain shows as loaded, and i can watch Alt-Above-Terrain drop towards 0 with no change in AMSL. AKA, Blocks Pending = 0, it still doesn't follow the terrain.
It's not clear to me exactly, but is it that you're using --map to do the "fly to"? I've never used that option before. I will try and see how it reacts with QGC also feeding it terrain data.
from ardupilot.
How are you sending the guided command from QGC? With fly to, I can only fly 3000' horizontally, and mountains are far away
from ardupilot.
QGC has an option in the Application settings for Max distance. "Fly View" -> "Guided Commands" -> "Go to Location Max Distance" (The exact path varies significantly with different versions, i'm describing recent Daily builds)
Mt Jerrabomberra is WSW of the default SITL airport. It's actually pretty close. It's not a very big mountain - but it doesn't need to be.
Edit: My perspective on distance is a probably a bit warped. The mountain is about 3 miles away, so either step your way there with several waypoints, or modify the Max Distance in QGC - which in my case was already set for more than 3 miles.
from ardupilot.
Related Issues (20)
- Can implement Custom Control in Plane HOT 2
- SIM_Plane.cpp uses torque as rotation acceleration when updating simulation dynamics
- Tools- Environment install fails on Ubunru 24.04, no package python-argparse
- DFU / USB Device Descriptor broken in Bootloader HOT 3
- Takeoff in GUIDED mode without GPS/GNSS but SLAM HOT 6
- Rover: SITL RTL_SPEED only allows 1m/s increments contrary to description HOT 1
- Copter: allow Loiter mode surface tracking to use the terrain database
- AP_Camera: 2nd camera should use different PWM output HOT 2
- AP_Mount: DJI RS2/3 should support "follow" during RC rate control
- Ardupilot v4.5.1 Batt4 Percentage Issue HOT 3
- Random values when sending mode switch request in SITL with ROS2 HOT 5
- Copter reverse motors via Lua
- ROS Guided control ambiguous behavior on which control commands have timeout or flyaway risk
- AP_GPS_GSOF: Supply 5Hz GPS for robust EKF
- AP_GPS_GSOF: Initial EAHRS support
- AP_Mount: add support for Siyi ZT6
- Ardupilot V4.5.x - ESC telemetry on the OSD has "stopped working" HOT 3
- ardu plane 4.5.2 flight modes not processed HOT 2
- AP_Mount: Siyi, SToRM32_serial and ViewPro drivers always use 1st gimbal serial device
- MOT_PWM_MIN, MOT_PWM_MAX are reset to default values automatically HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ardupilot.