[FRC Blog] Control System Update

[Philip Arola]

Shout out to Dustin Spicuzza at pyfrc for staying the course and not doing this. This might have made us convert overnight. Seriously, having manufacturers provide installers for libraries is awful. Setting aside the obvious OS problem (which I don't care too much about), its going to become disjointed and hard to manage. I simply cannot remember the last time dependency management with installers actually worked elegantly. Perhaps I am reading it too literally, and they might make Eclipse (shudders) installers.

[virtuald]

Originally Posted by Philip Arola

Shout out to Dustin Spicuzza at pyfrc for staying the course and not doing this.

Funny you should mention that. One of the side effects of not bundling software with WPILib is that a third party could distribute their software in such a way that would restrict third parties from redistributing it (similar to how Oracle restricts redistribution of Java binaries), in which case a project such as RobotPy would be stuck with whatever install process the third party decided to go with.

However, the nice thing about python is that there's really one good way to distribute software for python -- python packages. So if RobotPy supports it, it'll all come through the same standard install process.

[Tom Line]

As more and more suppliers service FRC, this was the next logical step for FIRST. However, I'm very concerned about the number of suppliers who will choose to not support LabVIEW at all with their code.

Unless FRC creates some way of gently nudging suppliers to supply LabVIEW code as well, I suspect that by the end of the year there will be a new answer to the question 'which language is best to use for a robot'.

[virtuald]

Originally Posted by Tom Line

As more and more suppliers service FRC, this was the next logical step for FIRST. However, I'm very concerned about the number of suppliers who will choose to not support LabVIEW at all with their code.

Unless FRC creates some way of gently nudging suppliers to supply LabVIEW code as well, I suspect that by the end of the year there will be a new answer to the question 'which language is best to use for a robot'.

Most third party providers will provide C bindings, and I've been told that LabVIEW has built-in stuff to easily interface with that. I suspect that if a piece of hardware was cool enough that an advanced team would help out the manufacturer with LabVIEW bindings (provided the third party doesn't have a restrictive license). A great example of this happening is the NavX LabVIEW bindings.

[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.

[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.