Innovation in Control award discussion

I’m an ambitious, yet novice lead programmer for an ambitious and dedicated rookie team.

As a goal for our programming team, we want to win the Innovation in Control award next year at an event. Yet from my impressions of teams I’ve seen win this award, the award isn’t really a programming award. The official FIRST description is:

“Celebrates an innovative control system or application of control components – electrical, mechanical or software – to provide unique machine functions.”

This award definition seems a lot broader than control - it seems that cool mechanical features can (and do) win the only technical award programmers can also win. Do you think FRC needs an award tailored to programmers? Also, what types of innovation, programming wise, have won innovation in control awards?

One of my students rigged up a control setup for our swerve drive that won.

He wrote a MIDI to USB joystick program so that we could use a DJ turntable as the yaw control, and coupled it with a joystick for field-centric drive.

If I recall, the total award was for the unique control setup driving a swerve with field-centric driving, some pretty impressive control loops handling steering and the 180 problem (reverse throttle, or spin the module?). He really whipped up quite a slick system, and it was that ‘total system mindset’ that resulted in the award. He also had a system to use a hacked guitar hero controller to drive the secondary robot functions, like scoring triggers, LED patterns, and LED feedback.

1 Like

One of the coolest things that I’ve seen win Innovation in Control was the dashboard of 2423 The KwarQs in 2013. They had a vision targeting system to line the robot up with the goal. They also had a touch screen computer, with the camera feed (included boxes around the targets that were found) . So when they lined up for a shot, they just pressed on the goal that they wanted to line up to, and the robot aligned with it automatically.

Also, I’d say you might want to broaden your definition of control. Many servos used in FRC use a purely electrical control system to regulate the position to the desired setpoint. Many toilets use a completely mechanical system to ensure the bowl is refilled to the correct level. There are mechanical and electrical systems definitely deserving of Innovation in Control.

It seems broad because it is. I try my best to talk to most IoC winners to learn what they did – mainly to learn new things, but also to figure out how to win this darn award. A lot of times, it is for crazy mechanical subsystems or fancy electrical/pneumatic stuff (some teams received IoC for being early adopters of CAN).

FRC almost certainly needs a programming award. Luckily at champs this year, we got the Autonomous Award, which was a great start. Rumor on the street is that it might go to all events next year instead of just champs, which will be a welcome addition.

1 Like

I’d agree. Probably why there won’t be a programmer-only award for the robot, it is too hard to separate systems. Things that simplify the driver’s job or autonomous programming should be considered, though vanity projects that show some skill are memorable to judges. My view is that being able to perform well and students being able to discuss their control feature with judges in the pit is probably the most important. For our engineering award this year I think having a one-page summary of our unique features probably helped 1) to get students on the same page and 2) as a visual aid. Having it well documented and sharing with the FRC community can’t hurt either, and can show the value of the feature. You certainly can do this for a programming achievement, but it does have to be explainable to the judges.

edit: Okay, maybe an autonomous award for programmers, but the pool of non-engineering award (esp. the control award) or non-finalist competing for a purely autonomous award I would think would be a small number of teams.

1 Like

4513 has gotten 4 Inno in Control awards while i was a student, 2 in 2015 for programming a way for both forks to close by having one fork hit, then moving the bot slightly and forcing the forks to move in until both were hitting the tote, and two in 2017 for making our gear manipulator moveable from side to side, able to orientate the hear to the same spot every time, and eject the cube. It also was used in auto to help compensate for wide or tight turns We also got excellence in Engineering at World’s for it. Video link.

TL: DR Cole is a god.

Innovation in Control usually goes to a programming feature. Before specifics, it seems like using sensors is a good thing to do, in terms of getting the award. Think encoders, gyros, etc.

Last year when we won Innovation in Control at Lone Star North, it was for the dashboard. Here is a video of it during a match: https://www.youtube.com/watch?v=mVr3uT-sZ4U

This year, after our first regional, San Diego, our head programmer, Valeria, made a sheet that she could give to judges that summarizes the big features of our controls. This probably helped a lot as now judges had a sheet they could refer back to during discussion, and so other judges who didn’t judge us directly could also see what we were doing. Here it is: https://imgur.com/a/jxJnDAP

At our 2nd regional, El Paso, we won the Excellence in Engineering (usually a mechanical award, so maybe programming is taking other awards as well :ahh:). It was for a specific feature of the dashboard, the auto selector. This made it easy to change autons on the fly and was very easy to understand. I think at this point we have like 80 auto scripts. In addition, it had easy PID testers on the screen, so testing those were very easy, just a couple minutes on the practice field. Here is a picture for that: https://imgur.com/a/PCVNtXP

At Lone Star, we won the Innovation in Control award for the dashboard feature mentioned above, and also Anti-Tip code that prevented the bot from tipping over. Here is a video of the code working!

At the UIL event, we won the Robot Innovation Award, for anti-tip code, auton selector, and also code that allowed the robot to auto-shift gears while in motion.

All the credit for this stuff goes to Valeria and the other programmers on the team (not me I just watch).

I’d suggest trying to meet with 2468, they are also in Austin and win a lot of IC awards, plus are always willing to help other teams!

1 Like

It has been my experience that well thought out handouts that explain interesting machine features are highly correlated with awards. After we started writing up our “Freezy Drive”, it has won an award at four consecutive district events (Creativity, Innovation in Control x3).

