Good afternoon. During our last local, Non FRC competition few teams suspected a malicious jamming attack directed at the to jeopardize their performance.
This local championship does not follow frc regulation.
Is there any way to bypass the requirement of WPIlib based robot code to be continuously connected to a driver station on team’s PC?
Is there any way to make robot independent of competitors PC and able to perform autonomous comands the moment robot code done deploying?
It is specifically designed to prevent that, for very good reason.
Yes. Buy LabVIEW and the FPGA module (or don’t, if you only need CAN), and write your own HAL, frameworks, and application software.
Well there’s your problem.
And what would it be? That part always confused me
So, there’s no straightforward way built in WPI Lib, Like method or something?
No.
Because we don’t want 140 lb machines with several kilowatts of motor power to go out of control and hurt someone. If a robot could operate without being in communication with a driver station, there would be no way of remotely e-stopping it.
No. Again, very intentionally.
Oh, i see. We’ve newer used anything remotely this powerful in our local competition (18 Lb tops with motors a couple hundred watts).
Thank you for your time!
Well, we utilized this proof of concept to operate an off-season cornhole launching arm without a driver station:
It’s absolutely possible to enable and run a Rio without a driver station in non-FRC contexts using WPIlib.
Yes, this and other ways to can bypass the driver station control.
To others reading this thread:
The main issue, which has been brought up and needs to not get lost into the weeds for anyone new who comes past here: it also bypasses the estop mechanism .
Ask yourself: where else in life is it acceptable to bypass a safety mechanism like an estop?
Okay, so besides the technical points others are mentioning I’m trying to understand what exactly is meant by this section.
You went to an off-season event that wasn’t following FRC regulations and had a custom field management system?
The accusation is that custom system allowed some teams to jam wireless communications for other teams?
And you’re seeking ways to have the robot work outside of their FMS system to operate even when there’s a network loss?
Exactly that
There’s a few parts that make this difficult.
the custom FMS is something outside of your control so you can’t do anything about how it is operating right now at the event. I would ask the event volunteers for more information about the FMS to help narrow down where it came from, not in an accusatory way. But because you genuinely want to know more about how that FMS works compared to the official one. Maybe there are other FMS systems they could adopt for the future that will not allow this.
You don’t know if this is intentional or accidental or if it’s truly the cause of the issues. We didn’t get a description of the symptoms that make you think it’s a network loss/jamming issue. Did several robots experience disconnects? Did these happen only during auto or during teleop as well? More information about what happened in a specific instance would help.
If you start operating outside of their FMS system how will you know to start autonomous or switch to Teleop controls at the correct time? That’s how all of the robots stay in sync and have the correct timing and field information. I can understand that Auton stopping because of a network loss seems silly, but Auton is when the worst things can happen. During Teleop you can usually just stop a motor with a control. Auton unless you have the new A-Stop (part of FMS), there is no way to disable it or affect how it operates if there’s an error. Errors could be something as simple as the Gyro/IMU disconnected or mounted upside down and the robot begins to turn in place at full speed with no way to stop it now. You can’t hit the breaker because the robot is moving and FRC doesn’t have an E-Stop on the physical robots. The only way to stop it is through FMS communication or DS communication as @CarlosGJ mentioned.
I think emotions run high at competitions and disappointed students and teams will look for issues to point to. I don’t know enough about the event this happened at so I’m making guesses at best. Definitely seek more information with an open mind and try to help remediate the issue for others as well. Your current path will isolate you from the rest of the teams at the event who might also be dealing with the same problems. If their is an issue with the FMS it’s not just your team suffering and fixing it rather than working around it would help everyone.
Answer for yourself: Nowhere.
Yourself will thank you later. Probably with all of your limbs and digits still intact.
Maybe this was lost in the mix, it sounds like the robots (?) are quite small, smaller than FTC, which to my knowledge has no EStop.
It is small. It’s VMX-pi based robot for local (as in a small country “local”) competition. And there’s no significant chance of serious injury and all contestants are required to have easily accessible emergency stop button on their robots.
The question was left open ended on purpose.
If I only get one word, this is my conservative answer:
If I get more words: When you’ve properly mitigated the risks the estop was intended to cover.
IE - remove the power source, put in an alternate mechanism that works the same, or change the situation.
Sounds like you’ve analyzed and mitigated the risk. Beautiful.
Engineer away!
I didn’t see anyone mention the log files produced by the driver station. If you are using the official driver station application, it saves logs about robot and communications onto the PC running the DS. The difference between jamming and bad wifi and programming issues is not easy to identify by just watching robots.
The DS Gear icon along the top includes a log file viewer that shows this information for every time that the robot was connected and the DS was running. You might want to look at the logs in order to understand what was happening at that tournament or to prevent it at future tournaments.