Open cody303 opened 7 years ago
@cody303 Ok, so I implemented this and then while testing discovered that the landing speed is controlled by parameters in both PX4 and ArduPilot. I tested with ArduPilot and the DO_CHANGE_SPEED seems to have no affect. I've asked a question to the ArduPilot folks about this to see what they say.
Have you heard back from the Ardupilot people? Will the Flap speed param get triggered by the landing speed parameter? That would save a lot of work.
I asked the question on Gitter but got no answer. Do you have anyone from ArduPilot side that you work with on Firmware
I will go and test it this week.
It all worked. Looks like I have been added extra unnecessary steps on each flight. Could we still make the landing distance lock the value?
add a lock button to the landing distance so the landing direction can be dragged around without change the decent angle.
This is a good idea, here are my thoughts:
The lock should apply to Landing dist or Glide slope whichever is selected. this way when the loiter altitude is changed either the distance or glideslope will update approriately (+1 for changing the words to Glide slope https://github.com/mavlink/qgroundcontrol/issues/5952)
The lock should be defaulted to OFF, but remembers your last setting so would be ON the next time you use it. A new default Landing dist or Glide slope would be saved when you enabled the "lock" checkbox.
One "feature" we like with the current QGC functionality is that the default landing pattern distance is too short for our airplane which causes PX4 firmware to send a warning message forcing the user to adjust the length of landing pattern. We view this as an indirect safety check against users trying to use the default landing pattern without adjusting the direction appropriately (this happens frequently!). So: If a "lock" checkbox is implemented we'd like to see some sort of "finalize" feature implemented that would force the user to change something in the default landing pattern (either typing values or dragging direction/location before the landing pattern would be accepted.
In addition to the checkbox items that Antiheavy listed; please create a pop-up warning or some other failsafe feature that will prevent a user from accidentally launching a fixed wing platform without a Landing Pattern being created. I have had a couple of my customers skip that step by accident and have to crash land their drones or come up with some other creative ways to get it back.
When coming from Multirotor to Fixed Wing it's easy to forget that the autopilot isn't going to do everything for you.
please create a pop-up warning or some other failsafe feature that will prevent a user from accidentally launching a fixed wing platform without a Landing Pattern being created. I have had a couple of my customers skip that step by accident and have to crash land their drones or come up with some other creative ways to get it back.
I would say that should be a firmware feature controlled by a parameter. You don't need a ground station to launch a vehicle. If the parameter is set, the check would be a new mission feasability check.
failsafe feature that will prevent a user from accidentally launching a fixed wing platform without a Landing Pattern
PX4 has this feature as long as you use the parameter RTL_TYPE=1. There are still ways to get around it, e.g. take off manually with RC control or if you delete/overwrite the mission while flying, but otherwise it works very well. I'm not sure if Ardupilot has a similar feature.
on Ardupilot fixed wing firmware. On landing the flaps are deployed when a commanded airspeed is below the set flap speed. What we would like to do is add a DO_CHANGE_SPEED before and after the orbit waypoint on landing. The DO_CHANGE_SPEED before the orbit would be to bring the airspeed back to normal flight speed and retract the flaps in the event of an aborted landing, the second DO_CHANGE_SPEED after the loiter to altitude would be the change speed that would deploy the flaps.
The waypoint list would be as follows: DO_LAND_START