Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   [FRC Blog] Control System Update (http://www.chiefdelphi.com/forums/showthread.php?t=151873)

bdaroz 13-10-2016 17:44
[FRC Blog] Control System Update
 
From http://www.firstinspires.org/robotic...-system-update

Quote:
Written by Kevin O'Connor, Robotics Engineer, FIRST Robotics Competition.


FIRST and our FRC Control System team have spent the summer improving the FRC Control System. Information about some of those changes, as well as the announcement of the 2017 season beta test teams who will help us validate those changes, is in this blog. We are also working on information about device legality, but we’re not quite ready to share that yet, so stay tuned.

Device Libraries

This season we are making a change to WPILib (for all 3 software languages) where third party software for items not in the Kickoff KOP will be provided separately by that third party.

Since the CMUCam (and perhaps earlier), companies have provided powerful sensors and controllers to FRC teams. We encourage the development of these devices as they help raise the ceiling for teams and enable them to create incredible autonomous and semi-autonomous robot routines. In the past few years, the number of these devices has increased more rapidly (which is good!), but it comes with difficulties. Integrating software for these devices into WPILib requires a substantial amount of work from the device manufacturer and the FRC Control System team, and, we acknowledge that the status quo is not sustainable. As a result, we’ve implemented a solution that is more sustainable for the CS Team and removes some of the headache for vendors to develop and test their products.

Going forward, WPILib will not include direct support for many of these sophisticated devices (including CAN Jaguar and CAN Talon SRX). Instead, it allows the integration of 3rd party code into teams’ WPILib programs. Suppliers provide installers which place their libraries into the correct location on the user’s system. WPILib tools will automatically detect the libraries and allow them to be used in FRC programs. FRC will create a “one-stop-shop” page for these installers to help teams easily locate the software for their selected devices.

We acknowledge that this is a compromise; teams will take additional steps to get and install libraries, but WPILib development is more sustainable and there’s a clearer implementation and ownership path for 3rd parties.

The 2017 Beta Test teams will test this change and provide feedback on how to make the experience as smooth as possible.

Robot Radio

In June, we blogged that we would be introducing a new radio for the 2017 season, and can do so now. The new radio for the 2017 season is the OpenMesh OM5P-AC. The OpenMesh OM5P-AN will continue to be competition legal, provided it has updated 2017 firmware. In order to comply with FCC regulations, the FRC firmware for the OM5P-AC and OM5P-AN disables the web interface and SSH access. You will only be able to configure the settings on the device using the FRC Radio Configuration Utility. Meanwhile, we will add flexibility to that tool to cover as many use cases as possible.

The OM5P-AC is available from Open Mesh and will soon be available from AndyMark. See those sites for pricing and availability. Devices won’t be usable until the firmware and configuration utility are available to teams. Worst case, they’ll be posted on Kickoff Day, and if we can publish sooner, we will announce via this blog.

Beta Testing

The 2017 Beta Test teams have been selected! Thank you to everyone to applied. Teams were selected on the basis of location, past Beta performance, Beta application history, and submitted essay.

Selected teams will help the FRC Control System team test changes to the software libraries and any new hardware FIRST decides to test. Beta teams pledge to share their learnings and findings with the community, especially teams in their area, so make sure to reach out with any questions you may have for them via the FIRST Forums and keep your eyes peeled for any “Open House” or training seminar events in your area.

We are grateful to this group for giving our systems a test run before the season, and we thank them for helping us find and fix any issues before we deploy to the entire FRC community!

Ed: List of teams removed

AllenGregoryIV 13-10-2016 18:46
Re: [FRC Blog] Control System Update
 
That all seems like good news to me. I like the device libraries, they should make it easier to import libraries like the NavX library, etc.

bdaroz 13-10-2016 19:00
Re: [FRC Blog] Control System Update
 
I'm just hoping that they move to a more standard library distribution / installation method (eg maven).

Dominick Ferone 13-10-2016 19:21
Re: [FRC Blog] Control System Update
 
The only problem i have with these routers, is they only have 2 ports. When at competition we couldn't tether in and view the camera at the same time. One port had tether and the other has the rio then.

AllenGregoryIV 13-10-2016 19:36
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Dominick Ferone (Post 1611703)
The only problem i have with these routers, is they only have 2 ports. When at competition we couldn't tether in and view the camera at the same time. One port had tether and the other has the rio then.
Can't you just tether with the USB cable? You can also just add a small network switch to the robot.

adciv 13-10-2016 19:43
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Dominick Ferone (Post 1611703)
The only problem i have with these routers, is they only have 2 ports. When at competition we couldn't tether in and view the camera at the same time. One port had tether and the other has the rio then.
We acquired a 5 port 5v ethernet switch. Worked great.

frcguy 13-10-2016 20:26
Quote:
Originally Posted by AllenGregoryIV (Post 1611705)
Can't you just tether with the USB cable? You can also just add a small network switch to the robot.


+1. We only used one Ethernet port and we still tethered over USB exclusively this season. And if you must tether over Ethernet, you can get an inexpensive switch that will run on 5v.

Mark McLeod 13-10-2016 20:28
Re: [FRC Blog] Control System Update
 
The switch doesn't have to be on-board either.
It can just be used in the pit to connect the camera and tether to the bridge.

bobbysq 13-10-2016 20:29
Re: [FRC Blog] Control System Update
 
It's good that they disabled the web interface on the FRC firmware. Hopefully the router won't have insane boot times anymore.

(I was really hoping for them to commission an FRC-specific router though, with screw terminals for power and at least 4 ports)

feverittm 13-10-2016 21:08
Re: [FRC Blog] Control System Update
 
Looking at the spec at the OpenMesh website it looks like this radio uses 24V. Is this correct? If so we will need a source of regulated 24V to power the radio.

What is others opinions?

Hitchhiker 42 13-10-2016 21:18
Re: [FRC Blog] Control System Update
 
I'm slightly disappointed with the radio choice, but the other things sound very good to me. Anyways, yay for improvements.

Mark McLeod 13-10-2016 21:22
Re: [FRC Blog] Control System Update
 
2 Attachment(s)
Quote:
Originally Posted by feverittm (Post 1611713)
Looking at the spec at the OpenMesh website it looks like this radio uses 24V. Is this correct? If so we will need a source of regulated 24V to power the radio.
Look at the picture of the specs on the bottom of the unit.
http://www.open-mesh.com/products/ac...ess-point.html
It takes DC Input: 12v-24v/1A

Added spec comparison between the old and the new models.

feverittm 13-10-2016 21:29
Re: [FRC Blog] Control System Update
 
My bad...

I can see where I got confused. The picture shows 18-24V on the back of the router while the actual datasheets says 12-24. Looks like we are good.

Thanks

Bkeeneykid 13-10-2016 22:19
Re: [FRC Blog] Control System Update
 
Since this is the upgraded model of the OM5P-AN, does this come with any upgraded stats like improved range or more throughput (not like that second one matters to FRC, but just curious)?

EDIT: Did some searching and found my own answer: https://help.cloudtrax.com/hc/en-us/...AN-and-OM5P-AC

It looks like the AC has better throughput, both ports are now gigabit, upgraded processor and DRAM (faster boot times? :D), but at the cost of reduced range. I think we might prefer our AN over the AC just because of the range.

ollien 13-10-2016 22:23
Re: [FRC Blog] Control System Update
 
Not psyched about the WPILib changes, but it is what it is. I understand the sentiment behind it, but CANJaguar and CANTalon just seem like two hugely integral classes to remove.

What's done is done, I guess. I suppose I'm more not psyched to be debugging build path errors than anything. (Though, in theory, and not reality, those shouldn't happen.)

ollien 13-10-2016 22:27
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Bkeeneykid (Post 1611728)
Since this is the upgraded model of the OM5P-AN, does this come with any upgraded stats like improved range or more throughput (not like that second one matters to FRC, but just curious)?
Or, hopefully, faster bootup/a better power connector? A boy can dream.

SoftwareBug2.0 14-10-2016 02:56
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by ollien (Post 1611729)
Not psyched about the WPILib changes, but it is what it is. I understand the sentiment behind it, but CANJaguar and CANTalon just seem like two hugely integral classes to remove.

What's done is done, I guess. I suppose I'm more not psyched to be debugging build path errors than anything. (Though, in theory, and not reality, those shouldn't happen.)
Perfection is less about effort or skill than it is about having a clear and limited goals. If this is a sign that the WPIlib authors are looking to reduce scope then I'm happy because it means that their efforts can be more focused on fixing their existing problems. If it turns out instead that they've taken this as a chance to implement some crazy plugin architecture I will be less pleased.

fsilberberg 14-10-2016 03:29
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by bdaroz (Post 1611700)
I'm just hoping that they move to a more standard library distribution / installation method (eg maven).
We actually already do this, and this was available last year. It's documented on ScreenStepsLive here: http://wpilib.screenstepslive.com/s/...aven-artifacts. There will be some updates to artifacts available in 2017, detailed in my design doc here: https://github.com/wpilibsuite/desig...eneration.adoc. The gist of it is that we'll be using real version numbers, and using 2 maven repos instead of 4, one for public releases and one for WPILib developers (although technically, there's nothing stopping you from using it). In fact, GradleRIO (https://github.com/Open-RIO/GradleRIO) already used the repo last year.

calcmogul 14-10-2016 03:32
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by SoftwareBug2.0 (Post 1611744)
If this is a sign that the WPIlib authors are looking to reduce scope then I'm happy because it means that their efforts can be more focused on fixing their existing problems. If it turns out instead that they've taken this as a chance to implement some crazy plugin architecture I will be less pleased.
The CAN motor controllers are a big maintenance burden for us. At least in C++, the CANTalon code is 5.5k lines of code spread over two classes (we use a PIMPL pattern). Half of this is a class we can't touch since it comes directly from CTRE, but we have to maintain testing infrastructure for it. Moving CANTalon out of WPILib gives CTRE more control over testing/QA and gives them more freedom to add features / do bugfix releases independent of the WPILib release schedule.

CANJaguar is basically a giant, ugly, 10k-line ball of code that we are hesitant to touch. Few teams use it, so we can't justify cleaning it up, and teams still use it, so we can't just drop support. We're supporting it for 2017 as a third party library, but we're probably going to stop maintenance in 2018.

Jaci 14-10-2016 06:47
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by fsilberberg (Post 1611745)
[snip] In fact, GradleRIO (https://github.com/Open-RIO/GradleRIO) already used the repo last year.
If you want implementation details, see the WPIProvider class. The first two dependencies (L34-35) are the RoboRIO and desktop versions of NetworkTables (since we do simulation we include the desktop version, but if you're only doing RoboRIO development you dont need this). The next dependency (L37) is WPILib itself (in this case, the Java version). The next 2 dependencies (L39-40) are the source jars for WPILib and Network Tables, which we attach to IDEs like IntelliJ and Eclipse so you can browse the source directly without the inbuilt decompiler.

Jaci 14-10-2016 06:59
Re: [FRC Blog] Control System Update
 
I'm a fan of the separation of device libraries. For specifically large libraries (like the CAN motor controllers), the omission of these from the 'standard library' should result in smaller binary sizes and (at least on Java, not sure about C++ just yet), less RAM usage.

For the 'plugin system', I hope that this support comes in the form of compile-time library additions. For C++, I'm hopeful that library providers will include either the source, or both a shared and static version of their native library. For java the plugin system should be fairly trivial assuming JNI is done fine.

I'll try and contact some beta-test teams and keep an eye on the WPI repo to try and get OpenRIO's existing and new libraries up and running for the 2017 season, as unfortunately I don't have access to beta-testing stuff directly.

maxnz 14-10-2016 08:21
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Bkeeneykid (Post 1611728)
It looks like the AC has better throughput, both ports are now gigabit, upgraded processor and DRAM (faster boot times? :D), but at the cost of reduced range. I think we might prefer our AN over the AC just because of the range.
Out of curiosity, how do the old d-links compare to the new radios in terms of range?

marshall 14-10-2016 08:45
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by ollien (Post 1611729)
Not psyched about the WPILib changes, but it is what it is. I understand the sentiment behind it, but CANJaguar and CANTalon just seem like two hugely integral classes to remove.

What's done is done, I guess. I suppose I'm more not psyched to be debugging build path errors than anything. (Though, in theory, and not reality, those shouldn't happen.)
I think it is probably a good change given that we've seen it take quite a while to get new features into WPILib from when a manufacturer introduces them. As a LabVIEW beta team, it always seem to take a while before we could be using the latest features.

That being said, I'm worried a bit that some vendors are going to prefer developing in one language over another and therefore some teams aren't going to get access to the latest code/firmware/features because of it. I hope this doesn't happen but it is a possibility with moving the development and maintenance to 3rd parties.

bobbysq 14-10-2016 09:14
Re: [FRC Blog] Control System Update
 
1 Attachment(s)
Quote:
Originally Posted by ollien (Post 1611730)
Or, hopefully, faster bootup/a better power connector? A boy can dream.
I agree. The attached picture is using the power cable included in the kit of parts.

bdaroz 14-10-2016 09:20
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by fsilberberg (Post 1611745)
We actually already do this, and this was available last year. It's documented on ScreenStepsLive here: http://wpilib.screenstepslive.com/s/...aven-artifacts. There will be some updates to artifacts available in 2017, detailed in my design doc here: https://github.com/wpilibsuite/desig...eneration.adoc. The gist of it is that we'll be using real version numbers, and using 2 maven repos instead of 4, one for public releases and one for WPILib developers (although technically, there's nothing stopping you from using it). In fact, GradleRIO (https://github.com/Open-RIO/GradleRIO) already used the repo last year.
We saw that, however we've sworn off Eclipse this year for IntelliJ Idea for our Java development. The student's weren't quite ready for a Gradle build so the hoops we had to go through to continue to support the ANT build/deploy for 2016 code were a bit much.

Code:
    <target name="doInstall" depends="wpilib.check" unless="wpilib.exists">
        <mkdir dir="${wpilib}"/>
        <get src="http://first.wpi.edu/FRC/roborio/release/eclipse/plugins/edu.wpi.first.wpilib.plugins.java_0.1.0.201603020231.jar"
            dest="${wpilib}/plugin.jar"/>
        <unzip src="${wpilib}/plugin.jar" dest="${wpilib}">
            <patternset>
                <include name="resources/java.zip"/>
            </patternset>
            <mapper type="flatten"/>
        </unzip>
        <delete file="${wpilib}/plugin.jar" />
        <unzip src="${wpilib}/java.zip" dest="${wpilib}"/>
        <delete file="${wpilib}/java.zip" />
    </target>
We're hoping for a smoother 2017 code build/deploy cycle that's a bit more platform/IDE independent. (And yes, we're a looking at GradleRIO once we finish our off season. :) )

adciv 14-10-2016 09:51
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by marshall (Post 1611752)
I think it is probably a good change given that we've seen it take quite a while to get new features into WPILib from when a manufacturer introduces them. As a LabVIEW beta team, it always seem to take a while before we could be using the latest features.

That being said, I'm worried a bit that some vendors are going to prefer developing in one language over another and therefore some teams aren't going to get access to the latest code/firmware/features because of it. I hope this doesn't happen but it is a possibility with moving the development and maintenance to 3rd parties.
Labview has the capability of importing C libraries (Call Library Function Node) and C code (LabWindows). That would make it easier in some respects.

Chris is me 14-10-2016 12:18
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by frcguy (Post 1611708)
+1. We only used one Ethernet port and we still tethered over USB exclusively this season. And if you must tether over Ethernet, you can get an inexpensive switch that will run on 5v.
The big problem is that the USB spec limits the length of most USB cables to shorter lengths than Ethernet. Ethernet is designed to be used over longer distances than USB. In practice you're probably fine either way, but Ethernet is what we "should" be using IMO

bobbysq 14-10-2016 12:30
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Chris is me (Post 1611779)
The big problem is that the USB spec limits the length of most USB cables to shorter lengths than Ethernet. Ethernet is designed to be used over longer distances than USB. In practice you're probably fine either way, but Ethernet is what we "should" be using IMO
Also, I don't believe you get full access to the robot's LAN when using USB. This is important if you used vision tracking with an external processor like us this year.

frcguy 14-10-2016 12:31
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Chris is me (Post 1611779)
The big problem is that the USB spec limits the length of most USB cables to shorter lengths than Ethernet. Ethernet is designed to be used over longer distances than USB. In practice you're probably fine either way, but Ethernet is what we "should" be using IMO
Yep, I agree that Ethernet is the ideal tethering method. For us however, tethering was limited to just testing things in either our pit or in queue, and we didn't need the longer distance that Ethernet can handle. If we needed to test on the practice field or some other long distance tether we had a long Ethernet cable ready.

Quote:
Originally Posted by bobbysq (Post 1611782)
Also, I don't believe you get full access to the robot's LAN when using USB. This is important if you used vision tracking with an external processor like us this year.
This is correct as well, although we didn't have issues with that this season (low goal robot :D).

adciv 14-10-2016 12:43
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by frcguy (Post 1611783)
This is correct as well, although we didn't have issues with that this season (low goal robot :D).
We were too...we still used vision in Auto. So nice to have a target right above your goal.

Philip Arola 14-10-2016 15:21
Re: [FRC Blog] Control System Update
 
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 15-10-2016 00:44
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Philip Arola (Post 1611811)
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 15-10-2016 01:28
Re: [FRC Blog] Control System Update
 
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 15-10-2016 08:35
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Tom Line (Post 1611879)
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 15-10-2016 10:55
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Tom Line (Post 1611879)
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 15-10-2016 11:27
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by cgmv123 (Post 1611897)
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 15-10-2016 12:53
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Jaci (Post 1611900)
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 15-10-2016 13:14
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by marshall (Post 1611902)
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 15-10-2016 15:05
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Jaci (Post 1611900)
"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 15-10-2016 18:34
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by bobbysq (Post 1611919)
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 17-10-2016 12:45
Re: [FRC Blog] Control System Update
 
I have a feeling this means team libraries will be expanding.

JR0405 17-10-2016 14:03
Re: [FRC Blog] Control System Update
 
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 17-10-2016 14:09
Re: [FRC Blog] Control System Update
 
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 17-10-2016 14:13
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by JR0405 (Post 1612159)
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 17-10-2016 14:33
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by cgmv123 (Post 1611897)
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 17-10-2016 15:01
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by Caleb Sykes (Post 1612166)
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 17-10-2016 15:56
Re: [FRC Blog] Control System Update
 
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.

Caleb Sykes 17-10-2016 15:58
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by virtuald (Post 1612175)
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.
I understand that, my point is that I think it is really cool that different teams use different languages, just like teams build their robots out of different materials. As a corollary, I've seen some really cool robots that are made nearly completely out of wood. If a team wants to make their robot out of wood, that is just fine, but they shouldn't try to mandate that no one use aluminum.

We program in Java, if I see a cool sensor out there that is only supported by Python, my first thought should either be:
Is it worth it to switch our programming language to Python in order to use this sensor?
Or
Can we somehow get this sensor to work with our existing programming language?
Not
Can we somehow ban this sensor so that no other team can use it?

adciv 17-10-2016 16:11
Re: [FRC Blog] Control System Update
 
Just a thought, but we have a Linux OS on the roboRIO which we have root access to. We can use this to our mutual advantage. POSIX interprocess communication from a sensor plug-in to C++/Java/LabView?

scca229 17-10-2016 18:26
Re: [FRC Blog] Control System Update
 
Quote:
Originally Posted by adciv (Post 1612161)
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 :yikes: 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 18-10-2016 07:39
Re: [FRC Blog] Control System Update
 
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.


All times are GMT -5. The time now is 11:12.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi