Team 1261

So, usually, the post ship period are a bit more relaxed, and there's no doubt that the amount of work will decrease, but we need to keep in mind that there are some crucial things to do.

Below is a little Time Table for when things should most likely be done/start wrapping up.

Post-Ship to Tuesday before P'tree.
- We need to test the impeller, and then test it again. In cahootes with the impeller, we'll need code for it. And similarly, I think we can simulate firing with the impeller as well.

- We need to build the operator control panel. Whether we use an attache, an 80-20 box, or a backpack, we need to do that, and do it nicely. \

- We need to compile and finish the BOM.

We have enough resources to pull off the above very easily.

Thursday of Peachtree Regional

- We need to rewire. We can take the VEX PWMs and use different sizes to make the panel neater, but we definitely need to rewire.

- We need to install the impeller mechanism. (The assembly for the front of the chassis should be safely stowed away somewhere)

- We need to install the dome.

- I think Tanner was very understanding about the issues we were having and he didn't totally freak out, but he needs time with the robot to get the PID loop working properly. As great as the driving is, I think it'll be much better when the loop stuff is actually running.

- Sunny

I think it's kind of late to attempt the PID code. It'd take too much time to tune and even then I'm not sure how much we would gain out of it.

I do believe I fixed the little jitter problem though. I had some erroneous code in the PID stuff (which we were using to debug - hence it was running) and just turning it off/removing it seemed to fix it. Do I know for sure? Not exactly, but if it is still there I won't know until Thursday.

-Tanner

Too Late?!?!?!?

An hour today would've been good, but an hour on Thursday isn't good? I think it can't hurt to try it. If the drivers aren't comfortable with it by the time you've done the PID code, then so be it.

Sunny wrote:Too Late?!?!?!?

An hour today would've been good, but an hour on Thursday isn't good? I think it can't hurt to try it. If the drivers aren't comfortable with it by the time you've done the PID code, then so be it.

I would need a hour with a field/open area. Doubt we can get the practice field for that long.

-Tanner

Tanner wrote:

Sunny wrote:Too Late?!?!?!?

An hour today would've been good, but an hour on Thursday isn't good? I think it can't hurt to try it. If the drivers aren't comfortable with it by the time you've done the PID code, then so be it.

I would need a hour with a field/open area. Doubt we can get the practice field for that long.

-Tanner

Hm...I see your point.

Just out of curiosity,

looking at the encoder spins graph, if the PID loop works, then shouldn't there be one line when we go 100% forward? So then can't we just test it with blocks, take the ratio that give us the best graphs, and then take it onto the field.

Or can't you make the code so that we can change the ratios in real time? I remember we could do that before or something. So that when when it's on the field, then you can quickly tweak.

I know that the conditions are ideal, but we have to work with what we have.

Sunny wrote:looking at the encoder spins graph, if the PID loop works, then shouldn't there be one line when we go 100% forward? So then can't we just test it with blocks, take the ratio that give us the best graphs, and then take it onto the field.

That might work (emphesis on the might), but I think it might end up with a wrong ratio or something. Or it would be noticed.

Sunny wrote:Or can't you make the code so that we can change the ratios in real time? I remember we could do that before or something. So that when when it's on the field, then you can quickly tweak.

Not sure when we did that. You could, but it might be chaotic.

-Tanner

Tanner wrote:

Sunny wrote:looking at the encoder spins graph, if the PID loop works, then shouldn't there be one line when we go 100% forward? So then can't we just test it with blocks, take the ratio that give us the best graphs, and then take it onto the field.

That might work (emphesis on the might), but I think it might end up with a wrong ratio or something. Or it would be noticed.

Sunny wrote:Or can't you make the code so that we can change the ratios in real time? I remember we could do that before or something. So that when when it's on the field, then you can quickly tweak.

Not sure when we did that. You could, but it might be chaotic.

-Tanner

Or, I remember that back in 08, randy had little buttons to change the ratios in the code so he could tweak the code without having to change the values and then downloading code each time, and then when he found a nice value, he hardcoded it.

Just a suggestion. I just feel like this is something we can do.

Sunny wrote:Or, I remember that back in 08, randy had little buttons to change the ratios in the code so he could tweak the code without having to change the values and then downloading code each time, and then when he found a nice value, he hardcoded it.

Oh. Those buttons. That was Randy's way of debugging the autonomous mode faster without having to take like 30 minutes just to download code. Kinda was like LabVIEW using the actual buttons instead of the dashboard.

We can always try the ratios, I just don't know how effective it will be at Peachtree. It's not like the drivetrain is at a 20% difference between the left and the right sides. More like a 2.5 to 5% difference possibly.

-Tanner