I believe fence or geofence to be one of the most amazing, useful safetly features of this firmware.

Thanks for everyone's hard work to make this possible!

With fence on,

Now, when the the target altitude is reached (or breached) the copter enters into RTL mode.

It used to just STOP and not go any higher.

When did this change? what firmare?

Can there be an option to turn this back on, if not, where exactly is the code where the change occured.

Also, would it be hard to write the code to have the multicopter just "STOP" and not PASS the fence instead of RTL in the horizontal fence breach also?



Views: 1549

Reply to This

Replies to This Discussion


I guess you're talking about copter?  It depends which mode you're in so if it's AltHold, Loiter or PosHold it should stop just below the altitude limit.  That was how it worked in AC3.1.5 and AC3.2 should be the same although I don't remember specifically testing this as part of the AC3.2 release testing.

If you have a log of the event we can be sure.  Otherwise one of the devs (maybe me) will give it a go in the simulator.

Doing it for the horizontal limit is a little more difficult although it's on the to-do list.

Hi Randy thanks for your prompt reply.

Yes, I fly mainly quads.

I am so happy to hear that there are plans in the pipeline to have the option to STOP instead of RTL in the horizontal fence breach. There are some many awesome uses for this feature.

Currently I am using and testing ArduCopter Quad v3.3-dev 09-18-14 10-09 (one of yours)

commit b552479e31b02a0136c0756e3ec04681d9a976a1

It has been flawless in everything that I tested so far. No baro errors, no false desperity warnings, all flight modes very accurate to its intended purpose, precise RTL and smooth auto landings every time, etc.

Except, the fence behavior that activated RTL on altitude breach. I double checked the logs hoping it was a RTL prompted by something else such as radio link lost or low battery but it wasn't.

I will try again with the same exact firmware version on another quad. (I do not have the log for that flight because I do not have that particular quad any more; I should have saved the log)

Then I will also try the fence/altitude on a newer firmware version.

So....this altitude fence feature has not changed by design? Thats good to know....I wonder what happened then?

I will test the above again and report soon.

Thanks again for yours and the rest of the teams time and dedication!!!!!!!!!!!

And yes, this happened while in PosHold

It could be a bug/mistake.  We made a huge number of changes between AC3.1.5 and AC3.2 so it's possible it was missed.  I've raised an issue here so we will check before AC3.3 goes out.

Ok, thanks.

I will report back after a few more tests to make sure the problem is conclusive.

Hello Gregory, so I have confirmed this issue in the simulator.  I have never actually used the fence system before, so I did not know that it would actually stop climbing before hitting the fence on 3.1.  

I can tell you that my testing with 3.2 does show that if you climb in Alt_Hold, it will go through the fence, then switch to RTL, normally stopping about 2-3m above the fence, then flying home and descending.  Note that if you switch modes from RTL to Loiter and resume climbing, it will continue to climb even higher above the fence.  The fence is not "reset" until it drops below the ceiling.  However, there are successive layers of fencing.  It will enter RTL every 20m you climb.  So in my case, I set the fence at 30m. It triggered the fence at 30m, went into RTL and stopped at 32m.  I then switched back to Alt_Hold, and kept climbing.  At ~50m it triggered again.  After about 4-5 layers of fence, it will enter Land instead of RTL.  You can continue to force it to climb by switching modes again.  But this has to be deliberate abuse by the pilot.

It would be useful however, in the case of an extreme and persistent GPS glitch, where the fence virtually moves away from the actual flying field.  The copter would attempt to RTL wherever the GPS glitch is heading.  This would pull the copter away from the flying field.  The pilot could attempt to save this by repeatedly switching to Stabilize mode and flying back towards the landing zone.

So it is confirmed, the code for the fence max altitude feature has changed!

The multicopter enters into RTL mode (as it does in the fence radius limit) instead a simply stopping at the pre programmed ceiling altitude.

To me and I hope to others also who value and understand the safety features of the apm platform this change is very unfortunate.

Besides the failsafe features of RTL on low battery and on loss of radio transmission, the max altitude "stop" feature or we can call it AFL (absolute fence limit) WAS one of the most powerful safety features of the APM which has been working flawlessly since the inception of geofence.

Let suppose we set our max altitude fence ceiling to 400ft so we have a safety net not to enter into manned aircraft airspace which is 500ft. (leaving 100ft cushion)

How the fence "max limit" resulting in a RTL functions is completely different than simply "stopping" the aircract and restricting it from climbing any higher. As we all know, you can easily cancel the RTL by momentarily switching to stabilize mode and back to whatever flight mode you were in. (and practically speaking it is a high probability that the pilot does not want the copter to come back just because it hit the max ceiling but to finish his flight)

Now as a result of canceling the RTL the max ceiling fence gets pushed up about 60 feet. You just lost your intended max ceiling limit. Pass that new limit, RTL and cancel again and now the limit has been pusher even higher.(after you drop to below the new max altitude) You can go several layers deep with this process to end up at almost 700ft when all you wanted for safety is not allow the copter to go over 400ft. This has great practical application of the horizontal (radius) fence limit and I am sure some pratical application in the altitude limit but definitely not an optimum solution to a "max altitude" safety net.

Yes, I know the pilot is in control of this process and should be aware of the limits that were changed but what a nuisance to have to go through that if all the pilot wanted is to finish the flight plan, filming, survalience etc with a max altitude safety limit In place.

As you can see from the above, the practical application for a safety net requirement for max altitude limit can be quite different then for a radius parameter limit.

How beautifully this was working in all the previous firmwares, you could just berry the throttle stick up and the copter would just sit there not not go any higher than intended.

Is anyone with me on this?

Can we please get this feature back?

Or at least the option on altitude fence for "RTL" or....say... "AFL"(absolute fence limit)

If there are no immediate plans to reinstate this fence feature, can one of the developers tell me which was the very last copter firmware to have this original fence feature before it was changed?

(date and time as categorized in adrucopter archive) Thanks

+1 here, very well put...

Rob and I have fixed this in master and it'll go out with AC3.3.  The previous behaviour is there in AC3.1.5 which is available through the mission planner's "previous firmwares" link.

Thanks for the report.

Excellent, thank you Randy, thank you Rob.

I will beta test 3.3 as soon as it is available and report here any results pretaining to the geofence feature.

Gregory, this feature was not removed on purpose, it would be more accurate to say that it was not added back in when most of the code affecting Alt Hold and Loiter was re-written for 3.2.  It just got missed.

As Randy stated, it is now fixed for the 3.3 line of firmware.

I would support patching this into 3.2.1, as it is a bug-fix, is safety-related, and is a very simple and low risk change.  But that decision is up to Randy.

Rob, I understand, thanks for letting me know. I am relieved it was just missed and not an actual change.

I am glad we caught this now.

Yes, that would be great to patch the bug fix into 3.2.1

I hope Randy will approve.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service