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?

Thanks

Gregory

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

      • Yeeeeeeeeeeees, that is awsome. I just did a cartwheel......mentally.

        I see some many safety (and "peace of mind" fun) applications for the circular limits.

        Great job guys, thanks for all the dedication and hard work!!!!!!

      • So when the uav get's to the height of the fence or the perimeter of the fence it will just sit there until the operator pulls it back?

        That would be my perfect setup but an option (individually for height and perimeter) to make it RTL/Land/Sit there instead would probably be the ultimate if possible.

        • Whever you talk about the side fencing you have to consider, "what happens if the fence moves due to a gps glitch?"  capturing the drone inside is not very helpful in that instance

          • Ben, I can answer "what happens if the fence moves due to a gps glitch?": the copter switches to RTL and moves back to where it *thinks* is the home position. I had this issue a few days ago and it took me a while to understand what happened - apart from almost 40 min. to rescue it from the top of a tree. :)

            I started flying with geofence on and after a few seconds, with the copter just a few meters away from me - horizontally - a GPS glitch indicated that the copter had moved hundreds of meters away, triggering the RTL. The quad accelerated wildly trying to RTL (actually moving away from the home position) and crashed over a tree before I could do anything.

            Geofence is a great, great feature but, Rob and Randy, if you allow me to make a suggestion, some additional checks could be implemented to avoid triggering RTL in the case of a GPS glitch. I don't know the complexity of doing that but there should be a check for light-speed moves like the one indicated on my flight log. The copter couldn't have moved hundreds of meters in a fraction of second so we could check "if the previous position is unrealistically far from the current position then it is a GPS glitch, not fence breach".

            I'm not using geo fence anymore because with this behavior I consider it more of a risk than a benefit. Fortunately the quad was high enough not to hit someone but it could be different. I was on the path and would be hit if not for the altitude.

            Please take my comment as an improvement suggestion, not as just a criticism. As I said before, the geofence is an amazing feature but it needs to be safe.

            Thanks!

            Arnie

    • Yes understand that.

      Thank you

  • +1 here, very well put...

  • 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

      • 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.

This reply was deleted.

Activity