Any way to predict when to stop a moving ball in order to get it to x?

  • Thread starter Thread starter crewxp
  • Start date Start date
  • Tags Tags
    Ball
AI Thread Summary
To predict when to stop a moving Sphero ball at a specific position, one can use the known velocity and an estimated acceleration. The stopping distance can be calculated using the formula v²/(2a), where v is the current velocity and a is the estimated acceleration. If the distance to the target position is less than this stopping distance, the ball should be commanded to stop; otherwise, it should continue moving. Implementing a system that alternates between stopping and moving can help manage inertia and prevent overshooting the target. A small error threshold can also be introduced to improve the responsiveness of the stopping mechanism.
crewxp
Messages
2
Reaction score
0
I am working on a project for my kid. I have a question.

Question: Is there a way to predict when to stop a moving ball in order for it to finally stop rolling at a specific position?

Data: I know the balls x and y position, and the velocityX and velocityY float values. I think it has an accelerometer as well, but I haven't experimented with it. It has a x,y, and z value.

Situation: I am programming a Sphero (wireless moving ball), and I know my starting location (0,0), and ending location eg:(0,300cm). Once it stops at the ending location, it needs to travel back to 150cm, (the middle between the two locations). But every time I find out the position is 150cm and send stop, it rolls past where I want it to go while its stopping. (Stopping Distance)

I can't hard program it to stop a random SET distance (through trial and error) before the middle because its velocity won't always be the same. Sometimes it rolls on rough carpets and sometimes on smooth tile floors.
 
Last edited:
Physics news on Phys.org
Sure. First, you can ignore the fact that it's rolling. Rolling inertia will just work as if the ball has extra mass. So you have a known x, y, Vx, and Vy, and you are trying to get the ball to come to a stop at specific position, but you don't know exactly what the acceleration is going to be. Let's talk just about x for the moment, because it's easy to generalize, and I'll just assume you want it to stop at x = 0. Naturally, you can shift the position to wherever.

The simplest way to do this is to make an assumption about worst case acceleration. This is gives you the longest distance it's going to stop on the surface. Let's say you found (or even just guessed) the acceleration to be a. Guessing a value too high can result in errors, so start low and see if you can increase it later.

Now you have the ball approaching zero from some distance x at velocity v. If you were to start stopping at acceleration a, you can stop in distance v²/(2a). So that's going to be your test. If x < v²/(2a), you should be trying to stop. But you keep making this test. If velocity drops too fast, and new x > v²/(2a), keep the ball rolling towards the target position.

Even if all you can do is alternate between "stopped" and "maximum speed", because the ball has inertia, you will get smooth movement with the ball decelerating at the set rate a before reaching the target. The fact that the ball can decelerate at the rate of at least a on any surface means you won't have problems with the ball rolling past the target, and because you alternate between moving and stopped modes, the net acceleration will not exceed a even on surfaces where the ball can stop faster.

There are a number of ways to go fancier, but I'm guessing you are looking for something pretty basic.
 
thanks a lot for this! Still confused lol. I thought I would have to somehow use the sphero's internal location to learn when to stop. But you said I don't need this? Only the velocity, acceleration, and x position to stop at?

I sent you a pm! (Confused!)

Here is what I was thinking:
if ((player2positioninY/2)<velocity^2/2a)
{
send stop to sphero
}

But I'm confused on the part where you say if velocity drops too fast.

On my sphero, I can get: VelocityX, VelocityY, PositionX, PositionY, Accel XYZ, Gyro XYZ)
 
The problem is that a is just an estimate. If actual acceleration is going to be greater than a, stopping the servo too early will result in the Sphero undershooting the target.

Ok, so let's say we have TargetY being location where we want to stop. In that case, you want to have two independent checks.

if(|TargetY - PositionY| < VelocityY^2 / (2*a))
{
send "servo-off"
}
if(|TargetY-PositionY| > VelocityY^2 / (2*a))
{
send "servo-on"
}

Here, I'm assuming that "servo-on" will have the Sphero rolling towards TargetY. I'm sure you can figure that bit out and generalize this whole thing to movement in 2D.

One more note, the above code will be switching servo on and off rather rapidly as it approaches target. If this causes any trouble, you can add a small threshold. Like, replace second if() with if(|TargetY-PositionY|-err > VelocityY^2 / (2*a)). Here, err is a small error you allow in the position. This will allow for a bit longer times between servo switching on and off. In ideal world this would reduce precision, but in real world a small allowance for error might actually improve it.
 
Thread 'Is 'Velocity of Transport' a Recognized Term in English Mechanics Literature?'
Here are two fragments from Banach's monograph in Mechanics I have never seen the term <<velocity of transport>> in English texts. Actually I have never seen this term being named somehow in English. This term has a name in Russian books. I looked through the original Banach's text in Polish and there is a Polish name for this term. It is a little bit surprising that the Polish name differs from the Russian one and also differs from this English translation. My question is: Is there...
Hi there, im studying nanoscience at the university in Basel. Today I looked at the topic of intertial and non-inertial reference frames and the existence of fictitious forces. I understand that you call forces real in physics if they appear in interplay. Meaning that a force is real when there is the "actio" partner to the "reactio" partner. If this condition is not satisfied the force is not real. I also understand that if you specifically look at non-inertial reference frames you can...
Back
Top