Register to reply

Help with motion of the car - Displacement

by NeoXx
Tags: displacement, motion
Share this thread:
NeoXx
#1
Nov23-12, 12:25 PM
P: 22
Hi all,

I am writing a code for the Ultra Sonic Sensor for the car which will show if there is enough parking space for the car to park parallel.

Basically, the UltraSonicSensor starts recording values when the distance from the side of the car to some object is greater than the car width.
It stops recording values when its the opposite, that is when the distance from the side of the car to some object is smaller than the car width.

However, I am unsure how to find out the length of the car space, which is the same as the displacement of the car from the moment the sensor has started recording, and to the moment it has stopped.

I thought of using the equation v^2 = u^2 + 2as
As the car velocity and acceleration change all the time, would it be okay to use this equation?

Thus, the moment the sensor starts recording, it should save the initial velocity at that exact time, right?
And then it should record acceleration and velocity of the car many times until the sensor stops recording, and then calculate the average of both right? And those two averages should enter the equation alongside with initial velocity.

I would be grateful if someone could point out if I'm thinking the right way or I'm completely wrong :)

Thanks!
Phys.Org News Partner Physics news on Phys.org
'Comb on a chip' powers new atomic clock design
Quantum leap in lasers brightens future for quantum computing
Enhanced NIST instrument enables high-speed chemical imaging of tissues
K^2
#2
Nov23-12, 06:52 PM
Sci Advisor
P: 2,470
You are trying to solve a localization and mapping problem without really understanding motion. I can walk you through this simple case, but if you are doing this as an exercise, you really ought to learn a few things first.

First of all, what do you have access to? Do you have continuous readings of velocity? Because [itex]\bar{v} = d/t[/itex]. So if you have an estimate on average velocity over some time span t, you have estimate on distance traveled. If you have access to accelerometer data, you can improve the quality of the estimate, but it's not trivial. In either case, you need to be able to gauge the error as well. I mean, say, you need a minimum of 4 meters to park in. You read 3 meters 80cm. Can you park there? Well, that depends. Did you read 3m 80cm 10cm? Or 3m 80cm 50cm? You can park if it's the former with 97% accuracy. It's a 50/50 shot with the second one. Your system should either reject the second result, or at least, provide some sort of a warning. That's why every good localization technique has error estimates. Fortunately, you have about as simple the case as you can imagine for localization, and I can probably explain it all to you, or at least, give you formulas to use. But I need to know which sensors/readings you have access to.
NeoXx
#3
Nov23-12, 07:17 PM
P: 22
Thank you for your answer first of all!

I am using this sonar sensor:
http://www.maxbotix.com/documents/MB1020_Datasheet.pdf

I believe the readings are continuous data.
If you could guide me I would be grateful! :)

K^2
#4
Nov23-12, 07:21 PM
Sci Advisor
P: 2,470
Help with motion of the car - Displacement

I mean, what sort of readings/sensors do you have that relate to velocity or acceleration of the car.
NeoXx
#5
Nov23-12, 07:41 PM
P: 22
There is a mbed processor from ARM(it's basically a small CPU) that will be connected to the car (Don't know how exactly) in order to show at which speed the car is going.

I can't tell you more because I don't know as I was told to write a C++ programming code for the mbed processor based on equations I need to use in order to implement it to the sensor, and then the sensor could calculate whether there is enough parking space.

I don't have problems with writing a computer code, but with using necessary equations in order to find out the space of the parking slot.
K^2
#6
Nov23-12, 08:33 PM
Sci Advisor
P: 2,470
Just as a note, I'm kind of assuming in all of this that you'll be using a consistent set of units. Like meters for position and meters/second for velocity. Or feet for position and feet/second for velocity. If you are going with something like feet and mph for units, you'll naturally need to do some conversions in between, but it shouldn't be hard to figure out.

If all you have is the speed of the car, it's very straight forward. On each tick, you want to have current velocity reading, and one from previous tick. On the first tick the range sensor tells you that there is space to the side of the car, you initialize your position x=0. On each consequent tick while range sensor still says there is space, you want to increment position by the average of the current and previous velocity times the time interval between ticks. In other words, your position update looks like this.

