0
$\begingroup$

I am trying to write a system that would be able to estimate the velocity of a traveling vehicle (usually a car) using a smartphone. Most smartphones have the next sensors:

  • 1Hz Low-Frequency GPS
  • 10-100Hz Accelerometer
  • 10-100Hz Gyroscope
  • 10-100Hz Magnetometer

I would also impose a limitation, that device must be in either portrait or landscape position, relative to vehicle's direction of travel.

Now, the GPS will tell me speed and position once per second, but I would like to estimate the velocity in time between GPS data comes in, up to 10-100 times per second, for which I would like to use other sensors. The speed should be accurately represented, even if the car is decelerating.

For now, I've implemented Kalman filter which fuses together GPS, accelerometer and gyroscope and estimates the velocity. But the biggest problem becomes the deceleration, as in all usual references I could find, only the absolute velocity from all axes is taken into consideration.

How to approach this problem? Am I even correct in using Kalman? How to get correct deceleration? What if vehicle is cornering?

Thank you for your help!

$\endgroup$
5
  • 1
    $\begingroup$ Kalman sounds right, and if your model can deal with acceleration, it'll deal with deceleration, too. Just a matter of sign, which Kalman doesn't care about. $\endgroup$ – Marcus Müller Mar 29 '20 at 15:05
  • $\begingroup$ "as in all usual references I could find, only the absolute velocity from all axes is taken into consideration" -- What do you mean? Do you mean that the velocity in each of the three directions is forced to range from zero to infinity? I find that hard to believe. $\endgroup$ – TimWescott Mar 29 '20 at 16:01
  • $\begingroup$ Could you give a couple of examples of your "usual references"? $\endgroup$ – TimWescott Mar 29 '20 at 21:34
  • $\begingroup$ Yes, the absolute velocity is always calculated from all three axes using the square root and power equation, as Kalman filter in my current setup provides both x, y and z acceleration, so I am not sure how to exactly get to the velocity of the vehicle. These are the references I used: - researchgate.net/publication/… - geomundus.org/2018/docs/papers/Amrit.pdf $\endgroup$ – Legoless Apr 5 '20 at 9:41
  • $\begingroup$ And a few more I went through: - researchgate.net/publication/… - blog.maddevs.io/… - unoosa.org/pdf/icg/2016/nepal-workshop/2-07.pdf $\endgroup$ – Legoless Apr 5 '20 at 9:43
1
$\begingroup$

How to approach this problem? Am I even correct in using Kalman?

Yes, a Kalman filter (or a derivative) is correct. Rotations are involved, and 3D rotations are highly nonlinear, so you'll pretty much have to use an extended Kalman or an unscented Kalman.

The basic approach is to model the vehicle motion as position, velocity, and angle driven by the IMU output, with the phone position estimate being corrected by the GPS.

You can correct the phone orientation estimate with the magnetometer, but then you need to take into account the various compass offsets.

How to get correct deceleration? What if vehicle is cornering?

That will pretty much fall out of the Kalman solution. As a plus, the phone's orientation with respect to the vehicle will only matter to the extent that you need to know where the vehicle is pointing, and that should be a pretty easy, fixed transform.

$\endgroup$
3
  • $\begingroup$ The desired output would be actually 10Hz IMU corrected GPS location, to fill in the 1Hz blanks. I have a basic method implemented and while during the acceleration it seems to be fairly accurate, the deceleration is never detected correctly and is mostly done by the GPS.. $\endgroup$ – Legoless Apr 5 '20 at 10:21
  • $\begingroup$ Something's off then. A formulation that only cares about acceleration with a direction (i.e., it's agnostic to whether it's cornering or accelerating or decelerating) should be easier to generate than one that differentiates between "putting on the gas" vs. "braking". So I can't say what you're doing wrong. If you start another question and post your algorithm (i.e., equations + explanation: I can't answer for anyone else but I'm not going to plow through your code unless I'm paid to do so) then maybe we can find your issue. $\endgroup$ – TimWescott Apr 5 '20 at 15:35
  • $\begingroup$ Well, you already answered the question, and of course, I don't expect you to plow through my code. The main question was actually if Kalman filter is the correct approach for this, including the acceleration and braking, or rather if that is theoretically possible. Likely there is a problem with my code, if in theory this is still possible. Thanks for the help! $\endgroup$ – Legoless Apr 6 '20 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.