[FRC Blog] Control System Update

[Bkeeneykid]

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? ), but at the cost of reduced range. I think we might prefer our AN over the AC just because of the range.

[ollien]

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

[SoftwareBug2.0]

Originally Posted by ollien

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.

[calcmogul]

Originally Posted by SoftwareBug2.0

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.

[marshall]

Originally Posted by ollien

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.

[adciv]

Originally Posted by marshall

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.

[ollien]

Originally Posted by Bkeeneykid

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.

[bobbysq]

Originally Posted by ollien

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.

[maxnz]

Originally Posted by Bkeeneykid

It looks like the AC has better throughput, both ports are now gigabit, upgraded processor and DRAM (faster boot times? ), 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?