x+=0.5*(v1+v2)*dt;

Where dt is time interval between ticks and v1 and v2 are current tick's and previous tick's velocities.

This will keep track of your estimate of distance traveled. Basically what you are doing here is integrative velocity over time using trapezoid rule. Trapezoid rule requires average of two measurements, which is achieved here by averaging velocities between two ticks. This is fairly accurate under assumption that acceleration is fairly constant from one tick to the next.

However, even under perfect integration, you have accumulated uncertainty due to uncertainty in velocity. You'll have several sources. First, the velocity measurement will most likely be given to something like 0.1 mph. (Or whatever unit.) So you immediately have a 0.05 mph error on each measurement. Or whatever it actually happens to be. Furthermore, reading will probably come from speedometer. If so, it is affected by tire diameter which is in turn dependent on air pressure. The typical tolerance there is 2-3%. So assume 3% error on top of the above.

So besides keeping track of x, which is your position estimate, you really ought to be tracking dx2, which will be square of your error. You initialize it to 0 at the same time you initialize x to zero. Then, for each step, you want an estimate of velocity error.

dv = 0.03*0.5*(v1+v2) + v_error;

v_error is whatever precision the reading is given to you with. You'll need to find out what it is, and convert it to units used. Even if they tell you there is no error, I'd assume at least a 0.01 m/s error. You should also check on that 0.03, but I'm pretty sure 3% is a good estimate for error due to wheels/tires.

The actual error in position from single measurement is dv*dt. Which would accumulate really fast, but thankfully, it's squares of errors that add for this kind of measurement. So you update your square of error in position like so.

dx2+=dv*dv*dt*dt;

So when you report the final result, your position is xsqrt(dx2). Keep in mind that this is a statistical error. Think of it as normal distribution centered on x with standard deviation of sqrt(dx2). Whether you use this error directly to accept/reject space as acceptable or use it for something else is up to you and whoever you are writing this code for.


Now, there are several ways to significantly improve on that depending on what you have in terms of hardware. First of all, adding a second position sensor can make a huge difference. For example, one on front bumper and one on rear bumper. It would let you verify your estimates against measured positions of obstacles. That can cut your error more than in half easily.

Second thing that can be done is if you have acceleration data. Not one derived from velocity, but independently acquired from accelerometers. If that's available, you can write a very simple implementation of 2D Kalman Filter. It basically does the above, but for velocity/acceleration rather than position/velocity. It also allows you to use both the updates of velocity and acceleration. The output of KF will be a velocity estimate with improved error estimate.

But both of these are mostly to allow you to reduce the uncertainty. The basic principles of algorithm described should be sufficient if you don't have any additional inputs. And in either case, it should be what you start with to make sure everything is working correctly.
haruspex
#7
Nov23-12, 08:35 PM
Homework
Sci Advisor
HW Helper
Thanks ∞
P: 9,644
As K^2 says, to answer the question of accuracy we need to know what data you get regarding the car's movements:
- speed and acceleration, or just speed?
- any directional info, or just scalars?
- how accurate is each data item?
- how frequently can you sample?
- how accurate is the sampling frequency?
I assume you get distance info from the sonar, but it will be hard to know to interpret this. If the proximity to the obstacles is different at the end of the parking space from what it was at the beginning, is it because the car is at an angle to the space or because the obstacles are different distances from the kerb?
Anyway, let's assume for now you just get speed, and we travel in a straight line parallel to the kerb, and we have a set of speeds v0, v1... vn at times t0, t1,.. tn. A first cut would be to compute the average speed over each time interval and sum:
Ʃ(vi+vi+1)(ti+1-ti)/2
If that's not accurate enough, because the speed varies too much, could consider fitting a smooth curve to the datapoints. There are standard methods for this, but you could perhaps do even better by putting in realistic constraints, such as an upper limit on (positive) acceleration.
But I would start with something fairly simple and model it to see how well it works. Either use real car data or make up a randomised simulation.
K^2
#8
Nov23-12, 11:38 PM
Sci Advisor
P: 2,470
The algorithm above accounts for all of this continuously and gives you an estimate for the error. But yes, it assumes straight-line driving, which isn't a bad assumption when looking for a spot.

