0

I'm building an exoskeleton in a student team and we're having some trouble finding the right prototyping system for our electronics system. All of the shelve systems are either too slow or too big. The setup is simple. Each leg has 3 joints and each joint has an array of sensors. These sensors have to be read by a DAQ system and then sent to a target computer running a control loop (simulink or labview).

NI has offered us some help by using their MyRIO's to acquire all sensor data where we can then send it to a CompactRIO over CANbus. However, we are unsure if that's fast enough. Each joint has to send 500bits per sample and we really need to keep the latency as low as possible. In total we need to sample at 200Hz. From what I've heard and read is that the CANbus won't be able to supply us with a fast enough connection due to all kinds of overhad. Perhaps it is possible to chain multiple CANbusses in parallel?

We looked into EtherCAT as well but all the data acquisition systems are huge and industrial. We need to keep it small.

Designing our own electronic boards is really difficult due to our time constraints and knowledge within the team.

So my question is what the available options are in case CANbus with NI hardware doesn't pan out due to its speed.

The requirements for the boards and overal system are:

  • Interface with Simulink or Labview
  • DAQ boards no bigger than a MyRIO
  • Programmable
  • 4 Digital inputs and 3 analog inputs per board

EDIT: added sampling rate

Ortix92
  • 147
  • 6
  • 1
    Shopping questions - those asking for a specific product recommendation - are offtopic on ee.se, because they're not likely to be useful to anyone else. Sorry! – Nick Johnson Oct 26 '15 at 10:18
  • Maybe we need a "shopping" tag; one that automatically closes a question once the tag is selected! – Andy aka Oct 26 '15 at 11:13
  • Do you really need 500 bits per sample? What sample rate? Could you just have a bigger wiring loom and link all the sensors directly to the master RIO device? Quite a lot of microcontroller eval boards might be suitable for this, e.g. http://www.nxp.com/products/microcontrollers/core/cortex_m0plus_m0/series/LPC11C00.html – pjc50 Oct 26 '15 at 11:21
  • Have you calculated the actual data rate the system needs? You wrote: "Each joint has to send 500bits per sample and we really need to keep the latency as low as possible", but how big is *keep the latency as low as possible*? That isn't a useful specification. As low as possible is only limited by the speed of transmission, which is about 1foot (30cm)/picosecond. Is that really what you need? Please try to write a proper specification. At worst that will put a bound on the problem. To reach some estimate calculate how far an object falls in 1millisecond under gravity. – gbulmer Oct 26 '15 at 11:47
  • You need to specify sample rate and the total number of nodes. That is, the total amount of data that has to be sent (and processed) per time unit. – Lundin Oct 26 '15 at 12:38

1 Answers1

1

So you have 2 legs times 3 joints = 6 CAN nodes, each needing to send 500 bytes at a sample rate of 200Hz.

Each CAN message can contain up to 8 bytes data, and given that you pick 11 bit CAN identifiers, each CAN message has an overhead of 47 bits (including end of frame and intermission). The number of messages = 500/8 = 62.5, round up to 63 messages needed.

The total number of bits to send per node will then be:

Total bits = total data bits + number of messages * overhead bits

Total bits = 500*8 + 63*47 = 6961 bits

You need a sample rate of 200Hz, meaning 6961 bits has to be sent each 1/200 = 5th millisecond. 6961 / (5*10^-3) = 1.39 Mbit/s, assuming continuous transmission on the bus with 100% bus load. Max recommended data speed for a CAN bus is 1 Mbit/s.

And that's just the need for one node. Multiply this by 6 and you get a total need of 8.35 Mbit/s.

So CAN bus will not work. Not even if you would use 6 parallel CAN buses, which would also in turn force you to use some unorthodox automotive MCU with 6+ CAN controllers on board. Or alternatively, create some nightmare solution with an array of 6 external CAN controllers...

Also of interest: your "master" CPU will have to be able to process 500*6 = 3000 bytes of data each 5th millisecond = 600k bytes/second. Unless the data is of trivial nature, you are in need of a powerful CPU to handle that.

So the sensible solution here is to go check those 500 bytes and see if you really need that many:

  • Are integers 32 bit resolution and if so, why do you need that?
  • What is the actual resolution on the DACs and ADCs?
  • Is there floating point data? Replace with integers.
  • Are there ASCII strings or other forms of non-compact data that could be replaced by index numbers?
  • Is there some kind of identifier or priority among the data which you can replace with the CAN identifier?
  • Does the data have a checksum and if so, do you really need one, given that a CAN message comes with built-in 15 bit CRC?
  • And so on.
Lundin
  • 17,577
  • 1
  • 24
  • 67