1. Limited time only! Sign up for a free 30min personal tutor trial with Chegg Tutors
    Dismiss Notice
Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Help with motion of the car - Displacement

  1. Nov 23, 2012 #1
    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 :)

  2. jcsd
  3. Nov 23, 2012 #2


    User Avatar
    Science Advisor

    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.
  4. Nov 23, 2012 #3
    Thank you for your answer first of all!

    I am using this sonar sensor:

    I believe the readings are continuous data.
    If you could guide me I would be grateful! :)
  5. Nov 23, 2012 #4


    User Avatar
    Science Advisor

    I mean, what sort of readings/sensors do you have that relate to velocity or acceleration of the car.
  6. Nov 23, 2012 #5
    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.
  7. Nov 23, 2012 #6


    User Avatar
    Science Advisor

    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.


    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.


    So when you report the final result, your position is x±sqrt(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.
  8. Nov 23, 2012 #7


    User Avatar
    Science Advisor
    Homework Helper
    Gold Member

    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:
    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.
  9. Nov 23, 2012 #8


    User Avatar
    Science Advisor

    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.
  10. Nov 24, 2012 #9
    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.
  11. Nov 25, 2012 #10
    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.
    Last edited: Nov 25, 2012
  12. Nov 25, 2012 #11
    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.
  13. Nov 25, 2012 #12


    User Avatar
    Science Advisor

    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.
  14. Nov 25, 2012 #13
    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.
  15. Nov 25, 2012 #14


    User Avatar
    Science Advisor
    Gold Member
    2017 Award

    I wonder what your Insurance Company would have to say if you made a claim as a result of 'damage resulting'. :wink:
  16. Nov 26, 2012 #15
    Fear, uncertainly and doubt are the biggest threats to creativity and happiness.
  17. Nov 26, 2012 #16


    User Avatar
    Science Advisor
    Gold Member
    2017 Award

    . . . . and insurance companies . . .
  18. Nov 26, 2012 #17
    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!
  19. Nov 26, 2012 #18


    User Avatar
    Science Advisor
    Gold Member
    2017 Award

    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.
  20. Nov 26, 2012 #19


    User Avatar
    Staff Emeritus
    Science Advisor
    Education Advisor

    This thread is veering into non-physics issues. If it doesn't get back on-topic for the forum it was placed in, it will be closed.

  21. Nov 26, 2012 #20
    The OP is discussing a system that measures parking spaces to determine if the car can fit.

    I was talking about a system that combines this with operating the steering, to get the car into the space. These have existed on certain new cars since at least 2003.
  22. Nov 26, 2012 #21


    User Avatar
    Science Advisor
    Gold Member
    2017 Award

    Interesting. Which cars? Is there a link that you would recommend?
  23. Nov 26, 2012 #22


    User Avatar
    Science Advisor
    Gold Member
    2017 Award

    I looked at a couple of You tube movies. Quite impressive but I don't think it would get into the spaces available in my street. I need castors and side thrusters!
  24. Nov 26, 2012 #23
    toyota yaris 2010 (was the first hit on youtube, but it;s older than that)

    Last edited by a moderator: Sep 25, 2014
  25. Nov 26, 2012 #24
    Vehicle speed is computed by measuring the time between pulses from vehicle speed sensor. This sensor changes it's output based on the presence or absence of a tooth on a rotating gear in the transmission, differential, or wheel bearing. The output may be a square wave in the case of a hall effect sensor or and AC sine wave from and magnet/coil type of sensor. In either case, each cycle = 1 tooth on the gear. It would be fairly easy to measure distance directly from the speed sensor signal because each tooth represents a certain amount of distance traveled (within the margin of error associated with tire wear and inflation). There would be no need for numerical integration and the associated additional error.

    If you are trying to build a 1-of system you may be able to tap the speed sensor circuit and run a signal wire directly to your module. If this is an engineering project for an auto manufacturer you might send a memo to the guys writing the ECM, TCM, or ABS code and ask if they could put raw distance data as measured by a speed sensor on the communications circuit for your program to use.
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook