Sensors Not Required: FRC Design "Sans Feedback"

[z_beeblebrox]

Last year, 4183 used no sensors on our robot except two limit switches at the ends of the turret travel and the pressure switch. We suffered because of it. Our shooting was slow to align and inaccurate since the driver had to manually aim the turret (a potentiometer or encoder would be far better) and there was no closed-loop shooter speed control.

During the off-season, we competed in Vex Robotics Competition, using more sophisticated software techniques, such as velocity and position PID control, multi-threaded code, motor controller linearization and trapezoidal velocity profiles. Most of these features worked well, given the limitations of Vex sensors, and made the drivers' lives much easier.

This year, we applied the lessons learned from Vex to FRC. On our robot, we have encoders and a gyro for the drivetrain, a potentiometer and limit switches on the shooter mount, custom optical encoders on the shooter wheels, a limit switch for pyramid alignment, the pressure switch and a camera to help run the floor intake. These sensors helped make our hardware far more competitive. However, effectively using all these sensors requires extensive software skills (Thanks Ether, 254) that must be learned and practiced before build season. It is certainly worth pursuing these skills; they can only help you. That said, there are many highly competitive robots (1726, as mentioned above) running very simple software.

Also, more complex sensor-based software can be far more difficult to debug and fix at competition. We learned about this the hard way: Since we built a practice bot, our software was written and tuned for it. When we tested it on our competition robot, we had serious issues with shooter mount and drivetrain control. Thursday afternoon and most of Friday of the Arizona regional was spent debugging the code. That cost us our first five qualification matches (though we did then win the second five).

Please feel free to ignore all my ramblings. This was written late at night after finishing a rather annoying Literature essay.

255th post. Is my post counter about to roll over to 0?

[Donut]

When I was a student on 498 we made heavy use of sensors, but that was largely because I was head of the programming team and kept wanting to learn new things each year. Sensors can definitely help make a good robot better and there is a nice shiny award for using them well, but I would put them as the last focus because they will usually not make up for mechanical deficiencies (the only personal exception was we used a gyro to drive straight which prevented our drivetrain in 2007 from drifting to one side). Our robots were living proof of it, in 2006 and 2007 we had multiple autonomous mode options and in match automation of our shooter targeting (2006) and arm positions (2007). None of it mattered because our game piece manipulators were poor in both years and we tended to lose control of game pieces long before we could score them. I guess it did matter some, as our ability to score in autonomous was probably the only reason we made eliminations in 2006, but we were more or less useless 20 seconds in to most matches due to ball jams.

If you have a little extra programming resources, push for one new sensor each year. Maybe use a potentiometer on an arm next year, the following try to add a gyro, etc.

Something I think teams tend to forget about when they go ahead with more sensor control is what will happen if the sensor fails. Starting in 2006 we always built in a Manual Override switch that would allow us to disable all sensor control when flipped. It saved us once or twice when a potentiometer slipped or a limit switch got jammed and we were able to get out of the software lock on our arm by overriding sensor feedback.

[Kevin Leonard]

Last year we tried to automate so much- and it was well beyond the abilities of our programming team. Our robot was a well built robot, but it couldn't shoot well at all (we ended up playing "feederbot" at UTC and CMP).
This year we simplified. We have two limit switches that turn on lights when we're in shooting position.
That's just about it.
Our drivers, however, are incredible, and make up for any deficiencies in software this year.

[nlknauss]

I also agree with a lot of what's been stated here. It really does take a few years to develop that "library of experience" that can be repeated applied to different applications year in and year out.

I've been on a few teams over the years and have seen different approaches to design with and without sensors in mind. In my experience/opinion, my most successful years have been with robots that have been designed achieve the goals of the game through simple mechanical systems with sensors/feedback added to enhance those systems. This doesn't mean that control system personnel are excluded from the design process as mechanical systems are designed. You have to have control designers involved so that accommodations can be made to make control enhancements.

This season alone, I've seen some great robots who have no feedback back to drivers stations during matches. You kind of have "Duh!" moments with yourself when you see the simplicity in design with these teams.

Nate