Just noticed on the product page for the VMX Robotics Controller it says “This is FIRST legal”.
Is that true?
As a co-processor, sure. It cannot be used as a replacement for the RoboRio, however, and can not be used to control any actuators directly.
4 Likes
I thought the rules merely stated that motors / motor controllers must be instanstiated by the Rio and you can’t override it’s CAN communications for safety with no explicit ban on driving motors from another device given the Rio can still kill them with an e-stop as follow commands for example actually set motor controllers to directly drive each other without the Rio. As far as I’m aware nothing stops you from adding another device to the network and interfacing and controlling motors but please correct me if I’m mistaken.
1 Like
It’s also absolutely not legal for FTC in any capacity, at least under current season rules.
I suggest you review R712-R715.
R714 *Control CANController Area Network motor controllers from the roboRIO. Each CANController Area Network motor controller must be controlled with signal inputs sourced from the roboRIO and passed via either a PWMPulse Width Modulation (wired per R713) or CANController Area Network bus (either directly or daisy-chained via another CANController Area Network bus device) signal, but both shall not be wired simultaneously on the same device.
1 Like
As long as the CANController Area Network bus is wired legally so that the heartbeat from the roboRIO is
maintained, all closed loop control features of the CANController Area Network motor controller may be
used. (That is, commands originating from the roboRIO to configure, enable, and
specify an operating point for all CANController Area Network motor controller closed loop modes fit the
intent of R701).
“Wired directly” includes via any series of PASSIVE CONDUCTORS (i.e. star or
hub configurations using only PASSIVE CONDUCTORS are permitted.)
Given the heartbeat is maintained, the ID is set by the Rio, and the motor is enabled by the Rio this doesn’t seem to exclude controlling them through another device given that R717 is followed it does not appear to be illegal to add additional messages to the CANController Area Network bus directed at motor controllers.
1 Like
There’s a big difference between closed loop controls inherent to the controller and controls coming from a completely separate unit… it specifies operating points originating from the RoboRio, which would not be the case if this other device were providing those iperating points.
wouldn’t that put TalonSRX, TalonFX, Spark MAX, & Venom motor controllers all in violation of this rule, they all directly send messages to control their followers on the CAN bus without the Rio intervening which may sound like it originates from the Rio anyways since its a duplicate command but for PID controllers for example the motor controller on its own calculates an output & then sends that on to another controller, therefore controlling a motor with a signal that in no way originates from the Rio.
This would also constitute that a CANivore is illegal correct?
CANivore have explicit legality stated in R718
*USB to CANController Area Network adapter permitted. Additional CANController Area Network bus connections may be added to the roboRIO
using the CTR Electronics CANivoreTM P/N 21-678682 USB-to-CANController Area Network adapter.
Any additional CANController Area Network bus added in this manner satisfies the requirements of R714
(i.e. you may connect motor controllers to this additional bus)
Note this also allows them to do things that a theoretical coprocessor on the CANController Area Network network definitely can’t such as actually creating motors and setting their IDs
Doesn’t team 900 control their motor controllers from a Jetson? They started doing so after “specify all operating points” was removed from the blue box of R701 in between 2018 and 2019.
I believe that the language in R714 requires the RoboRIO to control CAN motor controllers but does not require the RIO to exclusively control CAN motor controllers.
1 Like
Those operating points still originate from the RoboRio and utilize built-in closed loop control integral to an explicitly legal motor controller. Given the explicit legality of the controllers (see R503), I don’t think teams need to worry about followers and this rule.
Based on team 900s whitepaper using ROS on a jetson they do explicitly state that both the Rio and Jetson control the motor controllers.
The Jetson was connected to the CANController Area Network bus along with the roboRIO. CANController Area Network-based devices
are, as much as possible, controlled by the Jetson. So the Jetson currently reads and
writes to Talons, and reads PDPCTRE's Power Distribution Panel and PCMPneumatics Control Module states. PCMPneumatics Control Module (solenoid) writes still happen
from the roboRIO due to limitations imposed by the current WPIlib CANController Area Network framing for that
device.
I can’t speak to their setup - I’ve only ever inspected one of their robots once, in 2015, and it did not have a co-processor on it. I don’t think R701 invalidates the limits placed by R712-R715.
There is another legality issue with the VMX-Pi in season other than as a coprocessor with onboard nav-x (v1.0).
IMPORTANT NOTE : VMX-pi is currently supported on WPILib version 2020. Even if you currently have a different version of VSCode/WPILib installed, you will need to install the compatible version as described below. Each installed version of WPILib includes a unique installation of VSCode, and multiple versions of VSCode/WPILib can be installed (“side-by-side”) on a single computer. Therefore, you should not need to uninstall other versions of VSCode/WPILib to work with VMX-pi.
So, even if it were allowed, I think the competing software versions would be problematic.
This page is helpful at describing the intended use cases.
https://pdocs.kauailabs.com/vmx-pi/software/vmx-pi-for-frc-2020-robot-programming/
Not really an issue, just manually deploy your code in a linux aarch64 environment, even if it’s not officially supported by the VMX-Pi setting up robot code on a pi isn’t much work, there’s nothing unique about WPILib, it’s a few gradle scripts you just don’t have guaranteed support and will need to figure out a few minor issues on your own.
1 Like
This could be really helpful. We have two VMX-Pis, but have not used them for a while because of this fact. We need them to learn to use all of the features that have been introduced since 2020 (Kinematics etc). We are also using a linux box (Well, really a chromebook running a tweaked version of Ubuntu) for some of our programming.
If you need any help setting up wpilib 2023 on them just ask I’d be more than happy to help out.
1 Like
Let me add some clarity.
The operation of our motor controllers (all Falcons at present) comes from our Jetson but the heartbeat signals come from the RoboRIO, just like all FRCFIRST Robotics Competition robots. We also read our PDHREV's Power Distribution Hub from the Jetson, though the RIO can read it as well, just like all FRCFIRST Robotics Competition robots (that use a PDHREV's Power Distribution Hub, we can also do it with a PDPCTRE's Power Distribution Panel).
Hope that helps.
Edit:
The blue box for R701 stipulates (with some emphasis added by me):
There are no rules that prohibit co-processors, provided commands originate from the roboRIO to enable and disable all power regulating devices. This includes motor controllers legally wired to the CANController Area Network bus.
One more Edit:
Blue box for R714, again with emphasis added:
As long as the CANController Area Network bus is wired legally so that the heartbeat from the roboRIO is maintained, all closed loop control features of the CANController Area Network motor controller may be used. (That is, commands originating from the roboRIO to configure, enable, and specify an operating point for all CANController Area Network motor controller closed loop modes fit the intent of R701).
2 Likes
Let me add emphasis for the R714 blue box…
As long as the CANController Area Network bus is wired legally so that the heartbeat from the roboRIO is maintained , all closed loop control features of the CANController Area Network motor controller may be used. (That is, commands originating from the roboRIO to configure, enable, and specify an operating point for all CANController Area Network motor controller closed loop modes fit the intent of R701).
If the command specifying an operating point does not originate from the RoboRio, then this rule and blue box would seem to have a problem, at least that’s how I read it. I don’t think you can ignore the latter part of the box just by emphasizing the former part.
I don’t know what the GDCGame Design Committee intends for this sort of scenario, but I think the rules are not clear that this is legal. It would be worth a Q&A if it was still accepting questions.