2
\$\begingroup\$

In the context of a robotic project where different 'payloads' and/or robotics arms (end-deflector) should be mated mechanically with power, data and control connections support, I would like to identify the best suited (serial) bus.

I have a hard time putting together the requirements, but the main 5 important ones could be summarized as following:

  1. Minimal wiring: 2-3 pins (or less)
  2. Multi-points/clients, if possible without host/client/server/master aspects
  3. The-wiring-is-the-bus (=no need for repeater/switch/hub)
  4. Hot-pluggable/swappable: adding/removing clients, changing the topology
  5. Support for different topology: straight, meshed, star, fake-loop,...

Speed is not really a constraint.

Currently CAN bus was used in our bread-boarding, in order to inter-connect a few RasPi/Zero with PICANDUO daughter boards, covering almost all 5 requirements except of course #4, as it is not meant to be hot-pluggable and thus gives issues for #5 (especially moving/adapting the 120 ohms termination resistors). We then use a flying master for changing the master of the bus.

Ethernet would be almost covering all 5 (except #1 & #2), but is completely overkill...so is SpaceWire. SpaceFiber could be an option.

I am also considering RS-485, LVDS, I2C, 1-Wire,... But these seems to get trouble with #4 (end resistor) too.

USB would be great (only 2 data wires, powered separately), but it requires a single (stable/single) Host/master (or does it?).

Am I overlooking a specific bus here?
What would you think of other potential candidate(s) here?

Thank you for your hints!

\$\endgroup\$
1
  • \$\begingroup\$ I am also considering RS-485, LVDS, I2C, 1-Wire... You appear comparing apples to oranges. Recommended Standard (such as RS-485) is a medium to send/receive the data, LVDS sort of defines how the signal behaves, and then I2C and 1-Wire are typologies for Master/Slave device configuration. \$\endgroup\$
    – user103380
    Feb 10, 2019 at 19:05

2 Answers 2

Reset to default
1
\$\begingroup\$

The physical portion of your network could easily be RS-485. Although one normally uses termination resistors on all of the stubs, this can be alleviated by having the termination resistor permanently attached at the longest (furthest) node of the bus..

Or - operate at a sufficiently-low speed that reflections are not an issue and thus do not require termination.

You will need to work out the communication requirements and write your software accordingly.

This can be hot-plugged provided your software is written such that it will tolerate the momentary disruption

\$\endgroup\$
4
  • \$\begingroup\$ Ah, very interesting... does it mean there is some 'tolerance' on the resistor presence? what about the reflection/distortion? Yes the SW would be covering these aspect indeed, no problem. \$\endgroup\$
    – bli
    Feb 10, 2019 at 19:20
  • \$\begingroup\$ You typically do not need termination resistors if your data rate is slow. \$\endgroup\$
    – Dwayne Reid
    Feb 11, 2019 at 1:06
  • \$\begingroup\$ Sweet. And what would be typically your winning argument of RS-485 Vs. CAN ? \$\endgroup\$
    – bli
    Feb 11, 2019 at 13:15
  • \$\begingroup\$ Both, actually. I tend to think of RS-485 because that's what I've used in the past. But CAN is often arguably better than RS-485 in many applications. The salient point I was trying to make is that termination of stubs is not a problem if the reflections are completely died out before the receiver has acquired the proper number of samples for each bit time. That would imply that the reflections want to be finished in something like one-sixteenth of a bit time. That further implies a fairly low bit rate. You can work the math once you know your maximum stub length. \$\endgroup\$
    – Dwayne Reid
    Feb 12, 2019 at 0:15
1
\$\begingroup\$

CAN bus sounds like the best choice.

It somewhat fulfils your requirements including hot swap, as long as there is at least 2 nodes present, termination is taken care of, and the involved nodes know how to handle the new node. The new node would have to be connected to a stub, or otherwise you must temporarily disrupt the bus and move terminating resistors.

Different topologies work if you mix several sub nets with different CAN buses. The default CAN topology is a straight line, which isn't unique to CAN, same goes for RS-485 etc.

Most importantly, CAN is suitable for robotics or industrial use. It is very rugged, more so than RS-485 even. And due to CSMA/CA, CAN can be used for hard real-time, unlike Ethernet. RS-485 has no collision detection at all, so it relies on higher level protocols like Profibus to handle that.

Overall CAN is more modern than RS-485. UART technology is quite ancient. A CAN frame contains size, CRC and syncs every bit. RS-485 syncs every 8 bits. size and CRC is manual, plus it must support obsolete crap like parity.

Sounds like the higher layer you are currently using is CANopen, which is probably the best choice there.

\$\endgroup\$
3
  • \$\begingroup\$ Thank you! very valuable inputs. Indeed CANOpen was used for flying master and fall-ovre redundancy features (and PDOs/SDOs formating) However, what would be your second choice, should we move to a full-meshed topology? going wireless with Xbee ? \$\endgroup\$
    – bli
    Mar 21, 2019 at 8:36
  • \$\begingroup\$ @bli You'll need a specification... But consumer electronics and "2.4GHz fluff" is often not suitable for industrial use. \$\endgroup\$
    – Lundin
    Mar 21, 2019 at 8:42
  • \$\begingroup\$ I totally feel you for the "2.4GHz fluff". I wish there was a wired fully-meshed bus/network (well, yeah, other/lighter than Ethernet). I am afraid SpaceWire will be the way to go... \$\endgroup\$
    – bli
    Mar 22, 2019 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.