Slip Sensor?

[Adam Farabaugh]

Is anyone measuring body slip or front slip angles or similar on track?

I'm wondering what people have had success with and what just doesn't work.

Current ideas:
- Optical flow sensor such as this meant for aerial robotics: https://store.3drobotics.com/products/px4flow
Has anyone tried a sensor like this? No idea if it works well close to the ground / on relatively homogeneous surfaces

- Deriving it from GPS data at front and rear axles
Is this too noisy? We have 50 Hz GPS units coming in but have no characterization of accuracy/noise. Differential measurements should be better than absolute but not sure by how much

[BillCobb]

And just what would you do with sideslip sensor readings taken on a track ? The "value per accuracy" coefficient is kinda high... But borrowing one is always a nice perk. Best is rear axle slip angle in order to directly measure rear cornering compliance.

[Z]

Adam,

Hmmm ... need minimum-cost Slip-Sensor? Think, dammit Z, think...!

Howabout...

1. Take one foot length of welding-wire. Bend in middle to form "L" shape.

2. Push vertical section of wire through holes in floor and/or body work, but loosely enough that it pivots freely about this vertical axis.

3. Let trailing-edge of horizontal wire drag on ground, like an upside-down weather-vane...

But how to log the data???

Got it!

4. Mount Go-Pro camera where it can see the angle, wrt body, of trailing bit of wire. Watch video...

5. Much, much, later, add a "rotary potentiometer" (eg. TPS) to top of vertical bit of wire, and log angle with fancy-box-of-electronic-junk. Even later, maybe "productionise" it all, by making a more robust vertical-axis+bearings, fitting a little wheel to end of trailing-arm, giving said trailing-arm+wheel some real suspension (eg. via rubber bands), etc.

Z

[CWA]

Adam,

Sorry I can't help with your actual slip angle sensor query.

But I was wondering if you could add a bit more info about the GPS h/s s/w you are using? 50Hz with coordinate accuracy great enough for you to begin to consider differences in data between front and rear axle signals sounds like pretty capable stuff. The most experience I have with logging GPS is from an Arduino breakout board; 10Hz at best with standard maritime ~5m displacement accuracy.

Regards, Chris

[Tim.Wright]

Slip angles can be measured using whats basically an elaborate caster wheel bolted to the back of the chassis. The vertical pivot angle is the slip angle and you can get a clean speed signal from the caster wheel speed.

I can guarantee its will be more accurate than using pure GPS which is a terribly noisy signal - especially at fsae speeds. To make it anywhere near useful for slip angle measurements it needs to be "cleaned" by combining it with accel and rate gyro data which is how commercial GPS slip sensors work.

Then another possibility is to calculate the slip angle velocity (yawrate - latacc/vel) and for short maneuvers like a steering wheel step or constant freq sine test you can integrate that signal. If you start and end your test with a few seconds of straight line driving you can use that to cancel out the integrator wind up.

Obviously any of these methods will need some kind of error analysis - they aren't perfect but optical sensors are still expensive so sometimes you just have to make do with what you've got.

[murpia]

If you have a GoPro, why not just video the track surface and post process using an optical flow algorithm?

Or try one of these: http://www.unmannedtechshop.co.uk/optical-flow-sensor-board/

Regards, Ian

[Swiftus]

If you have a GoPro, why not just video the track surface and post process using an optical flow algorithm?

Or try one of these: http://www.unmannedtechshop.co.uk/optical-flow-sensor-board/

Regards, Ian

A problem with this is digital sensors distort the image with a 'rolling shutter' effect.

[Adam Farabaugh]

GPS module we will be using:
http://www.skytraq.com.tw/products/Venus838FLPx_PB_v1.pdf
Doing state estimation using GPS/IMUs/optical flow camera is right up our alley. Not super high-priority for building a fast car but I would love to put together a sensor suite that beats everything on the market for orders of magnitude less dollars. I have fantasies of funding our team by commercializing our great custom electronics...

