+1 to having a “stall” command.
Our line of thinking often says that each subsystem should be in one given state at a time. Different commands can swap between the states, and there is one default one. Here is an example of our Hopper subsystem from our design spec:
The hopper’s job is to store balls collected from the intake, then quickly push them into the shooter one by one.
In this state, the dejammer wheels and the feeder wheels stop spinning.
When entering the feed state, the dejammer wheels and the feeder wheels both spin inwards. This forces the balls into the shooter.
The feeder wheel stops spinning and the dejammer wheels spin outwards. This removes jams. All jellies, perservatives, and marmolades remain in the robot.
(Some people say a spec is over kill. We find it to be just the right amount of kill)
Full Subsystem Spec
Drivetrain
The drivetrain’s job is to get the robot from point A to B, whether that be by driver input or trajectory following. It uses curvature drive and motion-profiling with quintic spline generation.
Marketing Note: Motion profiling + Curvature drive are very advance topics, please make sure include highlight them in any media about the drivetrain.
States
Open Loop (default)
In this state, the driver is in full control of movement. Joystick input will be fed directly in as power inputs to the motors (after being cubed in order to give more control to the drivers)
Path Follower
In this state, the motion is controlled by a trajectory. This trajectory is fed in as a parameter. It sets the speed of the drivetrain based on an internal timer. This state automatically ends when the timer reaches or exceeds the total time of the trajectory.
Hardware
Shooter
The shooter’s job is to automatically track the goal and shoot balls when told to by the operator. It automatically tracks with the use of vision processing and gyro-based control.
Techincal Note: The shooter and hopper are very closely intertwined in function. We considered combining into one subsystem. It was decided that they each had their own states and functions, so they should be keep seperate. In the case that a command group needs information about a subsystem to determine the state of another, a “status” value will be passed over network tables.
States
Idle Shooter
All motors stop rotating.
Lazy Tracking (default)
In this state, the turret uses the NavX Gyro to approximate the goal target. It uses the angle to point the turrent down field. This makes it so the turret is almost lined up once we are ready to shoot. All other motors stop spinning.
Techinical Note: Consider using occasional burst of limelight tracking to adjust the angle of hood. Might also make since not to move the hood (because that’s you’re like to shoot from the same position) or to go back to a default angle.
Precision Shot
In this state, the turret and the hood use the limelight vision tracking to move into position. If an adeqauite vision target cannot be found, default to joystick values until found. The flywheels spin up once into position (within a tolerance). The limelight camMode is set to 1 for short range shooting.
Techincal Note: Rather than a 1, you could make a constant in the constances file and pull that.
Long Shot
This state is the same as Precision Shot, except the Limelight camMode is set to 0.
Quick Shot
This state is the same as Precision Shot, except the flywheel start spinning up immediate, allowing a operator to take a shot regardless of whether the turret is fully lined up. It will still try to lineup though.
Techincal note: Consider overloading and making this take in a tolerance parameter. The robot shoots once within the tolerance. Send a warning print statement if a tolerance less than the one specified by Precision Shot is used, since this method specifically is meant to be less tolerance than Precision Shot.
Eject
This state sets the flywheels to a very low power, so the balls can be gentle lofted to forwards, about 10 feet. All other motors stop. Overload the construct to allow an turret angle and hood angle to be added to specify the position of these.
Marketing Note: This method is used not only for dejamming balls stuck in the shooter, but also for the strategic value of being able to unload one’s feederstation very quickly into their trench run.
Hardware
- 2 FalconFX’s for the flywheels
- 1 TalonSRX for the hood
- 1 Rev through bore encoder for the hood
- 1 Limelight for hood and turret
- 1 TalonSRX for the turret
- 1 NavGyro for the turret
Intake
The intake’s job is to collect balls from the ground.
States
Stow (default)
In this state, the intake rollers stop spinning. It is stowed inside the robot for protection.
Collecting
The intake roller spin inward. It is extended outside the frame to collect balls.
Hardware
Open Issue Don’t know what CAD plans to use to actuate intake
- 1 VictorSP for intake rollers
- 2 pneumatics for acuating the intake
Hopper
The hopper’s job is to store balls collected from the intake, then quickly push them into the shooter one by one.
States
Idle Hopper (default)
In this state, the dejammer wheels and the feeder wheels stop spinning.
Feed
When entering the feed state, the dejammer wheels and the feeder wheels both spin inwards. This forces the balls into the shooter.
Dejam
The feeder wheel stops spinning and the dejammer wheels spin outwards. This removes jams. All jellies, perservatives, and marmolades remain in the robot.
Hardware
- 1 VictorSP for feeding balls
- 1 VictorSP (connected to 2 bag motors) to dejam balls
Climber (Currently off the table due to complexity)
The climber’s job is to extend at the end of the match and allow the robot to pull itself up onto the shield generator.
States
Open Issue: A clear enough picture does not exist. Talk to CAD about what theclimber might look like.
Hardware
Open Issue: This is just a guess, because CAD has not designed this feature yet.
- 1 Falcon500 for climbing wench
- 1 pnuematic for a brake
Writing Specs
Specs written based on approach by Joel Spolsky.
Painless Functional Specifications