What margin of error is tolerable in FRC?

[davidthefat]

What margin of error is tolerable in FRC? After running tests with last year's robot, the margin of error on the drive train encoder output was 1.45% and 3.45%. That seems insignificant, but is it? Would a kalman filter be necessary if this data was getting put into a PID control loop?

[Tristan Lall]

Originally Posted by davidthefat

What margin of error is tolerable in FRC? After running tests with last year's robot, the margin of error on the drive train encoder output was 1.45% and 3.45%. That seems insignificant, but is it? Would a kalman filter be necessary if this data was getting put into a PID control loop?

I'm actually more interested in what margin of error is acceptable for the officials' decisions—and that's kind of what I hoped the thread was about when I saw it in the portal—but that's a subject for another thread.

What's the second sensor for the Kalman filter? Even without knowing the plan, given that many teams do without even PID, my educated guess would be that you can get away without it—so it's not "necessary". Are you planning to use this for autonomous modes, or just for analyzing robot motion after the fact? How accurate are your measurements, anyway? What are you using as the baseline? Have you considered how much error is inherent to backlash in the drivetrain, for example?

The real answer is that it depends. You're going to need to define what's important to you, and assess it in that framework. Do some failure mode analysis: if the error on the encoder is 3%, and given certain other assumptions about the robot, what are the effects? Are those tolerable to you?

Another part of the analysis concerns how difficult it is for you to acquire or implement a suitable Kalman filter. Are you good at coding? Do you understand the principle of operation? What other things could you be doing instead of implementing a Kalman filter?

[Jared Russell]

Is the encoder on a driven or non-driven wheel?

Non-driven wheels ("follower wheels", typically using a primitive suspension and an omniwheel) will just about always give you better encoder data than powered wheels simply because wheel slip is not an issue. I would try using a non-driven wheel before attempting something like a Kalman filter.

[davidthefat]

Originally Posted by Tristan Lall

I'm actually more interested in what margin of error is acceptable for the officials' decisions—and that's kind of what I hoped the thread was about when I saw it in the portal—but that's a subject for another thread.

What's the second sensor for the Kalman filter? Even without knowing the plan, given that many teams do without even PID, my educated guess would be that you can get away without it—so it's not "necessary". Are you planning to use this for autonomous modes, or just for analyzing robot motion after the fact? How accurate are your measurements, anyway? What are you using as the baseline? Have you considered how much error is inherent to backlash in the drivetrain, for example?

The real answer is that it depends. You're going to need to define what's important to you, and assess it in that framework. Do some failure mode analysis: if the error on the encoder is 3%, and given certain other assumptions about the robot, what are the effects? Are those tolerable to you?

Another part of the analysis concerns how difficult it is for you to acquire or implement a suitable Kalman filter. Are you good at coding? Do you understand the principle of operation? What other things could you be doing instead of implementing a Kalman filter?

It is mainly for autonomous mode. The second sensor would most likely be a gyro. The error is mostly due to mechanical issues. The chains jiggle a lot so that translates into noise in the readings. My mentor has the mentality that all software can eliminate mechanical issues. And he kind of already has put all his eggs into the software basket this year. I've already written most of the relating to the drive train for this year... Coding is not the issue; the real issue is properly understanding and implementing the filter. As far as I know, that only requires some linear algebra and a lot of reading up on it. I spent the last 2-3 days just reading up on it.

I really do not have much to do other than implement that filter and tuning the PID constants. Perhaps I can be doing my winter break homework

Originally Posted by Jared341

Is the encoder on a driven or non-driven wheel?

Non-driven wheels ("follower wheels", typically using a primitive suspension and an omniwheel) will just about always give you better encoder data than powered wheels simply because wheel slip is not an issue. I would try using a non-driven wheel before attempting something like a Kalman filter.

All our wheels are driven (WCD)

[Joe Ross]

Can you describe the test that you performed to determine the 1.45% and 3.45% values.

[davidthefat]

Originally Posted by Joe Ross

Can you describe the test that you performed to determine the 1.45% and 3.45% values.

I let the wheels run, on blocks, at a constant PWM value for 5-10 minutes at a time and plotted all the data points on Excel and got the average RPM and divided by the range of values. And now I think about it, that is not the correct way to measure the MoE...

[Andrew Schreiber]

[quote=davidthefat;1096299] My mentor has the mentality that all software can eliminate mechanical issues. And he kind of already has put all his eggs into the software basket this year.
[\QUOTE]
Yeah... uh he's wrong.

[quote=davidthefat;1096299]
I've already written most of the relating to the drive train for this year...
[\QUOTE]

Check the rules on this one.

So here's the deal, good software can make a good robot great. Bad software can make a good robot bad. Good software can't make a mechanically incomplete robot good. What I'm trying to say is that, for FIRST, you don't always need fancy controls, you don't need 100% accurate movement. You need a 100% reliable drive train. A trained drive team. A solid scouting/strategy team. And a dedicated team of students and mentors.

[davidthefat]

Originally Posted by Andrew Schreiber

Check the rules on this one.

So here's the deal, good software can make a good robot great. Bad software can make a good robot bad. Good software can't make a mechanically incomplete robot good. What I'm trying to say is that, for FIRST, you don't always need fancy controls, you don't need 100% accurate movement. You need a 100% reliable drive train. A trained drive team. A solid scouting/strategy team. And a dedicated team of students and mentors.

I thought that if the code was publicly available before the kickoff, it is all good. It is on a public repository on GitHub as I type.

As far as your other comments go, I personally agree. However, I have to do everything in my power to make this year's robot best as I can. We are clearly lacking in the hardware aspect of the team and I am considering even doing the electronics this year because the main electrical guy graduated last year. It is my last year and I can't just sit around and expect someone else to do anything. That is partially the reason why I started writing the code two weeks ago and testing months ago. I'm just trying to do the best I can.

[EricH]

Originally Posted by davidthefat

I thought that if the code was publicly available before the kickoff, it is all good.

According to the 2011 rules, it is. (blue box in <2011R22>)

Therein lies the problem: we don't know if the rules will remain the same for 2012. Yet.

[jacob9706]

I don't know if you ever found an implementation but we created one in Java last season to try out on joystick readings. Here is what we came up with.

[wireties]

Originally Posted by davidthefat

I let the wheels run, on blocks, at a constant PWM value for 5-10 minutes at a time and plotted all the data points on Excel and got the average RPM and divided by the range of values. And now I think about it, that is not the correct way to measure the MoE...

Just a heads up... the drive train, the sensors and the software are a complete system. The system will behave very differently with no load (sitting up on blocks). In general running it on the ground dampens the response a bit and makes the system more stable. Your error bars should decrease.

HTH

[Djur]

Originally Posted by jacob9706

I don't know if you ever found an implementation but we created one in Java last season to try out on joystick readings. Here is what we came up with.

What's that gigantic int array, joystick output? And those variables have very descriptive names... could you elaborate on what they're for?

[Ginto8]

Originally Posted by Djur

What's that gigantic int array, joystick output?

It's only used in main(), so it just seems like sample data to me.