Optical flow is the whole point of the original link I posted. Doing optical flow with gopro footage in real time is not going to be easily possible on standard embedded hardware, could implement something custom on an FPGA to track features and do vectorized math but not worth the effort. In my experience to make optical flow work well with low effort you have to throw fast hardware at it. I've done EKF vision-based control of aerial vehicles and it was actually easier to radio the image data to a base-station and do the processing and control at the base station than to do it onboard. I'm going to look into the cheaper sensor Murpia posted.

A good hall effect rotary sensor is already $50 so $150 for a non-contact sensor looks attractive to me. To me FSAE is about sometimes doing cool/badass things with other peoples' money just because you can, this seems cool to me!


What do I want to do with this? Ground our vehicle dynamics models with ground-truth data.

[CWA]

Thanks for the GPS h/w link Adam. Interesting, but with an accuracy of 2.5m, I'm still curious as to how useful it's data really be to you w.r.t contributing to slip angle sensing? I must be honest, so far the only use I've found for GPS data is to confirm which sector of the track the car is on as a reference for all the other data channels logged.

I thought perhaps you'd found merit in fitting a position sensor to each axle by looking into something like Real Time Kinematics and the use of a base station to improve position-sensing accuracy drastically above what most normal GPS services seem to offer

[Adam Farabaugh]

We haven't actually gotten those units yet so not sure what real life accuracy will be. Should have some follow-up in a few weeks.

I think a lot of the error in GPS measurement is due to atmostpheric aberration of the signals (or other similar position-dependent effects). So two receivers close to each other experience almost the same inaccuracies, so a differential position vector between them (delta_x = x_a - x_b) will be much more accurate than either of their absolute position vectors.

This is similar to RTK but RTK w/ base station typically uses a surveyed location to allow you to reference the differential position vector back to a good absolute reference.

For the same reason velocity signals from GPS have much higher quality than position signals (v_a = (x_a[1]-x_a[0])/delta_t). It's possible to use differential velocity measurements as another input to a state estimation filter like a KF or an EKF, just some more effort required.

[BillCobb]

