The Future of Onboard Realtime Communications

Certainly. We’ve got our CAN connectors of choice, and I think they work very well, but no connector will save you if the wire shears. As for other topologies, I’d like to do some testing on my own as I mentioned to try and figure out what’s viable.

So based on the changes between that file and the original RoboRIO’s and the commit message separating “artemis” from “ARM”… We’re getting SDIO motor controllers?

I suspect that “Artemis” is a preproduction name for the roboRIO II, just as “Athena” was for the original.

1 Like

Sure, though the original doesn’t seem to have any distinction from NI’s other products using a Zynq processor (see line 6 here) while the 2.0 has its own thing in its file. Realistically, I assume it’s just a technicality that makes them need to be different regarding the internal storage.

btw if this means what i think it means pls include a preimaged card in the kop every year so we don’t have to do it ourselves thx

1 Like

By using a bus topology that doesn’t route the “trunk” of the bus all around the robot, a sheared wire will only cost you the speed controller it attaches to rather than your who CAN bus.

That’s definitely an option, and I guess I forgot to mention that this isn’t a problem we’ve run into yet, and likely won’t until we build up our brushless supply more and move toward only using it. I’m not even sure if we’ll ever need to deploy any sort of workaround. My original point was that I wished we had a standard available that didn’t need teams to mess around with topology stuff to prevent potential issues. I’m not trying to discredit CAN as a standard now despite its flaws, there’s just no point in doing that. It’s here to stay, and one guy’s “but sometimes” argument on a forum the people who choose the standards barely look at isn’t going to change that. All I’m saying is that in hindsight, some more options would have been nice to have in terms of hooking up smart motor controllers.

1 Like

I’m surprised to see so many supports of RJ45-based standards when it’s so bulky. Devices like the CANifier or CANcoder would be much more difficult to implement without locking the user into an auxiliary interface like a 10-pin data port. Not to mention the need for Ethernet switches.
Multiple CAN busses has my vote. Easy to implement with modern microcontrollers, and maintains support for old devices.

3 Likes

First, let me be pedantic: you don’t actually mean RJ45. Hardly anything uses RJ45 anymore. What you mean is 8P8C.

Second, 8P8C connectors have 8 conductors (not 10), but all 8 are only required for gigabit and higher Ethernet. 100BASE-TX (AKA Fast Ethernet, AKA 100 Mbps) only requires 4 of the 8.

Finally, 100BASE-T1, the specific standard called out in the poll, is an Ethernet variant which uses only one pair of wires.

3 Likes

Boop - this was the assumption I was rolling with. Locking connectors for sure, but not necessarily full sized normal 8P8C (TIL, thank you!) connectors on everything.

1 Like

TRRS noises

3 Likes

I’d trade bulkiness for ubiquity. When a rookie at an event has some transient CAN issue, I could get out the multimeter and start jiggling cables (god knows how they decided to connectorize), or I could give them a 20 pack of 3ft patch cables I ordered from Monoprice. This alone seems big to me.

1 Like

My bad, usually looking up “RJ45” gives me more of what I’m looking for than 8P8C. I wasn’t aware that 100BASE-T1 was a 2-wire Ethernet standard, that’s quite handy.

In that case, assuming non-8P8C connectors (JST PA or Molex CLIK-Mate would be good places to start) the biggest hurdle to clear would be that we would still need miniature network switches and PHYs on each device. At that point, I would sooner run a bunch of RS-485 or RS-422 busses, which would be much cheaper to implement at the cost of proportionally reduced data rate. A 10Mbps RS-422 bus can still be up to 30ft long, and low-power devices like sensors could run at reduced data rate to save power.

As it is, we run robots on a 1Mbps bus, with Ethernet only being used for cameras. I could see that being the primary driver of a need for a faster bus, but I’m curious what tangible benefits people see from running a bus that’s 100x faster.

3 Likes

Yeah! Bring back the Jaguars!

1 Like

Shop kitties!

1 Like

Let’s just use wifi or bluetooth

1 Like

1553B is old school. IEEE 1394 is way cooler. IEEE 1394B is even cooler yet! (I kid)

@marshall Jaguars weren’t bad, just misunderstood. Poor, poor Jaguars. I miss them so.

2 Likes

They weren’t bad, they were just bulky, expensive, and had poor connectors.

(qualities shared by most control system components at that time)

1 Like

They also were very susceptible to being destroyed by metal shavings, and they were big

Vulnerability to metal shavings, another hallmark of FRC electronics at the time (RIP our tote of dead digital sidecars).

5 Likes

Truth… but I do not miss those phone jack connectors.

2 Likes

…created by the screws that were part of the device.

2 Likes