What's your favorite programming/control system magic this year?

[billylo]

Effective programming/control system techniques almost work like magic. Unlikely mechanical designs, they are frequently hidden from regular observers.

Which cool techniques have you seen or adopted this year that are creative and worth highlighting for your peers?

I saw a few cool ones:

• Pulsing solenoid control to shoot with different power (842 and others)
• CheesyVision - use of driver station's camera during auton (hot goal)
• 1114/973's Kinect based - hybrid like control during auton (e.g. drive/blocker control)
• I forgot which team... an awesome motion-detection system (Axis-camera) to follow the opposing robots' movement for shot-blocking (saw them on the CMP practice area near Netwon)

What's your favorite?

[faust1706]

I personally love feedback systems. Like in 2012 and 2013, vision would be calculating how far away the robot is to the goal, and the shooter would always be adjusting to be ready to shoot. 341 had this in 2012 and I'm sure again in 2013, we(1706) had it for both years. It is truly amazing.

[brennonbrimhall]

The devil's in the details. Most of my favorite cases of programming are very much behind the scenes:

• 254's elegant usage of VEX bump switches. You can see them in Barrage's picture on their Aerial Assist page. I assume (based on their placement) that they were used to pulse their intakes when they are grabbing the balls for their famous auto.
• 254 and 1114 both had a strip of LEDs on their robot that lit up when the flywheel was up to speed for their drivers.
• Both 987 and 4334 have implemented their own engine to parse out an autonomous scripting language. 4334's engine for Gordian is open source and can be found on GitHub. Though I've never used Gordian, I can imagine that it cuts down on compile/reboot time when writing auto routines.*
• 33 had a unique catapult design that involved a lead screw that they used to vary their shot. I don't know if they ever did, but this gave them the ability to vary their shot distance on the fly. The only other teams that I know of that could change their shot distance on the fly were all flywheel based (or, per billylo's post, pneumatic).
• While not used, a sophomore on the team developed some OpenCV for ball detection, with the intention that it would be used in an autonomous mode that would pick up our partner's misses. The ball detection code was written, but the corresponding auto mode was never implemented due to our decision to allocate resources in a manner more consistent with our priority list. Who knows...maybe we'll finally have some time to realize it for some of our off-seasons.

*An aside: I'm curious to see whether or not they (Gordian, and other in-house scripting languages) are displaced with other solutions: the roboRIO is supposed to have Java 8, which should allow usage of Jython and/or Rhino (Java engines for Python and Javascript, respectively) for Java teams.

[Pratik Kunapuli]

254 had code that allowed them to set waypoints on the field and have the computer make a spline in that path. The spline was then translated into different motor curves for each side of the drivetrain. They could literally draw a path and have the robot follow it.

From Kevin Sheridan on /r/frc:
"We generated a path using quintic hermite spline interpolation. This creates two individual paths for the right side of the drivetrain and the left side of the drivetrain. We can tell the path generator the goal location, goal velocity, goal heading, starting location, starting velocity and starting heading. We can also set the max velocity for a path. This way we can set a path using multiple waypoints to navigate to a certain spot on the field in a specific way such as driving in a s-curve."

[billylo]

Originally Posted by Pratik341

254 had code that allowed them to set waypoints on the field and have the computer make a spline in that path. The spline was then translated into different motor curves for each side of the drivetrain. They could literally draw a path and have the robot follow it

Jaw-dropped.

[E Dawg]

Originally Posted by Pratik341

quintic hermite spline interpolation

For the record, my favorite magic so far is our team's quadratic deadband.

[SoftwareBug2.0]

Originally Posted by E Dawg

For the record, my favorite magic so far is our team's quadratic deadband.

What is that and what do you use it for? My first guess would be that you're trying to do some sort of fancy filter with some sort of funky ripple in the stop band but, my google fu fails me so my best guess is that "quadratic deadband" is just a made-up name.

[E Dawg]

Originally Posted by SoftwareBug2.0

What is that and what do you use it for? My first guess would be that you're trying to do some sort of fancy filter with some sort of funky ripple in the stop band but, my google fu fails me so my best guess is that "quadratic deadband" is just a made-up name.

It filters out extraneous values like a normal deadband, but instead of having output values come out linearly after the deadband they scale quadratically. We use it for our drive code.

And yes, the name is made up.

[Thad House]

Originally Posted by Pratik341

