Sensors Not Required: FRC Design "Sans Feedback"

[MagiChau]

I find that there are good benefits to sensors of course providing they work. I use them for autonomous, checking if the shooter is at the correct RPM, preventing mechanisms from slamming into the hard stops, and provide accurate feedback of the robot's location on the field.

On our robot we have an Axis Camera primarily used to help our drive team make sure the robot is lined up in autonomous and align to the corner for climbing. Going blind would be a nightmare for our driver.

We use limit switches on our climber to prevent our motors from stalling trying to get past the hard stops.

We have encoders on our PTOs for autonomous driving after our three shots are fired and for autonomous climbing. We have done manual climbing but it gets tiresome for ourdriver to do a 12 stage climb every match. I do not trust using timers as distance covered can vary based on the battery.

Lastly we have a gyro for turning in autonomous. Again the actual turn can vary based on battery voltage if timer based.

On the shooter we have a hall effect sensor to measure RPM. This allows our operator to 100% know that the shooter wheel is up to speed before firing a frisbee.

My team every season tries to find the balance between manual and automation. We try to use sensors as simplistically as possible. We do not do anything beyond basic closed feedback loops to slow down a mechanism as it approaches the target and simple logic check for if a mechanism is at the hard stop.

Sensors are there to supplement the mechanical system of the robot. Try to find what works the best for you.

[stuart2054]

I agree with most of what is said here. It is a balancing act. The more your know about the various sensors and have experience in implementing them the better off you will probably be but poorly implemented they can be a detriment. Our team could use more experience with things like vision, gyros, encoders etc... and I am sure we would find more uses for them. I think the mechanical design, which by nature has to be first, drives the automation and what can be done to add effectiveness to the robot by sensors and programming to make the drivers job easier and automomous the most effective it can be within your skill set.

Growing your knowledge is tuff for many of us but always useful. My work experience has made me familiar with utrasonic range, photo detection and analalog principals but not with vision, gyros, encoders and the like. For our vision system last year I would have be lost without the white papers and Greg McKaskle posts on CD. You have to keep it simple but realize when you need more high tech solutions.

[faust1706]

Originally Posted by stuart2054

It is a balancing act. The more your know about the various sensors and have experience in implementing them the better off you will probably be but poorly implemented they can be a detriment.

I agree with this completely. Every year 1706 has been around, we have implemented a gyro, now it is no big deal for our (labview) programmer (sadly, yes, it is singular). We are big fans of limit switches. This year, we put limit switches on our robot to know if we our claws are touching the pyramid so we can hang. Last year we had one to know if we were touching the bridge or not. Just simple tasks.

As this being my second year doing vision programming, it came a lot easier for me and the program this year is much more advanced than last year. That, of course, comes with experience.

I feel as if every team should at least attempt to use different sensors, just to see if they like them. That is what we did with vision last year, and we (meaning I) loved it, and fortunately it helped, a lot.

The less you have to guess. the better you are off. Or at least that is how I see it.

[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