Chief Delphi
Page 2 of 4 < 1 2 34 >
Show 100 post(s) from this thread on one page

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)

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.


All times are GMT -5. The time now is 11:12.
Page 2 of 4 < 1 2 34 >
Show 100 post(s) from this thread on one page

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