# Fence avoidance for manually controlled robot

I'm trying to find known techniques for keeping a manually controlled robot within a known polygon fence. More specifically, a pilot controls a robot by issuing desired velocity vectors, and the autopilot adjusts the velocity so that the distance to any boundary is always at least the stopping distance of the robot.

My goal is to implement a system that:

1. Tries to follow the pilot's desired velocity as closely as possible.
2. Is robust to changes in position and desired velocity. At a minimum, I want the velocity to change continuously with respect to the position of the robot and desired velocity of the pilot. Informally, this means that sufficiently small changes in the position or desired velocity of the pilot induce arbitrarily small changes in the velocity.

The second point is particularly important. Suppose that the policy were to find the intersection with the boundary in the direction of the desired velocity and slow down smoothly to that point. The below figure depicts a couple of scenarios in which this would not be continuous. In this figure, the black lines represent the fence boundary, the red dot is the position of the robot, and the blue line is the desired velocity of the pilot. In figure (a), a small perturbation of the position to the left will cause a large increase in allowed velocity because the desired velocity will intersect the far edge instead of the near edge. In figure (b), a small clockwise rotation of the velocity vector will result in a large decrease in allowed velocity because the desired velocity will intersect the near edge instead of the far edge.

I have searched for relevant papers, but most of the papers I've seen have dealt with fully autonomous obstacle avoidance. Moreover, I haven't seen any papers address the robustness/continuity of the system.

## :EDIT:

The robot knows its own location and the location of the boundary at all times. I also have some equations for maximum velocity that allow a smooth ramp-down to a single line boundary (though I'd be interested in seeing a better one). I would like the velocity limits to be continuous in the position and desired velocity of the pilot.

I want to continuously throttle the user's input such that a minimum safe distance between the robot and the boundary is maintained, but see the figure that I added to the question. The hard part (I think) is to make sure that small changes in position (e.g. due to sensor noise) or small changes in desired velocity (e.g. due to pilot noise) don't cause huge changes in what the autopilot allows.

I want continuity because I think it will provide a much nicer experience for the pilot while still enforcing the fence boundary. There is a trade-off with optimally but I think this is worth it. Even though the physical world smoothes any discontinuities in velocity, big changes could still cause large jerk which will be somewhat disturbing to the pilot. The goal is to not have the autopilot introduce large oscillations not intended by the pilot.

This Will be implemented On a physical system that has sensors that provide an estimation of position, and the boundary shape is known and is unchanging. The actual system that I'm targeting is a quadcopter.

• Welcome to Robotics BmoreDaniel. On stack exchange, it is better to edit your answer to add information requested in comments, rather than adding more comments. Comments are for helping to improve questions and answers, and are distracting, so we try to keep them to a minimum. If all of the information needed to answer the question is contained within it, the comments can be tidied up (deleted). I removed the comment chain between you, Mark, and NBCKLY and incorporated your statements into your question. If you all need to chat, please use Robotics Chat.
– Chuck
Commented Jul 11, 2016 at 13:25
• @Chuck thanks. How do I notify someone that I've edited the question in response to a comment? Do I post a comment for that and then delete it? Commented Jul 11, 2016 at 20:29

I think that your problem is rather uncommon, so there may be no solutions ready to use without any modifications. However, you may have a look at "The Dynamic Window Approach to Collision Avoidance" by Dieter Fox, Wolfram Burgard and Sebastian Thrun. This reverses your problem: given current velocity and achievable accelerations, find a path for a robot that avoids all the obstacles.

Or you could just calculate maximum velocity in any given point basing just on a distance to the closes point of the fence. That will of course mean that even going away from the fence you will go slowly, if you are close to the border, but it will surely be continuous.

I'll second mactro's answer, with a few notes:

I'm not sure why you are so concerned with continuity. With the window, you setup an imaginary line on all axes of motion where the distance is basically, "If I issue a stop command right now, where do I come to a stop?" Add a buffer to that stopping distance, then if an object gets between you and your stopping limit, then issue a stop command. A stop command would be zero speed.

So your reference is until the fence gets almost so close that you won't be able to avoid it, in which case you set the speed on that axis to zero. This is where my question on continuity comes in - what difference does it make if the speed reference has a jump from to ? The quadcopter, being a physical system, will not be able to instantaneously change speeds. That is, by being a physical object, the quadcopter will filter that discontinuity for you.

Further, hypothetically speaking, if your boundary isn't the fastest you could come to a stop, then what is it? You sound like you want to lower the maximum speed when operating near the wall, but why? As long as the operator isn't requesting to fly into the wall, why limit the performance? Leave the speed maximum at 100%, and then kill the operator input on that axis when they request to fly into the wall.

As a pre-rebuttal (prebuttal?) to a comment I'd imagine you'll make, a PID controller has some time step involved. Even if you have an instantaneous change in reference speed, that change doesn't register until the next time step. So it may be a large jump, but that large jump is going to look like a step command, which is generally the standard to which PID controllers are tuned.

• I want continuity because I think it will provide a much nicer experience for the pilot while still enforcing the fence boundary. There is a trade-off with optimally but I think this is worth it. Even though the physical world smoothes any discontinuities in velocity, big changes could still cause big accelerations which will be somewhat disturbing to the pilot. For an example, consider figure (a) in my question. Figure (b) is fine as long as you limit velocity only in the direction of the boundary, as you said. Commented Jul 11, 2016 at 20:28
• Actually, the above comment should say that a lack of continuity around reflex interior angles can cause a very large jerk which could be a bad experience for the pilot. I've added the above to the original question. Commented Jul 11, 2016 at 20:38
• @BmoreDaniel - If you don't want to go to peak acceleration limits of the quadcopter, you can set arbitrarily lower acceleration limits. In any event, at speed $v_0$ and acceleration rate $a$, you have still get a known stopping distance. If you're still concerned about jerk then you can use a low-pass filter to "ease" into the ramp-down acceleration. Just know that, the more you try to monkey with the anti-collision deceleration, the more likely you are to have a collision. PS - Also, the pilot isn't actually on the quadrotor, so I don't know what the "bad experience" would be.
– Chuck
Commented Jul 12, 2016 at 12:30
• Stopping before a single edge is not the issue. Consider figure (a) in the original question. Due to sensor noise or noise in the pilot's commanded velocity, the desired velocity vector could alternate between intersecting the course edge and not intersecting the close edge. This means that the velocity allowed by the autopilot would alternate very quickly between high and low, causing the vehicle to try to rock back and forth very quickly. In my opinion, this would be a bad experience for a novice pilot who doesn't realize that he's hit a corner. Commented Jul 12, 2016 at 17:01