The noise in velocity data will be attenuated significantly by integration. If it's still too strong, you can just use a Kalman Filter for the whole thing. It will take care of everything. But these things require some finesse to tune.
NeoXx
#9
Nov24-12, 09:05 AM
P: 22
Thank you very much for your help!

I will most probably use the algorithm, but I will take a look at the Kalman Filter as well.

Thanks again.
d3mm
#10
Nov25-12, 09:29 AM
P: 139
Why are you using the *width* of the car not the length?

Unrelated: I tried to get autoparking computers fitted to my car, but no such luck. No-one makes them. However they mostly use cameras not ultrasound. However I am talking about systems that steer the vehicle for the driver, not a system that measures the parking space.
NeoXx
#11
Nov25-12, 09:36 AM
P: 22
I use both the width and the length.
I need to use the width in order for the sensor to know whether its a parking space by comparing that space and the width of the car.
K^2
#12
Nov25-12, 11:37 AM
Sci Advisor
P: 2,470
Quote Quote by d3mm View Post
Unrelated: I tried to get autoparking computers fitted to my car, but no such luck. No-one makes them. However they mostly use cameras not ultrasound. However I am talking about systems that steer the vehicle for the driver, not a system that measures the parking space.
It's very vehicle-specific. While it might be possible to write generic software, all of the hardware would have to be customized for your car either way. You can get that sort of stuff custom built. I'd happily take something like this on as a project. But it would be ridiculously expensive this way. Well north of $10k. Might actually cost more than your car is worth. So there is not a lot of interest in that sort of aftermarket upgrade.
d3mm
#13
Nov25-12, 01:01 PM
P: 139
K^2, that plus liability and regulatory issues is pretty much what the aftermarket specialists I spoke to told me.

Turns out it's easier to get a new car with a factory fit system but that doesn't help if you need to use a particular non-supported vehicle for performance or sentimental reasons.
sophiecentaur
#14
Nov25-12, 05:47 PM
Sci Advisor
PF Gold
sophiecentaur's Avatar
P: 11,882
Quote Quote by d3mm View Post
Why are you using the *width* of the car not the length?

Unrelated: I tried to get autoparking computers fitted to my car, but no such luck. No-one makes them. However they mostly use cameras not ultrasound. However I am talking about systems that steer the vehicle for the driver, not a system that measures the parking space.
I wonder what your Insurance Company would have to say if you made a claim as a result of 'damage resulting'.
d3mm
#15
Nov26-12, 04:37 AM
P: 139
Fear, uncertainly and doubt are the biggest threats to creativity and happiness.
sophiecentaur
#16
Nov26-12, 04:41 AM
Sci Advisor
PF Gold
sophiecentaur's Avatar
P: 11,882
Quote Quote by d3mm View Post
Fear, uncertainly and doubt are the biggest threats to creativity and happiness.
. . . . and insurance companies . . .
d3mm
#17
Nov26-12, 02:57 PM
P: 139
A lot of cars have this factory fit, insurance companies cover it. Besides you can (legally) self-insure if you really need to, and the system doesn't operate the throttle, only the steering :-) Stop worrying too much!
sophiecentaur
#18
Nov26-12, 04:09 PM
Sci Advisor
PF Gold
sophiecentaur's Avatar
P: 11,882
We may be talking about different things. There are many parking aids that tell you when you are too near the car behind. I thought the suggestion here was for far cleverer functions.


Register to reply

Related Discussions
Motion Along a Line and displacement Calculus & Beyond Homework 0
Displacement of motion... Introductory Physics Homework 1
Motion and displacement Introductory Physics Homework 1
Projectile Motion, with only Displacement and Angle Known. Introductory Physics Homework 1
1D Motion Displacement, Velocity Advanced Physics Homework 2