What margin of error is tolerable in FRC?
 

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?

Re: What margin of error is tolerable in FRC?
 

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?

Re: What margin of error is tolerable in FRC?
 

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.

Re: What margin of error is tolerable in FRC?
 

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:p



All our wheels are driven (WCD)

Re: What margin of error is tolerable in FRC?
 

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

Re: What margin of error is tolerable in FRC?
 

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

Re: What margin of error is tolerable in FRC?
 

[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.

Re: What margin of error is tolerable in FRC?
 

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.

Re: What margin of error is tolerable in FRC?
 

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.

Re: What margin of error is tolerable in FRC?
 

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.

Re: What margin of error is tolerable in FRC?
 

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

Re: What margin of error is tolerable in FRC?
 

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

Re: What margin of error is tolerable in FRC?
 

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