Keep in mind that the 'sideslip' you want to follow is the relationship between two VELOCITIES. So who would like to demonstrate the lateral velocity and forward velocity tangent ? Because GPS is low frequency (~10 Hz its not real useful for transients but WTF ? Give it a try.Best accuracy is from GPS and GLONASS (55 satellites) plus cell towers. Just about all chipsets can do both now (smartphones).

Bombs away !

[MileyCyrus]

I'm pretty sure SAE-A is pretty close to publishing an article on developing a slip angle sensor cheaply using optical flow in one of their technical journals. ;)

As mentioned earlier, you need to be able to deal with the data coming from the sensor pretty fast, especially as the chip in that link has an 8 bit register for each the x and y motion data, that gets updated with each frame and is only reset after being read, meaning that it can overflow pretty quickly. Another issue with these sensors is that they typically have a deadband around each axis, to varying degrees, which works fine when you want to use your mouse to draw a nice straight line, less so when trying to measure relatively small angles accurately.

[Goost]

This is great it has been too long since we had an interesting VD thread!

The Venus838 is a good choice Adam, as far as I can tell that’s the smoking hot product for true 50Hz position in a consumer grade chip. Make sure your processor can keep up with the data rates - that’s why most consumer GPS modules advertise 20Hz but can only do 10 (because the modules don’t allow for any communication delay between NEMA messages.

Actually, GPS velocity is more accurate than position because it uses Doppler shift not Pseudoranges.
Here is a breakdown of the position errors in GPS (from Misra)
• SV (satellite vehicle) clock error: 2m RMS (DGPS fixes this)
• SV ephemeris: 2m RMS (DGPS reduces this to ~0.1m)
• Ionosphere delay: 2-10m RMS (DGPS reduces this to ~0.2m)
• Troposphere delay: ~2.5 m RMS (DGPS mostly fixes this if receivers are nearby)
• Multipath: large range, ideal ~1m (DGPS fixes this)
• Receiver noise: 0.25-0.5 m (DGPS CANNOT FIX THIS)

So you are correct you could use DGPS to help but you can Never get better than ~0.5m RMS accuracy without atomic clocks - that’s ~17 deg on a 1.6 m wheelbase! I believe you must have a gyroscope anyway or this scheme doesn’t work! We could use two antennas on a single GPS receiver, but I expect that’s a programming nightmare…

Sensor bias (‘integrator windup’) error: Good thing FSAE tracks are so short! Even a (relatively cheap) ~tactical grade gyroscope should be able to be integrated for a minute, use the long straight on the track to update your measurement in the Kalman filter. Some approximate numbers for random walk vs GPS quality, using a 1 minute time base so that this /almost/ means the error per FSAE lap (numbers derived from VectorNav):
• Navigation grade walk (0.000226 deg/sqrt(min))
• Tactical grade walk (0.01 deg/sqrt(min))
• Industrial walk (0.387 deg/sqrt(min))
• Automotive /consumer walk (0.645 deg/sqrt(min))

BUT, the good thing about GPS is that it’s unbiased. So regardless of the speed or accuracy we can always use your two GPS measurements in a Kalman filter as a measurement update for attitude (heading is an ambiguous word). But again, that’s the clever thing about using a lap beacon - it’s a nearly perfect measurement to say each lap was 360 degrees…

The bad news… There is still an active patent for slip using two GPS antennas(https://www.google.com/patents/US6681180?dq=slip+angle+bevly&hl=en&sa=X&ved=0CBwQ6AEwAGoVChMIjI-Dv8amyAIVBhY-Ch0CcAlu)
So you won’t be able to commercialize this one I’m afraid.

~~~

As for optical sensors, I think the problem would be the maximum % overlap of each frame for the sensor to correlate images into motion. So that sensor for the quadcopters may not work if it is only a few inches off the ground, because even at ~10kHz the images don’t overlap! Also, perhaps (unless you use a collimating lens?) you must account for distance to the ground as well?
I’m very excited to read your paper MileyCyrus! Please let us know when it is published.

[murpia]

GPS module we will be using:
... Doing optical flow with gopro footage in real time is not going to be easily possible on standard embedded hardware, could implement something custom on an FPGA to track features and do vectorized math but not worth the effort. In my experience to make optical flow work well with low effort you have to throw fast hardware at it.
Just curious as to why you think it needs to be real time?

I would have thought syncing the video recording to the other data recorded on the car could be done in post processing on a workstation not embedded hardware. And even then, the necessary frame by frame analysis need not be real time. Using slip sensor data in real time for e.g. stability control is a massive leap from correlating your VD models in post.

Point taken on the rolling vs. global shutter issue. Not sure why, but I thought GoPros were global unlike the cheaper Chinese cameras. Seems not...

Regards, Ian

[Flight909]

Wouldn't the rolling shutter just show up as a bias in your calculated slip angle? And since you'd have to zero the angle anyhow, would it really be an issue?

I'm guessing the only thing would be if characteristics of the rolling shutter changed over time?

[Adam Farabaugh]

Ian, you're right - no real reason it needs to be real-time at this point. All of our other sensors are real-time though, just seems cleaner. We report live telemetry back at lower data rates and log full datastreams onboard at higher rates.

[exFSAE]

Better question is what would you use the data for? Need to be practical. I mean hey it's an interesting technical discussion I guess, but IMO there are better things you can be doing to make the car go faster.

[Adam Farabaugh]

Better question is what would you use the data for? Need to be practical. I mean hey it's an interesting technical discussion I guess, but IMO there are better things you can be doing to make the car go faster.

Agreed. As I said above I like to explore cool problems with other people's money while I can :)