ArduPilot / ardupilot

ArduPlane, ArduCopter, ArduRover, ArduSub source
http://ardupilot.org/
GNU General Public License v3.0
10.85k stars 17.3k forks source link

Copter: Transition to Brake prior to executing Failsafe action #8341

Open lordneeko opened 6 years ago

lordneeko commented 6 years ago

Feature Request details

Not an issue, but an observation. Some part my fault, some part the mechanics of how the system operates. When flying Sport mode, I was in and out of some obstacles. The Battery critical failsafe was set to RTL, which is fine, except it occurred at the precise moment I was straffing around said obstacles. Because the RTL action occurred with excessive lateral momentum, the drone maintained that momentum without agressively stopping movement. That momentum carried it right into the object. Without question I could have either not had that as my failsafe, or switch back to a controllable mode (which is what I almost always do anyways), but the former was an afterthought, and the latter was not possible given how quickly the action occurred.

My suggestion is the addition of "Brake Mode" until movement is halted, and then progress to the failsafe mode. This would potentially (hopefully) be a parameterized option, because i'm sure there are those that wouldn't want this to occur.

Additionally, it would be an option for each of the main failsafe functions (battery, low_throttle, etc)

Platform

[ ] All [ ] AntennaTracker [X ] Copter [ ] Plane [ ] Rover [ ] Submarine

Airframe type

Quadcopter

rmackay9 commented 6 years ago

Thanks for the report. when transitioning to RTL or Land during a failsafe it projects a stopping point based on the vehicle's velocity and configured maximum acceleration/deceleration. So the vehicle should slow down more quickly horizontally by increasing the WPNAV_ACCEL parameter. The same controller is used for RTL/Land and brake, it's just the acceleration that is used that is different.

lordneeko commented 6 years ago

Hmm I feel like transitioning to brake happens a lot faster...but that's on my Solo, which has a dedicated brake button...maybe they modified it? But also on my Solo, when it transitions to RTL it is "smoother" but at the same time it'll continue on the current path longer than pressing brake.

I'll observe a little more though...

Kiwa21 commented 6 years ago

@rmackay9 if land FS happens for a GPS loss for example, you can see the copter drifting at the same horizontal speed than when navigating while landing.. Which is scary!

I share the view of @lordneko here. A very simple brake could be implemented to avoid some ballistic issues. Again not sure it will benefit the mass..

rmackay9 commented 6 years ago

@Kiwa21, Brake relies on having a good position and velocity estimate. I wish it weren't so but bringing the vehicle to a stop requires knowing how fast it's going. For a GPS/EKF failsafe, we simply don't know how fast the vehicle is going anymore and the speed and position estimates degrade very quickly. I'm definitely open to people trying to find a fix but it's not easy I think.

There's a similar discussion about trying to make an RTL that works without GPS by taking a guess at how fast the vehicle was traveling and how far away home is (i.e. dead reckoning). I'd be overjoyed if someone can get that to work.

Servox3 commented 6 years ago

I experienced the same problem as threadstarter, and I also feel, that my quad does not at all stop at the accelleration given by WPNAV_ACCEL. The picture shows an AUTO mission where a simple circular path (yellow) is repeated until battery failsafe kicks in and switches to RTL (green). Note how far the quad flies along the tangent before turning back against home. Actually I don't remember if it's failsafe or me that switches to RTL, but in any case I have experienced a very long stop before returning home.

auto-rtl

rmackay9 commented 6 years ago

@Servox3, could you try increasing WPNAV_ACCEL? I think this should help..

Servox3 commented 6 years ago

Thanks, I will try that on the next flight. In the meantime, I did some calculations on this particular situation: According to the log, the quad is flying at 15.5 m/s when RTL is invoked. WPNAV_ACCEL is 200 cm/s/s. That should stop the vehicle in 7.75s after traveling 60m. If I measure the stopping distance in my Google Earth view, I actually get pretty close to that (68m), so I rest my case.

lordneeko commented 6 years ago

I think the point is that your braking speed for a RTL event should not be based on WPNAV_ACCEL. That is a value that the quad should obey when everything is going well...not when there is an emergency like battery critical or RC Fail Safe. On those RTL events it should come to as fast of a stop as practical. The reason I suggested transitioning to BRAKE_MODE first is because it has an independent variable BRAKE_MODE_DECEL_RATE to determine how fast to brake.

You wouldn't want to change the flight dynamics of your mission (by changing WPNAV_ACCEL) just to account for a fail safe event.

Servox3 commented 6 years ago

That's a very good point.

rmackay9 commented 6 years ago

Well, it's possible to add a parameter like RTL_ACCEL_MAX defaulting to zero which means use the regular WP_ACCEL_MAX but if non-zero use it for the accel/decel when doing RTL. Each additional parameter adds a small amount of complexity and a delay when downloading parameter to the GCS for all users though so we need to consider if it's really worth it. I suspect that if the vehicle is capable of faster accel/decel the user would often be happy using that faster accel/decel all the time.

Servox3 commented 6 years ago

To expand on my problems with the current implementation:

I often fly a smooth AUTO mission, desiring very smooth movements for movie recording. With a low WP_ACCEL_MAX the vehicle can slowly accellerate to high speed, wich is perfect for shots like this. If RTL then kicks in, the vehicle would sometimes travel far out of the area of interest (and collide with surroundings) before it starts to fly towards home.

Also, between such AUTO missions, I would often have some manual flights, and if I then fly fast towards (but not necessarily close to) some trees, then a failsafe would suddenly take over and crash into the trees because of the slow braking. I realise, that before the manual flight, I could just turn up WP_ACCEL_MAX to solve the problem, but that is very impractical and easy to forget - and sometimes I forget to turn it back low for the next AUTO mission. I also realise, that I could disable battery failsafe alltogether during the manual flight (which is what I usually do), but I really like having battery failsafe able to interrupt these kind of flights and switch to RTL. That makes me relax more during the flight.

So, @rmackay9 , I find your idea very attractive and elegant. I think it would solve the problem.

Servox3 commented 5 years ago

After thinking a bit more, I like @lordneeko idea better, because it would enable the vehicle to stop quickly and then fly home with its normal (possibly smooth) acceleration from WPNAV_ACCEL.

Also, it could be implemented without adding parameters, ie the brakemode rendezvous would only be enabled if BRAKE_MODE_DECEL_RATE > 0.