Sensors Not Required: FRC Design "Sans Feedback"

[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

[Jared Russell]

It sounds like minimizing the use of sensors and advanced automation techniques is a good fit for your team based on its resources. In general I applaud teams for being pragmatic about what is within their means.

As awesome as they are, the problem with sensors, automation, feedback control, and advanced autonomy is that there is a HUGE learning curve that you must conquer before you come up with even pretty basic functionality (ex. how many teams in FIRST can program their robot to accurately and repeatably drive a non straight line path?). Adding a sensor or automated routine to your robot also causes the number of potential failure points to increase exponentially, and in the 6-week-build world of FRC you often find a lot of heavily automated robots having teething problems as they discover these failure points.

FRC is very heavy on mechanics. While true "powerhouse" robots are a result of mastery of all aspects of engineering, many well-built robots with bare-bones code have won Regionals. Comparatively few kitbots with world-class code have done the same.

Mechanical disciplines, in general, are more tangible and are more quickly grasped by students. They have also been around for thousands of years longer than software engineering and we have become pretty good at formalizing them. Even in the microcosm of FRC, we had COTS gearboxes available to us long before COTS computer vision software (since the CMUcam was basically a closed system, I do not include it in this self-indulgent lamentation about the short changing of software in FRC ).

FRC games usually have some sort of incentive for automation (vision targets, randomization, additional game pieces during autonomous mode, etc.), but clever teams often find low-tech solutions to these problems that work just as well during teleoperation (best example I can think of is the "photon cannon"). Balancing the "need" for sensors and automation against the fact that many teams are deficient in these areas is (I would imagine) a real challenge for the GDC.