Autonomous

[Michael Chau]

The usage of the 12 position potentiometer dial as an autonomous selector has been what we used for many seasons. There are other autonomous mode selection setups that we could do however. What we would have working without much development is the potentiometer dial and up to 16 DriverStation inputs. It appears the issue with SmartDashboard crashing last year is gone so we are now open to using it for autonomous settings. An example would be a widget to adjust the shot delay offset or select how many discs are preloaded.

Ryan has suggested a design scheme of splitting up the autonomous selection to allow more flexibility and power in autonomous settings. Such a design would possibly go robot initial position, enable drive to center line, select first shot time, select second shot time, select third shot time, do nothing.

Initial position ideally as of now is aligned to the high goal behind the pyramid. Being able to shoot from other positions would allow us to accommodate other teams unable to start anywhere else but the middle. Each position would affect the shooter speed setting. Some possible positions would require driving the robot for a clear shot which adds complication in shooting because it requires the robot to accurately drive and turn.

Autonomous shooter setting based on distance calculation would theoretically make the shooter almost 100% accurate in autonomous but there may not be time to properly integrate it into the robot code.

Shooter speed control will be developed to especially prevent shots from being fired before the shooter is at the correct RPM. We can obtain an estimated time for the shooter to recharge from testing to be able to predict total shooting time for a load. This can be used in autonomous to set minimum times between shots and in teleop to prevent misfiring. Last year we wrongly prioritized auto aiming over shooter control and lost too much time.

Autonomous drive code should be relatively minor in time needed to be implemented compared to other subsystems. The two commands will be drive straight and turn in place to keep it simple. The purpose is to drive the robot towards the center line to save a few seconds needed to travel there in teleop. The distance traveled should be short to prevent crossing the center entirely or collision with opposing alliance robots. The drive will most likely be based off of trapezoidal motion profile to ensure motors dont "jump" and cause the robot to turn and because it is very simple in concept. The turn could be based off a gyro or encoder. If we could get the gyro to properly function it would give us great feedback otherwise the encoder would have to do. The turn would orient the frisbee hopper towards a feeding station to minimize teleop time need to reorient the robot.

The shot times is meant to prevent collision of Frisbees in midair by coordinating with alliance robots. Tests should be done to measure the total time the Frisbee remains in the air to allow the drive team to accurately determine correct shot times. Shooter control will either prevent the Frisbee from being fired until the shooter is ready or used as estimated between time of shots. The ability to reliably use SmartDashboard really opens the ability to actually have a lot more control over the shot times.

The prioritization will go from features needed to features that would be nice to have. Shooter speed control and position shooter speed settings is at the top of the list to ensure every shot will be as accurate as we can make it. Shot times is critical especially in elimination matches where a single autonomous Frisbee could be the event winning shot that gets blocked due to inability to accommodate shot times to your alliance partners and your robot's capacity. Drive code is second to last as a luxury that admittedly is mostly flashy but still offers nice benefits for the small time investment. Last is autonomous shooter speed calculations due to the numerous amount of bugs that could occur without proper testing for reliability. It is the biggest possibility for a time sink. Static shooter speed settings aren't pretty but they don't have a chance by itself to set the shooter to the wrong speed due to the vision target not being properly tracked.

Autonomous has been a critical and underdone part of almost every year's challenge. Ever since 2010 autonomous involved uninterrupted points and ability to position (excluding teams blocking 469 in 2010) creating deficits that make or break a match. It offers both teams and spectators an exciting glimpse into the world of autonomous robots that can only rely on sensors and the internal system to do tasks. In my last year as I student I would like to be able to see the robot do be able to do what it was unable to do in 2012 (lacked shooter control) and 2011 (lacked proper drive control.)

tldr - Plan to make an awesome autonomous this year so read the entire thing