5

First of all, as I am new in this very corner of stack exchange please help me by selecting the correct tags!

I'm interested in finding an alorithm, that estimates wether a phone is picked up from the center console by a driver or by his co-driver. For simplicity we can assume that the device is an iPhone an has all the usual sensors like gyro, accelerometer, magnetometer and - maybe most importantly, that we know the direction of travel (in the form of a three dimensional vector expressed in the coordinate system of the phones accelerometer).

Ideally the algorithm would work regardless of the initial orientation of the phone (facing up/down, ...)

My background is in theoretical mathematics - so the actual "estimating" part would not be hard for me to formulate, by I'm having problems wrapping my head around the question wether or not such a motion is even disinguishable...

Any thoughts or hints would be greatly appreciated.

Thanks and all the best, Dennis

Edit: Maybe to elaborate where my thoughts are: One actually has a sense of "to the left" and "to the right" in the frame of the car due to knowing where the car is going toward. That has to be worth something, hasn't it?

Dennis Heinig
  • 59
  • 3
  • 3
    Keeping things from Dennis to spite Transistor doesn't seem 'right', to me... – Jonathan R Swift Jun 11 '21 at 11:55
  • 2
    There's little point to this, since calls and texts can be routed thru Bluetooth to the vehicle's infotainment control system these days. Further, your assumption that the phone is kept in the center console to begin with is flawed. And since you seem to want the phone itself to do all this, how does the phone know it's in a private vehicle as opposed to any other moving item such as a bus or train or bicycle? – Carl Witthoft Jun 11 '21 at 12:12
  • 2
    Motion of accelerometers and gyros will be affected by car acceleration. If the car turns left, the phone may get tricked into thinking that it is pulled right. – AJN Jun 11 '21 at 12:51
  • @Carl Witthoft About the private vehicle vs bus, one could argue that the phone knows it's in a private vehicle exactly _because_ it connects to the infotainment system. Your point about the center console assumption is really good though. – OpticalResonator Jun 11 '21 at 13:58
  • @AJN if the can has accelerometer sensors and the phone has access to that acceleration data, then it should be possible to be able to find when the phone is moving to the right or to the left, or when its facing up or down. – NMech Jun 11 '21 at 15:20
  • What is the resolution - my phone gets my house on the wrong side of the street. also how will the phone know if the car is left or right hand drive? – Solar Mike Jun 11 '21 at 16:56
  • My use case is constrained to left hand drives, we can be 100% sure to be in the appropriate car. The use case is related to violating traffic/driving rules, which actually permit calling via infotainment systems but not "handling" the smartphone itself while driving – Dennis Heinig Jun 11 '21 at 21:10
  • Also: assume we have additional information about the acceleration of the car itself. This might be because we can interface the car's electronics or because we have a second accelerometer attached to the car – Dennis Heinig Jun 11 '21 at 21:12
  • Not that many vehicles have co-drivers. You're generally talking about ladder trucks, trains, aircraft, or the Kennedy crawler. Pretty easy to geolocate them to their respective bailiwicks. – Harper - Reinstate Monica Jun 11 '21 at 22:00

1 Answers1

1

To respond to some of the comments, anytime you are concluding a binary value based on an analog or algorithm there are some big assumptions and it wont be correct 100% of the time. I am not sure of the intended use of this binary left/right driver value, but I think we can safely say that it doesn't launch nuclear weapons and some error is permissible. With proper instruction, the operators are not just dummies and will help the program operate correctly by changing their habits or setting sensitivity thresholds in the program settings.

Assumptions:

  1. Gravity
  2. Car/truck is in motion for a period of time before selection is made
  3. Braking acceleration is greater than acceleration of nearly all vehicles
  4. Center console surface is geometry and or material is such to hold the phone stationary such that it does not shift during car operation/maneuvers.
  5. Phone is placed in center console before selection is
    made
  6. Phone will be spatially moved toward the operator to make a selection.
  7. The operators will generally place the phone back in a similar orientation in the console. Obviously this could be compensated for but ignoring this issue makes things easier starting out.

Algorithm:

  1. Confirm the phone is in the center console. First step is to look for gravity at 9.81m/s^2 oriented in or out of the face of the phone. Phones are flat and generally will not be rested on their sides; either the face or the back. Obviously have to do some work to filter out the noise and car accelerations, but should be pretty easy. Include in operating instructions that the phone must be placed this way. In addition you could add an option to detect a wireless charger that the users could put on the center console. A little bit of install cost but this would give you a deterministic value for this stage if it presented issues.
  2. Determine the orientation of the phone relative to the car. A cars acceleration is weakest in the forward direction because it is limited by the engine power. The vehicles acceleration in the reverse direction (deceleration) is the largest because the braking system is only limited by the friction between the road and the tires. These limits are only rarely reached in normal driving, but drivers will tend to break at greater accelerations than their car can accelerate. Turning also generates accelerations, but has a more constant force over a predictable time period. Also since the drivers will pick up the phone left and right, it is pretty easy to identify left and right, and ignore them. As an additional input to identifying front and back you can look for left turns being a longer duration than right turns. If you have access to the GPS data determining orientation is much easier because you know the forward velocity of the car, when it accelerates, decelerates and turns; you don't just have to infer based on intensities.
  3. Make the binary left/right driver selection. The phone will detect a sustained acceleration in addition to gravity indicating a selection is being made. Note that this conclusion takes half a second so the accelerometer data will need to be archived in an array to run this future calculation. Once the displacement operation has been completed (maybe just time based initially then get fancier with summing the deceleration later on), the program will calculate vector sum the acceleration data during the selection and compare it to the orientation it had concluded from step 2. Based on your application you may want to make a left/right driver selection 100% of the time or you may want to have the program display that it does not know (make the user select) if the degree of certainty is below your desired (or user defined) threshold.

Sounds like a fun project! Let us know how it turns out!

ericnutsch
  • 7,689
  • 1
  • 9
  • 28