Hmm, can’t quite make out the details of the top image. But I’ve come across this kind of thing before. My advice would be to print out distance and force for each time step and look at what happens as they reach zero. Clearly there’s too much force being applied causing an overshoot.
Usually its going to be caused either by incorrect maths (lets say something like floating point rounding error, or a slight miscalculation), or temporal aliasing (you’re computing a force vector at a point in time, but in reality to actually steer to a stop you would have to compute that force at EVERY timestep (i.e. continuously, rather than in discreet steps like you get in games). Ideally you’d see both values for force and distance converge to zero with both hitting zero at exactly the same time. I’ve not looked at Reynolds original paper for quite some time (steering really doesn’t tend to work for most things in games) but you could have a look at the code for OpenSteer and see his implementation of arrival, see if he has any fixes in place for this issue.
The easy fix would be to have an area around the arrival position that is considered arrived. It looks as far as I can make out like you already have that in place. Having the ability to be “near enough” is actually a good thing in general, because game environments tend to be pretty noisy. You might also just clamp to the target position if you get below a small threshold away from it, resetting the velocity to zero.
Let me know how you get on. Maybe post the final distance/force values (and speed as well) as they might hold a clue where things are going wrong.
Phil.