3
$\begingroup$

I want to measure the acceleration (forward and lateral separately) using an android smartphone device in order to be able to analyse the driving behavior.

My approach would be as follows:

1. Aligning coordinate systems

Calibration (no motion / first motion): While the car is stationary, I would calculate the magnitude of gravity using Sensor.TYPE_GRAVITY and rotate it straight to the z-axis (pointing downwards assuming a flat surface). That way, the pitch and roll angles should be near zero and equal to the angles of the car relativ to the world.

After this, I would start moving straight forward with the car to get a first motion indication using Sensor.TYPE_ACCELEROMETER and rotate this magnitude straight to the x-axis (pointing forward). This way, the yaw angle should be equal to the vehicle's heading relativ to the world.

Update Orientation (while driving): To be able to keep the coordinate systems aligned while driving I am going to use Sensor.TYPE_GRAVITY to maintain the roll and pitch of the system via

enter image description here

enter image description here

where A_x,y,z is the acceleration of gravity.

Usually, the yaw angle would be maintained via Sensor.ROTATION_VECTOR or Sensor.MAGNETIC_FIELD. However, the reason behind not using them is because I am going to use the application also in electrical vehicles. The high amounts of volts and ampere produced by the engine would presumably make the accuracy of those sensor values suffer. Hence, the best alternative that I know (although not optimal) is using the GPS course to maintain the yaw angle.

2. Getting measurements

By applying all aforementioned rotations it should be possible to maintain an alignment between the smartphone's and vehicle's coordinate systems and, hence, giving me the pure forward and lateral acceleration values on the x-axis and y-axis.

Questions:

  • Is this approach applicable or did I miss something crucial?
  • Is there an easier/alternative approach to this?
$\endgroup$
3
  • $\begingroup$ Is there a real-time requirement? Are you using many test subjects? $\endgroup$ – JSycamore Jun 16 '16 at 14:10
  • $\begingroup$ Welcome to Robotics, RDoe. This type of question would be great for Robotics Chat, but for Q&A it's generally regarded as not constructive: "As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. There is a relevant discussion on this topic at our meta site $\endgroup$ – Chuck Jun 16 '16 at 17:23
  • $\begingroup$ Generally speaking I would comment that the EM fields from the vehicle should only affect the magnetometer. That is, you should still be able to use the yaw gyro. Check out the Madgwick filter for more info on gyro and accelerometer sensor fusion. (The algorithms are available for download in Matlab and C/C# at the bottom of the page) $\endgroup$ – Chuck Jun 16 '16 at 17:27
0
$\begingroup$

There are many things to consider.

Assuming that you are developing an app to accomplish this, you should invest some time in filtering. Depending on the vehicle and the phone's position in the vehicle, you would expect to encounter sensor noise due to vibration induced by the road surface or possibly the engine. Among many filtering techniques, Kalman filtering is often used with Accelerometer/Gyroscopes to fuse the raw sensor measurements and implementation is straight forward. To understand Kalman filtering (and possibly pick up a few other techniques), I suggest Sebastian Thrun's textbook Probabilistic Robotics, which covers the topic quite well.

While we are considering things you may have left out, assuming you are attempting to characterize driving behaviour of many test subjects, you should count on the subjects not using your app as intended. If a subject uses the phone while driving, your measurements will obviously be affected. Consider implementing a "quiet mode" while testing to discourage using the phone. Furthermore, you cannot assume that the phone will start in any one place.

Of the concerns above and the many like them, rather than characterizing driver behaviour in real-time using the phone, you could instead have the phone log raw sensor data, including GPS location and raw accelerometer/gyroscope data--you could then use statistical techniques (again described in Thrun's text) to determine the transformation between the coordinates of the phone and the coordinates of the vehicle to finally determine the pose of the vehicle and characterize driving behaviour. This approach has the benefit of being easier to deploy and being robust in the event that your characterization procedures change in the future.

$\endgroup$

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