We won the innovation in control and excellence in engineering awards this year for our custom control system. After having a unique system we were proud of, I think the primary item that led to our winning was encouraging the programmer to discuss it in detail with the technical judges when they come by. There’s a tendency for the more technical team members to summarize the more technical items when giving a description of the robot functions so as to keep it short and not bore the less technical. They need to be encouraged to describe some of the more advanced features in great detail to the judges so the judges understand exactly what makes the feature special and demonstrate the students knowledge of the functioning of the feature.

One of the easiest ways to help with your odds is to know the system so well that you can explain it. Our team doesn’t make super crazy robots, but we explain all of the nuances of our system, which impresses the judges more often than not.

100% this. Having a handout and being able to explain it to the judges are essential. This year we wom IoC for our well-designed control box setup that let us swap out our electronics at every event we attended this year. A key part of that was prepping documents related to it, which also ensured the students were able to talk about it well at the event. We follow this with our safety award binder and outreach documentation as well, and I think the quality of those documents, and being in a position to make those documents quality, was a big part of why we did well in those awards as well as taking home our first Innovation in Control Award this year.

I looked at your github description and am quite impressed with your work. Good job:eek: :smiley:

I’m solidly in this camp. I’m even not super into associating “autonomous award” with the programming team. As some of our favorite Poofy mentors have said recently, the best way to do auto is to design a robot which makes auto easy. It’s not just programming’s job to make the auto routine work. It’s the whole team’s.

On the topic of controls systems:

Embedded software is almost never an end unto itself. It’s merely the description of how you want a complex system to function. The lines of code written are just a particular means to a desired outcome. (see servo/toilet examples above)

I can tell you from (non-1736) experience - a poorly functioning drivetrain cannot be fixed by nifty software, no matter how wizard you think your programming team is :).

I don’t believe it would be possible to have a “software award” for a controls system, auto routine, or really anything related to robot motion… Yes, software is a part of that. But the mechanical and electrical components are also a huge part.

What could you do a software-only award for? Perhaps a software development process or build infrastructure that caused a measurable improvement in development efficiency or software quality? Perhaps even an award for well-commented and well-laid-out code (a la FLL style?), demonstrating true knowledge of the usage of the language?

In all these cases, so much of the award comes down to communicating with the judges. Many judges themselves are controls engineers, and you have to be able to talk at their level. Others will have never worked with a controls system in their life, so you have to also be able to talk at their level, and you probably won’t know which you have to do until the conversation starts. Having a solid innovation to “sell” is paramount regardless, but presenting it well can also make or break your chances at an award.

If only there were different types of software in FRC… Stuff like

  • Custom motion profiling implementation (more teams than you realize have done this)
  • Custom scouting systems (eg mobile phones -> database -> dataviz website) (see 1678)
  • Custom vision solutions
  • Anything that 900 does with ROS and whatnot (I can’t even begin to summarize it)
  • 254’s great idea to use vision processing on the scale to determine how high their elevator should go
  • Contributions to open-source work and/or strong software documentation provided for their robot code
  • Successful use of Agile/Scrum during the season and documentation on how/why it worked for the team
  • Robot simulation software

Agreed these are all great examples of exemplary software work in FRC of recent. If I could group them together further, would it be fair to say there’s a category of “innovative single software component that provides significant value to the whole system”?

It’s much more important for students to be able to articulate what they did and why than for the feature to be particularly nifty.

The Freezy Drive example above is an excellent example of student-driven and student-articulated design ownership & attention to detail in execution of both hardware and software design. In this case, in service to higher quality controls, so earning controls awards, and looking at design of pieces of the system most teams don’t bother to analyze or change, so earning creativity awards. It’s a beautiful system, and they deserve all the awards they got for it.

From a technical perspective, very little of it is groundbreaking (it’s not PhD research), and the robot speeds involved (12fps, 15fps) are low to medium. That’s not a bad thing. 1778 students totally owned the overall execution of an integrated controls system, brought attention to details often skipped in FRC, and likely drove circles around their competition in no small part due to all the attention they put into these upgrades to deliver the highest quality driver-machine controls connection that they could. Then explained all of it.

If your team’s students own and articulate the design process and outcomes, the judges will find an award that fits.

Innovation In Control can be many things. That said, there is another side to it that hasn’t been mentioned yet. Not only should your control be innovative, be you need to be able to explain it to the Judges for that award. How can you win an award for something that no one knows about?

We have won the IIC award a number of times. Even though we know that there were more innovative controls in use at some of the same competitions, we were able to explain in detail how and why we choose to use our control approach.

This variety in game-changing and innovative software is what makes me think there should be a specific award to reward these efforts. An earlier commenter argued that it’s hard to separate between mechanical systems and the software component. I disagree, citing the above list as proof that software solutions can be rewarded independently from hardware solutions. Certainly, hardware enables the software, and motion profiling what be successful on a kitbot with the bolts falling off, but in the same sense software enables mechanical hardware to move in the first place.

I think the autonomous award is a good step in this direction, but if no new programming award is to be created, the scope of the innovation in control award should be refocused on the creative software-side solutions of many teams, whether that be on the robot or in the hands of scouters. That way we can reward the diversity of software the way we reward the diversity of mechanical design through the various awards for that. Just my two cents. :smiley:

Also, thanks for your suggestions, especially on ‘selling’ your team to the judges and also having judge handouts. We will definitely be implementing these ideas.:smiley:

In 2011 we won the innovation in control award with a robot that had 2 limit switches on the arm and no other sensors. Super simple programming. What impressed the judges I think was that the whole machine was really smooth. The drivetrain and arm were just really easy for the drivers to operate well.

Can we put test-driven development on the list? Not only is that good industry practice, but to mock WPILib for unit testing is very nontrivial.