Automated Test?

[joecaraccio]

So... from testing these last few weeks, we have a few sensors on the robot that could provide issues.

Off the top of my head, there is:

• [ ] turret encoder
• [ ] climb encoder
• [x] storage encoder
• [x] the storage without an encoder
• [x] shooter encoder
• [x] drive left side encoder
• [x] drive right side encoder
• [x] garage door sensor
• [x] intake roller
• [x] camera

Before we launch into TestPeriodic (and can manually test motors). Would it be worth developing an automated test in our Testinit? Quickly check if Encoder Values Work? If we can read everything?

[joecaraccio]

Then use the existing functionality in testperiodic to manually check functionality.

[Nick-P-Orr]

There’s currently in the final robot -1 gyro (connected to the RoboRIO) -6 encoders (1 on each drive mount, 1 on the lower intake, 1 on the shooter, and 1 for the climb, 1 on turret azimuth) -Garage Door sensor (connects to DIO on the RIO) -11 Talons -2 cameras connected to the roborio

I think the current talon setup is left front drive (1E), left rear drive (2), right front (3E), right rear (4), shooter slave (5), shooter master (6E), top roller (7), bottom roller (8E), turret turn (9E), intake (10), climb (11E) (E means there is an encoder).

@averwhy , would you want to start thinking of ideas to test all of this? I think we could be kinda creative with how we go about this. If we put the robot on the ground we could command the drive to turn for a half second in both directions and check if our gyro and encoders fall in a range. Conveyor and shooter could probably work in a similar way, run them for a set time and figure out a relatively tight rage they should fall in.

[averwhy]

Liam, Noah, and me talked about this and determined that is would be crusty and ineffectively lengthy to make this work.

Why? because in order to run things for set times, we'd have to make command wrappers for all of the state machine control functions. Therefore time consuming. We'd rather give Noah something to do instead of denying him his button mashing ability.

[Team138Entropy]

What Avery means to say is that in order to build a self-automated test function, all of the methods we normally hook up to button presses in our Periodic() loops would need Commands to call them, as well as more Commands to monitor median states and report back to the overall test routine. Had we used a classic CommandBased structure, this would have been a much easier undertaking, but with our current setup it would require too many fingers in way too many black-box pies.

• liam

[maxh65000]

Sign in to your real account liam

[onedeadeye]

no

[Nick-P-Orr]

Why do you need the state machine for any of the testing stuff? Is there a reason you don’t want to set a percent output to a talon?

[joecaraccio]

I think we are over complicating this. Like Nick said,

in a single maner you could step through and run:

• Motor A, Verify Encoder moves a reasonable amount of ticks
• Motor B, Verify Encoder moves a reasonable amount of ticks ....

This should be independent of the state machine. We have so many encoders on this thing.. would be a good self test before each match

[maxh65000]

I agree. The Storage subsystem, for example, has setBottomOutput() and setTopOutput(), as well as a updateEncoderPosition(). Using these methods will allow us to not have to set up the talons before we use them and greatly simplify this testing.

[maxh65000]

Hey haters it's almost done

[maxh65000]

What do we do with the gyro? Just put it on the dashboard?

[maxh65000]

136 addresses everything except the turret and climb.