MoTeC Global Forum

I am calculating lean angle using the arctan of the lateral accelration calculated from GPS heading and speed information. As part of the process, I need to do some low-pass filtering. Does it make sense to do an initial filter of the GPS heading which is used in subsequent calculations or just do a filter of the final output of the calculations.

Fast_Moto wrote:I am calculating lean angle using the arctan of the lateral accelration calculated from GPS heading and speed information. As part of the process, I need to do some low-pass filtering. Does it make sense to do an initial filter of the GPS heading which is used in subsequent calculations or just do a filter of the final output of the calculations.

If anything do all the math fast, and then select the median value by blocking some larger number like 5, so every 1/4 second you get an answer out - I doubt you will be happy with that because it is not possible to know the attitude with any certainty using just GPS... and especially so when you are hanging off the inside of the bike.
http://www.motec.com.au/forum/viewtopic.php?f=14&t=546&p=7578#p7578

The gyro/accelerometer IMU I am using does a pretty decent job (e-Lean) using a Kalman filter helps keep the error acumulation lower. But, as nobody has used this sensor with a Motec system, I am still identifying certain issues.

As part of my testing, I am using the GPS based lateral acceleration as a check (not as the primary input). However, using the derivative of the GPS heading as the rate of angular rotation causes the a big spike when the heading changes from 0 to 360. That is something that I am having difficulty filtering without overfiltering the rest.

Do you have any suggestions for that?

Fast_Moto wrote:The gyro/accelerometer IMU I am using does a pretty decent job (e-Lean) using a Kalman filter helps keep the error acumulation lower. But, as nobody has used this sensor with a Motec system, I am still identifying certain issues.

As part of my testing, I am using the GPS based lateral acceleration as a check (not as the primary input). However, using the derivative of the GPS heading as the rate of angular rotation causes the a big spike when the heading changes from 0 to 360. That is something that I am having difficulty filtering without overfiltering the rest.

Do you have any suggestions for that?

Maybe do a .dll and do the math in there.
Or a math channel and output the GPS in the same range -180 to 180, or 0 to 360, as the IMU and then adding the general bias (Magnetic north to true north angle) to get the data closer.
If you difference the 2 readings and they are more than 90 apart, then take away 180 from one of them... Do that first, then divide by the time increment if you need derivative.

The IMU will be leaning on the bike's coordinate frame. The GPS will be in the Earth's local frame (aka Topographic). If you are in the same frame of reference it should be easier - and you are when the bike is vertical, but when the bike leans then your reference frames become severely misaligned, so pitch looks like yaw.
The IMU should be good with that for roll pitch and yaw (RPY), but the accelerations and always in the bike's frame, of reference (FOR) and not topo .(The Rates are the same as the accelerations being in the bike's FOR)

Fast_Moto,

As Holmz correctly said, you'll need to set up some logic for determining outputs in either an external plugin or in i2 Maths. In Maths, the simplest "catch-all" is that of the CHOOSE() function. You can set your derivative to output a static value or the current value depending on whether or not the derivative has exceeded some threshold.

As I only know of one customer using this device, I'm guessing I have already worked on this with you a little. E-mail if you need help with specifics.

PaulGM wrote:Fast_Moto,

...

As I only know of one customer using this device, I'm guessing I have already worked on this with you a little. E-mail if you need help with specifics.

It would be good to see the outcome posted here...

Fast_Moto wrote:I am calculating lean angle using the arctan of the lateral accelration calculated from GPS heading and speed information. As part of the process, I need to do some low-pass filtering. Does it make sense to do an initial filter of the GPS heading which is used in subsequent calculations or just do a filter of the final output of the calculations.

Are you on a banked track?
Are you on a track with altitude changes?

If the answer is no and no, then compute the lateral acceleration as ((lateral^2 = vert^2)^0.2 - 1G).
Then your lean angle is your lateral acceleration with your tangent function applied knowing the vertical acceleration (1G).
Your lean angle might be less if the rider is hanging off the bars.

Usually these devices get confused on long steady turns - I would look there for errors.

The other away to do it is to use the devices roll (pitch and yaw), and the 3 accelerations and propagate the position forward in time. You will not have a lot of error over a short time once you have a good bias value. MATLAB helps with this.

In this example:

I propagated the speed starting at a known ~160 kph (100mph) to find coefficients for drag... (Took about 90 seconds to coast down to a slow speed)
Once I computed the coefficients; then the graph shows the GPS speed in green and modeled speed in red on the top graph.
I took into account the rises and dips in the road, which were not much - but really showed up as needed once the coefficients got close.

One the lower graph is the HP required to do that speed.


That was a totally different problem to yours - but the same principles can apply.

For your case - you could start with the GPS position, speed and heading.
Then propagate the motorcycle forward in time based upon the initial GPS position,speed/heading using just the RPY (Roll, pitch, yaw) and the 3 accelerometers.
You will probably have to take out some bias...
If you plot that against the true position and it matches up, then you have success!
Otherwise you will see regions where the device works great and regions where it is not so good.

I found it easiest to export the data as .cvs and work it off-line outside of i2, where I know how to do the math better/easier.