NotInControl
commented
9 years ago Do we know what sensors we are going to have on the actuators? I am not sure if we will have sensors on all motor controllers, like the intake wheels for example, or the winch motor.
A good generic approach for motor controller would be to use the PDP to sense current in those instances. Because we know encoders exist on the drivetrain we can make those tests use these sensors.
It make be useful to walk through each actuator and understand what sensors if any do we have to sense the pass/fail criteria. For example, what sensors if any do we have for the intake open/close piston, or gripper open/close.
Mapping out these sensors will guide the programmer better on what to code for this.
We can have automated tests for actuators we have sensors for, and use human eyes for the sensors on actuators we don't have sensors for where the person running the test determines the pass/fail of that actuator.
The idea here is to develop a single command that we can run in the pits which will sequentially go through and test that all our motors and actuators are working correctly. If any aren't we can generate an alert or log an event. This will be a great feature for selling the controls award, and also make it real easy for us to verify everything is operational between matches.
The starting point will be to identify the expected results when sending an output to a motor or actuator. For example, if a left drivetrain motor was commanded to drive forward, the expected result would be to observe a positive RPM on the left drivetrain encoder. If we saw a negative RPM or none at all, that would be a problem.
Start by sequencing all the motors (drive in one direction, stop, drive in the other direction, stop, move to next motor, etc.) we will add in the verification steps next.
It might make sense to create a new package that all the commands for testing components can live under. Call it diagnostics?