Hey everyone, I was looking at the specs on the new Arduino uno, and I was wondering if it could be a low cost replacement for a CANivore? It could still be connected to the rio via usb, and run a second CAN bus off of its CAN pins. This is an idle musing of an electronics guy who knows less than he should about programming, but if my team (which has yet to purchase a CANivore) can save $275 on an already tricky season budget, I’ll take that opportunity gladly.
1 Like
You’re probably better off using a generic USB-CAN device designed for this purpose rather than trying to write Arduino firmware that does the same thing. This would also be contingent on software support coming out to support external buses using SocketCAN devices and a rule change fully allowing non-CANivore adapters. (As R718 is written, it doesn’t disallow any other adapters the way I read it but I also wouldn’t stake my season on it.)
You need to add a transceiver to begin with.
Once you’ve done that, I would look at porting the CandleLight Firmware and leveraging the gs_usb kernel module. That firmware has been ported to quite a few widgets.
As for what you can legally do with it… read the rules carefully.
Have fun!
4 Likes
Why does this rule name a single allowed device?
Would it not be better to write the rule as specifications and include the CANivore as an example of an acceptable devices? See for example:
1 Like
Nearly all the rules written that way started with a single allowed device and over time (when comfort level rose with other similar products on the market) changed to first allow multiple specific devices and eventually specs with example devices as shown.
Motor controllers are also a constrained set of specific devices, as are MXP boards that you can hook up PWMs through. FIRST is generally very conservative with what devices are allowed in the electrical control path for actuators/motors due to the safety implications.
What would a “common” spec look like for this case? What is the testing methodology? Do multiple manufacturers sell a device that meets that spec? How would an inspector be able to easily check that the device meets the spec?
1 Like
I think the main thing you would have to demonstrate is that your controller can handle watchdog commands to disable CAN devices when the robot is disabled. That’s the main difference you run into between standard CAN and FRC CAN networks I would think (that and maybe the FRC-specific device vendor ID reservations).
I think FIRSTs primary concern about just allowing any CAN controller to be used is that someone could use one that gets around the safety restrictions (whether intentionally or otherwise), and run motors when they shouldn’t be. This is also likely why FIRST restricts motor controllers, even though there’s tons of ESCs on the market that could, theoretically be used for FRC motors.
This should be more or less irrelevant - CAN adapters would just be interfaces for the roboRIO to communicate with the CAN bus. As far as I know, they wouldn’t be sending any messages of their own accord.
And for the record, I’m not against restricting this, but I don’t think it needs to be as rigorous as it’s being made out to be. I would probably write the rule along these lines:
R718: USB to CAN adapter permitted. Additional CAN bus connections may only be added to the roboRIO using one or multiple of the following:
- CTR Electronics CANivoreTM P/N 21-678682 USB-to-CAN adapter
- Any SocketCAN-compatible device such as the REV Robotics SPARK MAX or CANable
1 Like
Have staked several seasons on it. Have also gotten into it with a couple LRIs about it.
I’m not saying FHQ can’t change their minds but it’s been made very clear to me (and those LRIs from what I understand) that the intent is to allow SocketCAN devices, provided the enable and disable (“heartbeat” - god I hate this term about as much as watchdog) signals come from the RoboRIO.
With CAN-FD, my suspicion is that CTRE has a right to claim that the only CAN-FD SocketCAN adapter that is guaranteed to work with their devices is the CANivore… and as of right now, they are the ONLY kernel module included with the RoboRIO images for that. I don’t expect that to change for this coming season.
1 Like
This is part of the issue, re: safety concerns. A USB to CAN adapter is effectively a coprocessor- it has its own microcontroller, sometimes with user-flashable firmware, and can be programmed to act of its own accord. Normally, they wouldn’t, but FIRST has no way of guaranteeing that every adapter is “safe”.
Like Marshall stated there are other technical blockers at the moment, but those are more easily solved.
1 Like
The same can be done for the STM32s and PICs in REV/CTRE devices, yet those devices are still legal.
2 Likes
Sorry, I should have been more clear. It would be trivial to add arbitrary functionality to many socketcan adapters, as there is open source firmware available for them.
Neither rev nor ctre publish firmware sources, so it’s just a little more difficult to do the same on their devices.
Sure… they could be programmed to ignore whatever… the RoboRIO can be programmed to ignore the same things… and a whole lot more.
Let’s make up a hypothetical scenario… one in which a high profile and highly resourced team decides to roll their own code to ignore the “heartbeat” (seriously, I hate this term) signals. They could MAYBE, in a best case scenario, gain a fractional second advantage to play and I’m willing to bet it would HAVE to be less than .5s and probably even closer to .2 or .3s for it to not be noticed by well… everyone.
Someone (likely a lot of someones with this crowd) will catch on and it will be so obvious that many many eyes will be on them and they would risk not just their reputation, but any ability they have to continue using the control paradigms they have invested in.
The cost to them would very likely be that they are removed from consideration of awards, that some mentors get removed from the program entirely, and maybe even more.
Look, I get it, not everyone has spent hours (days?) of their life reading data sheets, compiling kernel modules, lobbying for rule changes/updates, and losing sleep over the ability for like 2 teams to do novel things on the CANbus but some of us have and well… we want to keep those things working because it enables innovation and others are ultimately going to benefit from it in the long term.
5 Likes
not even mentioning the time delta in robots being enabled/disabled by FMS, it’d have to be outrageous for it to be noticed even by the most keen of eyes.
3 Likes
The exact details would be for FIRST HQ to decide, but I’m thinking something like “Implements Vx.x of the CAN specification”
By being on an approved list list motors & controllers and so on (from FIRST HQ testing).
Here’s my thinking. For FIRST to thrive there needs to be a robust set of manufacturers supplying the parts eco-system. Having a rule specify exactly 1 implementation of something damages that eco-system (IMO) by discouraging others from making that part.
I see two scenarios that I think are more likely:
-
(On the intentionally deceptive side of things) Say there’s a game like 2022 where you have a lot of robots with flywheel shooters, rather than giving yourself an advantage at the beginning of a match prior to the countdown, you could wait for autonomous to end and during the brief disabled period, use a user-flashed CAN controller to make sure your flywheel motor keeps running at a set speed so it’s ready to go right when teleop starts. Depending on the game, this could be a huge advantage and could be quite difficult to detect (since you could just claim the motion was due to residual speed in the flywheel and that it was slowing down but not enough to tell), then you just make sure the motor/controller lights can’t be seen from outside the field and no one would be able to tell.
-
(On the unintentional side) A team could potentially do something to a CAN controller unintentionally (or buy one that has the functionality built in without knowing), where the controller sends the last signal transmitted after being disabled, potentially resulting in out-of-control robots and the inability to e-stop them. While I admit I don’t know how realistic this is on a CAN network, it’s definitely something you see in RC-type electronics (even FRCFIRST Robotics Competition had this problem years back where watchdog errors could cause robots to run into walls and such even after being disabled). Hard to know how likely this is, but it seems like something that could be possible.
To be honest, I think this is probably the best solution in this particular case, rather than having a broad rule that allows any “comparable” device, I would much rather just have FIRST streamline the device approval process to allow for more options, and make it easier for new entrants into the market for FRCFIRST Robotics Competition teams. As it is, even the process to get a device approved is pretty vague (from what I’ve heard, new vendors basically have to contact FIRST by email and hope they get a reply, and approval criteria are not always made clear), a more streamlined, published process would help alleviate a lot of issues like this and potentially open up a lot more options for teams.
So this happens in a match… there will be an FTAFIRST Technical Advisor that reports it. There will be questions from spectators and CSAs. It’s not going to happen and be ignored.
The one match where our robot drove in circles at the end of the match because of a (reported) issue due to CAN on a Jaguar with the 2014 beta testing was reported and I had to account for why I jumped the field border to disable the robot. It was a bug… it’s been fixed since… it was terrifying. I don’t take this lightly.
Then all you are doing is spreading FUD. I love you man… but like, that’s all you are doing. Just like a lot of others who keep pretending they’ve done the research and know how this stuff works. Just stop posts questioning it. Better yet… POCorGTFO.
Look… I get it… there is so much uncertainty because this stuff is a black box because of various groups that keep making it seem like it is is magic. It isn’t. It’s safe. It’s remarkably safe. Don’t inherently distrust it.
On this, we agree.
3 Likes
To answer the original question, the answer is no, the R4 cannot be a replacement for a CANivore, but for a 100% technical reason rather then rules. From what I can tell, the CAN on the R4 is not CAN-FD, which is what CANivore uses (This is why it only works with falcons and pigeon 2’s, and no other existing hardware). In fact on the market, very few other USB to CAN-FD adapters exist, and the ones that do all seem to use proprietary drivers (If there is one feel free to correct me).
The CAN 2.0 vs CAN-FD split in the FRC ecosystem is one of the things that will make adopting new setups harder. We have a mix of HW that doesn’t support FD and would destroy the bus with can errors (iirc this is all the 2015 era CTRE HW and the Spark Max), HW that supports FD but still communicates over 2.0 (iirc the new REV HW), and HW that communicates over FD (Falcon, Pigeon and cancoder). I think to teams, once more adapters start coming out and being legal, the differences here will be a lot more confusing. Theres also the fact there’s a distinct possibility some vendors wouldn’t support all adapters. The confusion here is what worries me more about external adapters.
In my opinion, the rules part of using other can adapters should be fairly easy to solve, and I don’t see any issue with actually allowing more adapters. But as a CSA it terrifies me slightly, as its very possible for wrong protocol devices to be hooked between buses and cause absolute havoc. As well as the possibility for teams to hook the buses together, like we’ve seen a few times with teams putting the CANivore on the roboRIO bus, and either cause chaos, or completely negate the advantages of doing a 2nd bus.
4 Likes
The rule specifies exactly 1 implementation because only one currently exists. If another vendor offers an equivalent implementation and FIRST accepts it, it will be added to the rules. As I pointed out, many rules have gone through this evolution over a multi-year period: for example, the rules used to specify just 1 particular battery model was allowed, then it allowed 2 different battery models, now it’s a generic rule allowing any battery that meets a certain spec.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.