254 had code that allowed them to set waypoints on the field and have the computer make a spline in that path. The spline was then translated into different motor curves for each side of the drivetrain. They could literally draw a path and have the robot follow it.

From Kevin Sheridan on /r/frc:
"We generated a path using quintic hermite spline interpolation. This creates two individual paths for the right side of the drivetrain and the left side of the drivetrain. We can tell the path generator the goal location, goal velocity, goal heading, starting location, starting velocity and starting heading. We can also set the max velocity for a path. This way we can set a path using multiple waypoints to navigate to a certain spot on the field in a specific way such as driving in a s-curve."

That is absolutely incredible. Hopefully they actually release that code, because that would be so cool to read through and learn how it works.

[RobotDoktor]

At Championships we had a fairly interesting system controlling our pneumatic catapult pulses. We had a pressure sensor that measured the pressure feeding to our launcher pistons. We used a polynomial function based on collected data that would match pressures to pulse times so that the shot is consistent regardless of pressure. Our programmer could probably tell you more about it if you want.

[Joey1939]

1986 had really simple yet effective targeting system setup. A ultrasonic sensor set low to the ground told them how far away they were from the wall. When the robot was in shooting range, LEDs on the back of the robot lit up to inform the drivers.

[MrTechCenter]

Originally Posted by Joey1939

1986 had really simple yet effective targeting system setup. A ultrasonic sensor set low to the ground told them how far away they were from the wall. When the robot was in shooting range, LEDs on the back of the robot lit up to inform the drivers.

We did the same thing! I'm glad to see that we had the same idea as a famous team.

[ekapalka]

Originally Posted by Joey1939

1986 had really simple yet effective targeting system setup. A ultrasonic sensor set low to the ground told them how far away they were from the wall. When the robot was in shooting range, LEDs on the back of the robot lit up to inform the drivers.

This is quite similar to what we did this year :) Except we used ours as an active aim-assist to put ourselves the correct distance from whatever was in front of us when a button was held. We literally got it working ten minutes after the last match :/ Our autonomous and teleop aim-assist could be reduced down to just a few lines of code using the map() function we replicated from the Arduino language. For both the range was smoothed using a moving average to avoid jittering.

ForwardSpeed = map(rangefinder_distance - target_distance, 0, 200, 0, 1);

The map() function takes an input (in our case from a rangefinder), the minimum expected value of that input, the maximum expected value of that input, the minimum value to output, and the maximum value to output. The input/output ranged aren't exactly set in stone... if the input is greater than expected, the output will also be outside of the expected range (meaning that the above piece of code can be used when too close or too far away from the wall, even though the output should fall between 0 and 1. It just re-maps values from one range to another. We pretty much programmed the entire robot on the fly during competition this year, so the only time we had to test out changes during matches. We ended up running into the wall on more than one occasion due to this...

[SoftwareBug2.0]

Originally Posted by ekapalka

This is quite similar to what we did this year Except we used ours as an active aim-assist to put ourselves the correct distance from whatever was in front of us when a button was held. We literally got it working ten minutes after the last match :/ Our autonomous and teleop aim-assist could be reduced down to just a few lines of code using the map() function we replicated from the Arduino language. For both the range was smoothed using a moving average to avoid jittering.

ForwardSpeed = map(rangefinder_distance - target_distance, 0, 200, 0, 1);

The map() function takes an input (in our case from a rangefinder), the minimum expected value of that input, the maximum expected value of that input, the minimum value to output, and the maximum value to output.

I read part way through that and I was like awesome, someone has decided to use map, filter and fold. That's still pretty cool though. We started writing something like that but didn't finish because it didn't fit how we played the game.

[Joe Ross]

Originally Posted by ekapalka

Our autonomous and teleop aim-assist could be reduced down to just a few lines of code using the map() function we replicated from the Arduino language. For both the range was smoothed using a moving average to avoid jittering.

ForwardSpeed = map(rangefinder_distance - target_distance, 0, 200, 0, 1);

The map() function takes an input (in our case from a rangefinder), the minimum expected value of that input, the maximum expected value of that input, the minimum value to output, and the maximum value to output. The input/output ranged aren't exactly set in stone... if the input is greater than expected, the output will also be outside of the expected range (meaning that the above piece of code can be used when too close or too far away from the wall, even though the output should fall between 0 and 1. It just re-maps values from one range to another.

This is another way of doing proportional control, (ie the P in PID). It's a nice way to do a first pass to figure out the P constant.