[FRC Blog] The 2016 Season, by the Numbers 2

[Hallry]

Posted on the FRC Blog, 6/7/16: http://www.firstinspires.org/robotic...-the-numbers-2

The 2016 Season, by the Numbers 2

Written by Kevin O'Connor, Robotics Engineer.


One of the under-the-hood features of the FRC Control System software is a system called Usage Reporting. This system tracks what WPILib objects are created in each team's code and reports the data back to FMS when the robot is connected to the field. This data helps FIRST and our Suppliers understand how teams are using the Control System which can give us insight into things such as adoption of new features or usage of legacy classes.

Here are a few numbers from the data that teams may find interesting:

152,572

The total number of Usage Data records captured by FMS

22,607

The total number of motor controllers used on 2016 robots

6,402

The total number of USB input devices used to control those motors

2,156

Total Encoders used to get feedback from those motors

1,4021

The number of teams that used pneumatics (with the PCM) on their 2016 robot

764

The number of USB cameras streamed back to the Driver Station

489

The number of Digital Outputs used to control non-actuators (lights, sensors, etc.) on 2016 robots

17

The number of Analog Outputs used to control non-actuators (sounds, lights, etc.) on 2016 robots



1

The number of teams using the GearTooth sensor class which was made for the GearTooth sensors from the 2006-2008 KOP

The complete processed data set can be found here.



A few notes on this data:

- The data has been semi-anonymized. Team numbers have been replaced with rookie years and the data has been resorted so teams are not in order by team number.

- We can only track the objects teams create in code. If you create extra motor controllers that aren't on your robot2, they will still be captured by this system. If you create motor controller objects of the wrong type, that wrong type will be captured by this system.

- Counted objects and TRUE/FALSE show the largest number of any given object used in any one match (i.e. if a Robot had 2 Encoders in match 1 and 3 Encoders in match 7, 3 will be reported). Language and Framework report what was used in the last recorded match.

- Some objects naturally result in double counting (Encoders use Digital Inputs)



1Compressor may not show for C++ and Java teams that didn't use the Compressor object. Counting the # of teams that had > 1 Solenoids is a more accurate count of teams using pneumatics.

2Example: 43 teams report more than 4 relays with only 4 relay ports on the roboRIO.

[marshall]

So how do we get more encoders on more motors?

[notmattlythgoe]

Originally Posted by marshall

So how do we get more encoders on more motors?

Require 2 encoders to be declared per motor. Because 2 > 1.

#2encoders

[Thad House]

Those numbers are really cool and interesting to go through.

Originally Posted by marshall

So how do we get more encoders on more motors?

One thing to remember is that Encoders hooked up through CAN Talons would not show up. I saw a decent amount of teams doing that this year, which would probably help raise that some more. But I do agree more teams need more encoders or potentiometers, as that greatly increases the performance of robots.

[notmattlythgoe]

Originally Posted by Thad House

Those numbers are really cool and interesting to go through.



One thing to remember is that Encoders hooked up through CAN Talons would not show up. I saw a decent amount of teams doing that this year, which would probably help raise that some more. But I do agree more teams need more encoders or potentiometers, as that greatly increases the performance of robots.

It also probably isn't taking into account optical sensors used as counters for shooter wheels.

[marshall]

Originally Posted by Thad House

One thing to remember is that Encoders hooked up through CAN Talons would not show up. I saw a decent amount of teams doing that this year, which would probably help raise that some more. But I do agree more teams need more encoders or potentiometers, as that greatly increases the performance of robots.

Are you certain about this? I would think they would still show up per WPILib... I am likely wrong though.

As for tuning PID... I think we need to release some directions on how we do it... that or Omar should put his method out there. We spend maybe a couple hours tuning it and then we play with values a little here or there as needed but typically we get it right pretty quick. I'll see if I can't get a student to explain the method they use.

[Thad House]

Originally Posted by marshall

Are you certain about this? I would think they would still show up per WPILib... I am likely wrong though.

They don't. The encoder and counter reporting are only set when the WPILib encoder or counter classes are used. The encoders into the CAN Talons have no way currently of getting reported, as they are just methods in the CANTalon class.

So for like our robot, which is on 1885, it only shows 1 encoder, as we only had 1 hooked into the roboRIO, and the other 2 were directly into CANTalons.

[marshall]

Originally Posted by Thad House

They don't. The encoder and counter reporting are only set when the WPILib encoder or counter classes are used. The encoders into the CAN Talons have no way currently of getting reported, as they are just methods in the CANTalon class.

So for like our robot, which is on 1885, it only shows 1 encoder, as we only had 1 hooked into the roboRIO, and the other 2 were directly into CANTalons.

Well then... there are likely a lot more encoders not being *ahem* counted for then.

Sorry, had to do it.

[notmattlythgoe]

Originally Posted by marshall

Well then... there are likely a lot more encoders not being *ahem* counted for then.

Sorry, had to do it.

[Jon Stratis]

Originally Posted by marshall

So how do we get more encoders on more motors?

I think the key to this is figuring out how to make tuning the PID loops easier. We've been using encoders and potentiometers with PID loops for years, yet it still takes our programming team a ridiculous amount of time to get each one tuned correctly. There just isn't enough time to get them set up correctly most years, and even though we put them on the robot and try to get them working, it seems like we end up commenting them out when we get to competition and have run out of time to get them working.

Plus, the USDigital encoders that we've always used have such small wires... it seems we're always breaking one or more of them!

[Anupam Goli]

Originally Posted by Jon Stratis

Plus, the USDigital encoders that we've always used have such small wires... it seems we're always breaking one or more of them!

Once you go Grayhill, you never go back.

Originally Posted by Thad House

But I do agree more teams need more encoders or potentiometers, as that greatly increases the performance of robots.

Depends on the application. If I have a 2 position arm or mechanism that doesn't need precise operation, I can get away with just using a limit switch. And I'm sure that you don't really need encoders for intake rollers, either; but teams should definitely be using them for their drivetrain and shooter wheels. (Hell, 1648 used a banner sensor and a piece of retro-reflective tape on a belt for our shooter's feedback)

[Conor Ryan]

Coolest thing I saw:

Lang	Count	Percentage
C#	1	0.03%
C++	435	13.97%
Java	1526	49.00%
LabVIEW	1116	35.84%
Python	33	1.06%
Unknown	3	0.10%
Total	3114	100.00%

[Cothron Theiss]

Originally Posted by Conor Ryan

Coolest thing I saw:

Lang	Count	Percentage
C#	1	0.03%
C++	435	13.97%
Java	1526	49.00%
LabVIEW	1116	35.84%
Python	33	1.06%
Unknown	3	0.10%
Total	3114	100.00%

I am very curious as to what the three unknown's are. Also, I had completely assumed that LabVIEW would comprise the majority, or at least be the most commonly used.

[Jon Stratis]

Originally Posted by Cothron Theiss

I am very curious as to what the three unknown's are. Also, I had completely assumed that LabVIEW would comprise the majority, or at least be the most commonly used.

This actually doesn't surprise me very much. Java is the language used for the AP Computer Science exam, and thus the option that is probably taught in schools the most. I'm sure many teams made the decision to go with Java for just that reason!

[jtrv]

Originally Posted by Conor Ryan

Coolest thing I saw:

Lang	Count	Percentage
C#	1	0.03%
C++	435	13.97%
Java	1526	49.00%
LabVIEW	1116	35.84%
Python	33	1.06%
Unknown	3	0.10%
Total	3114	100.00%

C#? Who? What? When? Where? Why?