+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 11 to 18 of 18

Thread: Slip Sensor?

  1. #11
    Senior Member
    Join Date
    Mar 2008
    Location
    Brighton, MI
    Posts
    686

    A Different Angle on this

    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 !

  2. #12
    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.
    Nathan Tarlinton
    UOW FSAE 2010 - 2013

  3. #13
    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/US668...IVBhY-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.
    Austin G.
    Tech. Director of APEX Pro LLC
    Auburn University FSAE
    War Eagle Motorsports
    Chief Chassis Engineer 2013
    Vehicle Dynamics 2010-2012

  4. #14
    Quote Originally Posted by Adam Farabaugh View Post
    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

  5. #15
    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?

  6. #16
    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.
    Penn Electric Racing

  7. #17
    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.

  8. #18
    Quote Originally Posted by exFSAE View Post
    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
    Penn Electric Racing

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts