Programming Problems

[Tanner]

Yeah, I don't know if anyone will check this, but hey - might as well.

So the programming problems that I see thus far is that:

• Variable Kicking Backwinding
• Arming Lock-Down
• Autonomous Depreciated

So the problems with the variable kicking/backwinding is that apparently the rope length has changed thus causing the backwinding to be different than it used to be. We've played around with different timing and it's not working with the current system we have. I have two ideas, though they're both kinda one idea. Have separate settings for each setting, and use either a) encoder clicks or b) time to backwind. Encoder clicks would be accurate, and I think the encoder should still spin there. It would have no reason not to.

I don't really know why the arming lock-down (when the kicker crushes the limit switch). It might be deep down in my code somewhere. Revamping the code sounds like a nice idea, but I'm not sure if I can do that tonight. Usually we have a bit more time driving, a bit more time to iron out the bugs before Peachtree. This year we've had very little driving time. Lots of things changed between ship and today.

Uh, autonomous. I don't have the three or four constants I need for autonomous. I don't know if I could use any of it anymore. If I have no constants, our autonomous won't be as awesome. I might look up the distances we need and we might just extrapolate the distances tomorrow by going one feet of encoder clicks and doing some math. That should work, but it requires us looking at the field docs. Kapp, if you want to do that and ease the load on me that'd be great.

Uh, I don't think there is anything else. The kicker wasn't working on the field, no idea why - see "arming lock-down". There's also a mysterious tiny-lag bug, but idk where it came from.

And I'm tired. *sigh*

-Tanner

[Sunny]

Today was really tiring, but most important of all, we got stuff done. From a hardware perspective, tomorrow, we need to ...

1. Create a funnel to funnel balls towards the suction cups.
2. Tape the crap out of the impeller and maybe try to find leaks.


From programming perspective...
1. Tanner, Kapp and I can get the distances you need tomorrow. We can just go onto the practice field and get what we need.If we get an "extrapolated version", then after our first match, we have a practice block set up, and we can tweak. Just...out of curiosity, since we have encoders on our drive, won't the extrapolation be pretty accurate?

2. I think rebuilding the code is a great idea, I just don't know if we'll be able to do that in the time frame.

3. For the backwinding, it seems that either the time is being counted differently, or the team for each section is different. It might just be easy to have a time set for each kicking mode rather than only have one constant time for all of the modes.

We REALLY need to get onto a practice field tomorrow. I would like to test the kicker we have. I was told that we have a spot at 10:30, but we should sign up for like...a line for the pit registration. Although, in the past, they generally don't let teams register for the day after...

[Tanner]

1. Tanner, Kapp and I can get the distances you need tomorrow. We can just go onto the practice field and get what we need.If we get an "extrapolated version", then after our first match, we have a practice block set up, and we can tweak. Just...out of curiosity, since we have encoders on our drive, won't the extrapolation be pretty accurate?

Practice field doesn't have the dots for the balls. And the real field guys won't let us measure anything. They're very touchy about that field, but like come on... Extrapolation should be as accurate as the base measurement.

3. For the backwinding, it seems that either the time is being counted differently, or the team for each section is different. It might just be easy to have a time set for each kicking mode rather than only have one constant time for all of the modes.

Just realized a problem to that. Kinda. That would be ideal with three definite positions, but overall we have 300 possibilities - one for each encoder click from "ful power" to "slow power". A way to do this would be to find encoder clicks for the backwinding for the full and slower power modes and extrapolate the different in the middle. That should work. That should work very well in fact.

And for Sunny - I figured out how to do what you were talking about, in a bit easier way. It should work pretty well now. Well, it won't crush Mr. Limit Switch anymore.

-Tanner

[Sunny]

And for Sunny - I figured out how to do what you were talking about, in a bit easier way. It should work pretty well now. Well, it won't crush Mr. Limit Switch anymore.

-Tanner

I'm interested in hearing about the solution.