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

[Cel Skeggs]

Originally Posted by AlexD744

I can see this happening if they only had a drive base and initialized it with the RobotDrive constructor that takes in port numbers instead of motor controller objects.

There are some other explanations. At least two of the teams with no reported motor controllers are due to our framework - we don't report usage data currently, due to it not being a high priority for us compared to the other goals we could work towards. See rows 525, which is our team, and row 1951, which is another team that we know uses our software. These rows pretty much only report the language.

I could definitely understand it if something similar happened with another few projects.

[BrendanB]

Originally Posted by marshall

So how do we get more encoders on more motors?

If suppliers like Vexpro and Andymark included their integrated encoder options in the pages of the products they work with it could help teams who don't know they exist to look into them.

Take it a step further and have more experienced teams make tutorial videos on how to add sensors to mechanisms (installation, wiring, programming, and basic debugging).

I know from experience that sometimes when teams are building a robot it can come down to the lead purchaser saying, "I saw this on their website maybe this can be useful too". The teams who surf CD daily or eagerly wait for the new product launches aren't as large as one would think. Many teams don't use certain parts because they either don't know it exists or don't know how to use them. Cost can be a factor as well but I'd put it lower on the list on the why teams don't use them.

[Andrew Schreiber]

Originally Posted by BrendanB

If suppliers like Vexpro and Andymark included their integrated encoder options in the pages of the products they work with it could help teams who don't know they exist to look into them.

Take it a step further and have more experienced teams make tutorial videos on how to add sensors to mechanisms (installation, wiring, programming, and basic debugging).

I know from experience that sometimes when teams are building a robot it can come down to the lead purchaser saying, "I saw this on their website maybe this can be useful too". The teams who surf CD daily or eagerly wait for the new product launches aren't as large as one would think. Many teams don't use certain parts because they either don't know it exists or don't know how to use them. Cost can be a factor as well but I'd put it lower on the list on the why teams don't use them.

I'd also add "get more teams using CAN" to that list.

I've been around a long time, I've done a lot of stuff with closed loop controls. But I still prefer to run something with limit switches or cylinders if possible. Call it laziness if you want. But the fact is that being able to set a motor to a speed and then stop it is really easy and can solve a LOT of problems. But this year with CAN, once tuned (with a web dashboard might I add) I essentially just had to set the desired position in code and it handled the rest.

[frcguy]

If anyone is curious, 95% sure that row 2725 is 5940. Looks like we are the only rookie that used Java and had 5 Talon SRXs, so that's how I determined it.

[AWoL]

225 is row 118. Everything matches up to a "t," except I have no idea why the system would think that we have a single, old Talon...