Accelerometer success?

[gvarndell]

Originally Posted by Bongle

We adjusted our WindRiver accelerometer class so that it implemented an averaging filter. It takes the last 20 samples and averages them. It delays its responsiveness somewhat, but it also removes much of the noise that the accelerometer displays.

We know that there is a GetAverageVoltage function, but it didn't seem to be doing any actual averaging, so we averaged GetVoltage instead.

How often are you sampling?
Are you able to translate your average acceleration to a reasonable approximation of current velocity?

[Bongle]

Originally Posted by gvarndell

How often are you sampling?
Are you able to translate your average acceleration to a reasonable approximation of current velocity?

I doubt we would be able to, the thing is still very noisy. We're sampling at about 100hz (the rate that our wheel-control PID loop is currently running). The spec sheet says that accelerometer runs up to 225hz, so we might bump it up later as a test.

The good news is that we don't want to get our velocity. We're comparing the accelerometer-reported acceleration with the acceleration reported from our encoders. If the encoders report an acceleration substantially higher than the chip, we know we've got wheelspin and should probably do something about it.

[MrForbes]

Originally Posted by Bongle

We're comparing the accelerometer-reported acceleration with the acceleration reported from our encoders. If the encoders report an acceleration substantially higher than the chip, we know we've got wheelspin and should probably do something about it.

I was thinking about this, and realized that it's probably unnecessary...if the encoders report an acceleration substantially higher than the robot can accelerate (which is a pretty low number, at the rate the encoders report things happening) then you have wheel spin.

[Bongle]

Originally Posted by squirrel

I was thinking about this, and realized that it's probably unnecessary...if the encoders report an acceleration substantially higher than the robot can accelerate (which is a pretty low number, at the rate the encoders report things happening) then you have wheel spin.

There are a couple reasons I like the dynamic approach:
1. It covers more cases. Our robot could get involved in a pushing match and have the TCS still work (in theory)
2. It covers the case where the trailer starts filling up, and the ratio of the robot-trailer system's mass tilts more towards the trailer
3. It works as the field and wheels degrade and their CoFs increase or decrease
4. It works on the carpet.

The static approach will our fall-back if we can't get the dynamic setup working properly.

[MrForbes]

I don't see any cases there that would not be handled by the static approach...the robot mass is pretty large compared to the inertia of the wheels, even in a situation where you get bumped by another robot, or drive on the carpet, or the load on the robot changes. In a pushing match you'll be accelerating much less than when you're out in the open.

(really, I'm not trying to dissuade you from making the accelerometer work, I just think that it's not necessary for TCS)

[Bongle]

Originally Posted by squirrel

I don't see any cases there that would not be handled by the static approach...the robot mass is pretty large compared to the inertia of the wheels, even in a situation where you get bumped by another robot, or drive on the carpet, or the load on the robot changes. In a pushing match you'll be accelerating much less than when you're out in the open.

(really, I'm not trying to dissuade you from making the accelerometer work, I just think that it's not necessary for TCS)

One big issue is your on-carpet acceleration: On a carpet, your robot's potential acceleration will be higher than on regolith. So if you artificially cap wheel acceleration to your on-regolith acceleration, you're hurting your peak performance.

Another issue is your ability to push trailers or pull a loaded-up trailer: Your in-code maximum acceleration will be higher than what your robot can physically achieve, and so your wheels will be able to speed up and start spinning despite the code being there.

However, these arguments from me are mostly based on our system's theoretical performance. It may turn out to be not reliable enough for a full-time implementation, at which point a static setup makes sense.

[Jared Russell]

Originally Posted by Bongle

One big issue is your on-carpet acceleration: On a carpet, your robot's potential acceleration will be higher than on regolith. So if you artificially cap wheel acceleration to your on-regolith acceleration, you're hurting your peak performance.

Another issue is your ability to push trailers or pull a loaded-up trailer: Your in-code maximum acceleration will be higher than what your robot can physically achieve, and so your wheels will be able to speed up and start spinning despite the code being there.

However, these arguments from me are mostly based on our system's theoretical performance. It may turn out to be not reliable enough for a full-time implementation, at which point a static setup makes sense.

Well put.

In short, static acceleration limiting will prevent slip as long as (1) no external forces are manifest and (2) you know your CoF with high confidence. Once these assumptions are broken, however, you can lose traction and - with the static approach - you will have no automatic way to detect that this has occurred and, by extension, will have no automatic way to regain traction.