I have been the Electrical and Programming Captain on team 1625 for 3 years now, and through those years we have had some pretty cool control methods (Like our Load Cell and infrared camera tracking in 2012 that won Innovation in Controls at Midwest) I am looking to make a jump in control methods over the summer and I need some ideas! I have been researching different sensors and discussing their applicability, I have also been looking into co-processors, vision programming ect. I have come to CD to see what cool control methods you have been using, be it an awesome custom dashboard, a beautiful vision system, “hacking” together a sensor, custom circuits, making individually addressable RGB LED’s work in Labview, auton magic, ect. Share your awesome control methods, and hopefully we can learn and draw inspiration from each other! 
Would it be practical to use a compass to sense your robot’s orientation more accurately than say a drifting KOP gyro? Or would all the electronics and electromagnetic motors surrounding it mess that up?
A combination of a gyroscope and magnetometer would be better, as magnetometers usually can’t be sampled very fast.
Team 443 used a netbook with RoboRealm running on it to process vision data from last years game and adjust speed of our shooter. One of my favorite uses of a gyro and mecanum wheels was field relative, being able to drive straight while rotating 360 was awesome. We also used a vertical gyro to auto balance us on the bridge last year. One thing that I always thought would be cool is being able to “record” autonomous by driving in teleop and it recording the values of wheels etc… and being able to “play” that in autonomous. There was also this this small serial LCD screen we could program things to display on, like battery voltage, team number, but ever got the chance to put it on the robot.
This year was still pretty basic for controls on our team.
We used a Hall-Effect Sensor (https://www.sparkfun.com/products/9312 using the typical 3 wire circuit described in the datasheet) coupled with two magnets on our shooter wheel to compute RPM. The RPM was fed into a bang-bang control (which switched to power control mode during shots) to control our single-wheel curved-shooter RPM.
We used a gyroscope (kit) at the front-center of our robot to make sure our multi-disk autonomous routine drove straight. We simply used the output of the gyro to feed the myRobot.Drive(speed,angle); function, with the angle input capped at 10degrees. We also hoped to use this to drive a center-line autonomous, but I didn’t see the need for it on Galileo, where most floor loaders that were better than us already had it.
I hoped to use encoders on our drive wheels to use position control during autonomous, but we were unable to get them working before bag date, and found tweaking time was good enough.
I had thought to use an accelerometer to help compensate our loader mechanism (which picks disks up from the floor, lifts up, and tosses them into a large tray where they funnel into our shooter bucket) so that we would load more gently while driving back, and more powerfully while driving forward, and not load at all while spinning. The code is in place, but I never had time to test it, since it solved a fairly minor/controllable problem.
We also had a 9-shot autonomous routine that was very close to working, however I couldn’t get the team motivated enough to test it (tried it 5 times in practice, one or two more would have probably had it working, but the problems were with the timing on the first two disks, which messed up the rest of the routine, so it looked bad to them). We definitely had a robot capable of doing the 9 shot, I wish we could have completed it.
We did that in 2010 and 2011, but not since then. We found that the extra code complexity and attention to timing management required wasn’t offset by a performance improvement in competition. Since we used mechanum wheels those years (be quiet Nick Lawrence, we still won Buckeye with it!
) we were able to do a neat trick where the robot would start in a fixed position, spin 360, drive to the top of the Bump, sidle on top of the Bump towards the Tower, then drive back off the Bump. Totally useless in game play, but kinda neat as a demo. Everything was done using cRIO resources, a YRG and encoders on all four wheels (with our own modified version of the WPILib mechanum drive routine that incorporated four independant PID loops). Got us one or possibly two RIIC Awards, so that was cool.
I don’t know if this would count as an innovative control, but we did win an award for it in control at KC regionals. Our climb code was completely autonomous, our drivers would just get centered on the pyramid, press a button, and watch it climb.
Not sure if it counts, but 1477’s driver told me at one of our regionals that he has been messing around with R/C cars forever, and likewise, has a controller to match. They are definitely one of the most agile bots I’ve seen, so I guess it works quite well.
It looks a bit like this: http://www.getprice.com.au/images/uploadimg/1572/dc1500.jpg
Cool stuff we had this year
Fully Automatic Frisbee shooting.
Line Robot up with goal (cross-hair on camera) -> Hold FC Preset button -> Hold Auto-fire Button -> Score Points
Tune shooter RPM as needed.
Automatic pyramid angle lineup
Select corner on Gampad’s D-pad -> Hold “Set Header” button -> Abuse mecanum’s ability to transverse
Oh yeah, forgot to mention the fact our drive-train controller’s control scheme is incredibly reminiscent of Call of Duty.
LJoy = Forward/Backward/Left Strafe/Right Strafe
RJoy = Rotation
We did similar with our climb and won the controls innovation award at Cross Roads. Illuminating the robot different colors to indicate robot statuses also contributed to the win. In regards to the climb we took it one step back from fully autonomous. The entire sequence was an autonomous climb but we had “breakpoints” at key steps that allowed the drivers to verify everything latched successfully before moving onto the next level. A side from falling off twice, once from the 2nd level and once from the 3rd level, the climb sequence was solid.
We’ve hacked a pistol grip RC car controller and a custom control box to Logitech gamepad guts. That has worked pretty well.
Otherwise, our control system is not too fancy:
Potentiometer PID on the shooter-mount
Bang-bang control with optical speed sensor on shooter
Fairly unsophisticated autonomous driving with gyro and encoders.
Developed but not used on competition robot:
More sophisticated autonomous driving
Full auto frisbee firing
“Cheesy Drive” inspired drivetrain control software
Everyone should see 1111’s control board this year; it’s a 3D printed model of their robot and controls the real one like a voodoo doll.
I know that Talon 540 used a PSP as their controller this year. I’m trying to get more information about how they did that because it sounds really cool. They even managed to get the screen on the PSP to be a secondary display.
What is YRG?
YRG= Yaw Rate Gyro (the technical name for a gyro)
Team 1504, The Desperate Penguins, won two Innovation in Control Awards this year (at the Kettering and Grand Blanc District Events) for their “Space Drive” control scheme. I don’t remember the specifics, but it had a whole bunch of cool features, including robot orientation-independent movement.
Thanks for the compliment. Me and my controls captain built it. We designed to to be a voodoo doll as you said. The voodoo doll controls the mechanism portion of the robot IE the shooter arm and everything attached to it. Pictures of the voodoo doll are attached below.
https://docs.google.com/file/d/0B6AB_Fr-jALvWW9ScExPWUtuU0k/edit?usp=sharing
https://docs.google.com/file/d/0B6AB_Fr-jALvVDg3Rm9kUFo4SzQ/edit?usp=sharing
I’m the Controls sub team Captain for 1111 Powerhawks, and yes; our controls board does act like a voodoo doll. We call it “Voodoo bot”, or machinula: little bot in Latin. The base and aesthetic wheels are ABS plastic printed in a 3-D printer. The structural parts are made of leftover bits of black 80-20, and miscellaneous scrap and FTC metal. Also, plexiglas (or equivalent) makes up the switchboard on the base, and the handle for the shooter arm controller is a piece of PVC.
The arm is on an axle that turns sprockets on a chain that are hooked up to a 16-bit rotary switch, to control the up and down movement of the robot’s shooter assembly. There are “firing buttons” at the handle end of the controller to index frisbees into the shooter, and any other switches (shooter on/off, shooter speed, autonomous selector, frisbee indexer de-jamb, arm position indicators, and any other operator control.)
The innards house the wiring, cypress unit, battery for back lights (bright blue LEDs to light up switchboard) and any other breakaway mini-boards for any of the controls. The Voodoo bot works directly with the laptop and what it does, the robot mirrors. Real Steel style.
We used a series of potentiometers in 2011 to mimic our arm. Not very practical in a match, but it made programming arm positions easy. We won an award for it and also our control board.
Here is a picture.
This year we implemented point-click, fully automatic, and manual targeting into our pan+tilt shooter. We also used encoder based (p-loop) drivetrain brakes, and an rpm-based rapid fire mode for our shooter.