Sensors Not Required: FRC Design "Sans Feedback"

[Bongle]

I've been on sensor-heavy teams (my current one, 2702) and sensor-deficient teams.

The sensorless teams did ok, though they'd be inconsistent. It's hard to make sure that arms get to the right place each time, it's hard to do a proper repeatable auto mode, and it's hard to make sure that your robot can't damage itself in case of operator error. One time a structure that required two motors moving at the same time had the operator only move one motor and bent the entire frame of the robot.

2702 goes far in the opposite direction. Assuming everything worked (and at Waterloo, things did), this year's robot can be completely operated with 3 buttons: one to go to "load mode", one to load a frisbee, and one to fire the frisbees. Last year's robot needed two digital sidecars because we had about 14 sensors to manage the basketballs.

The firing mode had to spin up the motor until it was at the right speed, hold the speed, then move a set of augers exactly one rotation to release exactly one frisbee, then move a servo to push the frisbee out. All those operations were repeated 4 times in about 3 seconds. A human simply couldn't do it.

The advantages of a fully-sensored robot are pretty obvious: properly programmed, they're faster, more reliable, don't damage themselves, and are easier to operate.

Advantages to sensorless teams:
-Far fewer points of failure
-Simpler to code: not only do they not have to program sensor code, but they also don't have to handle cases where sensors fail and overrides are needed
-Few easier to test
-If designed properly (aka "let's hope the driver never makes a mistake" is never said or implied in the design), then they can be extremely robust and reliable.
-May be more likely to come across simpler (but equally good) solutions to the problem, as "solving it in software" is never proposed.

[MrForbes]

This year we were top seed and won the Phoenix regional with no sensors on the robot other than the pressure switch on the pneumatic system.

Oh....I fibbed....we had a camera on it, but it wasn't used, it just sat there looking pretty.

[Chris is me]

We try to eliminate sensors as much as possible, but sometimes they are useful. We have basically only used limit switches and encoders, though this year we used an IR sensor.

2013: Open loop shooter speed control. Because the discs slip on the shooter wheels repeatably, and because discs fly into the goal on the "upward" part of the trajectory, this works just fine.

We used an encoder + limit switch on our arm almost exclusively for autonomous mode. Probably could have used a pot, but meh. Arm goes down, zeros on the limit switch, goes up until we hit our preset encoder count, fires. This style of arm and shooter could have been done completely without sensors using pneumatics, but we liked being able to use the camera and a drawn crosshair to shoot from anywhere we wanted, so we made an aimable arm.

For our disc path, a limit switch and IR sensor would help us detect what state the hopper was in.

2012: Only sensor was our shooter wheel encoder. We had something resembling PID working for our offseasons, but it wasn't stellar. Software isnt' our strong suit.

2011: Zero sensor feedback. Robot was a pretty crappy arm-bot that we have all tried to forget since. Set points would have been nice.

2010: Zero sensor feedback. Robot was basically just an 8WD base with a piston kicker and a suction cup. There was no need.

[Mark Sheridan]

This year we are using way less sensors. I always try to plan for a design not to use sensors just in case a sensor breaks. We did have to implement a few this year.


1. We have a light sensor to measure shooter wheel speed. We have a ban-bang control loop set up to control the speed. 766 is running a similar set up to us and they have no control loop. We have a wobblier mounting for our shooter than than them so i feel our design has to eliminate our speed error a bit to match their accuracy. Mostly our bang-bang controller eliminates firing at too fast of a rate and causing shots to to be fired at a slow speed. I think a practiced operator could do this manually. We also use polycarb whips to touch the pyramid, so we avoided vision systems.

2. The drive train pretty much runs with no control loop, we have been messing with our gyro but it looks like we wont need it. We do mess with the joystick curve to change the throttle response. We did design the drive to have encoders have have them in place. We only use them when the PTO is engaged on the left hand drive. I do have a design philosophy this year of making sure our motor systems always have a spot to place an encoder.

3. Our climber has two limit switches to prevent crashes. We tried to design the climber to be strong enough to crash but the PTO has enough torque to skip chains so we have to use the limit switches. We also zero the encoders using the limit switches. I think we have everything to automate the climb but we bounce over corners so I think we will leave in manual. We also have a camera to check our alignment.

[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