[FRC Blog] Control System Update

[cgmv123]

Originally Posted by Tom Line

Unless FRC creates some way of gently nudging suppliers to supply LabVIEW code as well

Here's a nudge: If you don't support all of our programming languages (including LabVIEW), our rules won't allow teams to use your device at all.

[Jaci]

Originally Posted by cgmv123

Here's a nudge: If you don't support all of our programming languages (including LabVIEW), our rules won't allow teams to use your device at all.

"Hey we're just going to completely blacklist your device because you don't want to support a proprietary language officially despite many existing devices supporting only a few languages with the community figuring out the rest".

Friendly reminder that there are no rules stating that you have to use WPILib, just rules stating you must use the official driver station. Making this rule is completely unnecessary and unreasonable.

[marshall]

Originally Posted by Jaci

Making this rule is completely unnecessary and unreasonable.

I agree that additional rules are not likely needed at this time but there is a real concern that some manufacturers won't support specific languages down the road if this is being pushed out to 3rd parties. The community has and continues to pick up the slack though so here's to hoping we'll keep up that trend.

[slibert]

Originally Posted by marshall

I agree that additional rules are not likely needed at this time but there is a real concern that some manufacturers won't support specific languages down the road if this is being pushed out to 3rd parties. The community has and continues to pick up the slack though so here's to hoping we'll keep up that trend.

Hear, hear. I wanted to echo Marshall's point:

My 2c on this initiative to enable inclusion of 3rd party device libraries is that it enables a greater opportunity for those students interested in product software engineering to get real-world experience - contributing to products that make things better for all FIRST teams.

I want to take this chance to thank all of the mentors and students who have helped or are currently helping w/the navX-MXP/Micro library development and testing. This includes Joe Ross, James Parks, Tim Easterling, Alex Allen, Dustin Spicuzza, Thad House, Christian Sandrowski, Elizabeth Makizuru, Tyres Caberto, Nygel Melchor and more. The result is navX-MXP/Micro libraries in 5 languages. There is no way we'd be where we are at now w/out all this help. And the work continues: development is underway to add even more features and make these libraries even simpler to use.

If there are others with similar interest in being a part of this type of effort, please feel free to personal message me and we can discuss what opportunities Kauai Labs has in this area.

I have a sense it's possible that other device manufacturers might have similar opportunities...

[bobbysq]

Originally Posted by Jaci

"Hey we're just going to completely blacklist your device because you don't want to support a proprietary language officially despite many existing devices supporting only a few languages with the community figuring out the rest".

Also, what's stopping the creator of a device from making WPILib plugins on their own, but unapproved by WPILib? I really hope this means they won't lock down WPILib, preventing cool mods like running code at 50hz or using DIO as extra PWM output.

[calcmogul]

Originally Posted by bobbysq

I really hope this means they won't lock down WPILib, preventing cool mods like running code at 50hz or using DIO as extra PWM output.

Our motivation for pulling out the third party libraries was our inability to adequately test all hardware devices that came along, decoupling our release/update schedule from (possibly) many vendors, and providing a clean way for other third party code like teams' open source software to be easily included by other teams.

We feel our software and development tools should be as open as possible. We acknowledge there could be quality assurance issues with letting third party vendors handle packaging, such as badly written software, missing languages, and restrictive licenses. We're working on packaging standards and an easy packaging process for our supported target platforms. For example, we could have a Gradle script that builds for all our platforms and produces a tarball containing shared objects and includes. That would get automatically detected by the WPILib Eclipse plugins and extracted (I can't speak about LabVIEW since I've never used it). Part of that process could include us providing build and distribution infrastructure (not that it would be required) while vendors provide tested code that meets our packaging standards. Keep in mind we're still actively working on what this will look like.

I know a few other developers and I are willing to help vendors bring their language support up to speed if their licenses aren't restrictive (virtuald has echoed this sentiment a few times).

[adciv]

I have a feeling this means team libraries will be expanding.

[JR0405]

Will the decrease in range cause issues? I wonder this because the indoor range is 25'-50' through 1-2 walls and since the driver station wall is between the robot and the computer and the field is 57 feet long. I could be wrong but wouldn't this make it hard to connect to your robot and make it easy to lose connection?

[adciv]

The driver station does not connect directly to the robot. The driverstation is hardlined to an Access Point located at about the middle of the field where the FTA is usually sitting. The robots connect to the Access Point. The barriers to the robot to field connection are the robot structure, other robots, and the field obstacles.

[scca229]

Originally Posted by adciv

located at about the middle of the field where the FTA is usually sitting.

Mostly correct on the rest of it (the driver stations plug into the SCC at each end of the field, which then carries it to the FMS), but....you've actually seen an FTA sitting!?!?! I'm going to have to stop listening to my step-count on my Band 2 At the AZ State Champs event this past weekend, 27900 steps on Friday Setup day, 25000 steps on Saturday event and tear-down day. I think my rear end hits a chair 2 or 3 times a day once I'm at the venue and one of those might be lunch if I'm lucky (mostly because I don't want to stiffen up and not be able to move again).

[adciv]

Ok ok, FTA is standing, kneeling, and troubleshooting the FMS, bending over it with the precision adjustment tool trying to get it working again. Although I have seen FTAs sitting for long periods of time. Typically when in discussion with HQ about why the #$^@#($ field is acting up again.

[Basel A]

Originally Posted by JR0405

Will the decrease in range cause issues? I wonder this because the indoor range is 25'-50' through 1-2 walls and since the driver station wall is between the robot and the computer and the field is 57 feet long. I could be wrong but wouldn't this make it hard to connect to your robot and make it easy to lose connection?

The robot radio connects to the FMS (which is wired to the driver station computer), which is on the side of the field and not through any walls.

[Caleb Sykes]

Originally Posted by cgmv123

Here's a nudge: If you don't support all of our programming languages (including LabVIEW), our rules won't allow teams to use your device at all.

No, let's not do that. Leave the developers free to provide support for whichever languages they want, and leave the teams free to utilize whichever language they want.

I don't mind at all if teams use unique languages like Python, but if they start taking away resources from me because Python is not supported by many FRC Suppliers, then we have a problem.

[virtuald]

Originally Posted by Caleb Sykes

No, let's not do that. Leave the developers free to provide support for whichever languages they want, and leave the teams free to utilize whichever language they want.

I don't mind at all if teams use unique languages like Python, but if they start taking away resources from me because Python is not supported by many FRC Suppliers, then we have a problem.

Python isn't officially supported, so I doubt they would require a supplier to support Python. If they were to make such a requirement, it would probably only affect the officially supported languages: C++, Java, and LabVIEW.

It seems like such a requirement wouldn't be necessary -- there are a significant portion of teams using each language, so not supporting one of them would be leaving money on the table.

[adciv]

I think it depends on the component. It's not be a big deal for sensors. But for anything FIRST limits such as motor controllers...well, if CTRE didn't support one language for their Talons SRX, any team that typically uses it would be at a distinct disadvantage.