Which embedded system would you use?

A research,

Which digital and wired communication system would you use for the following robotic system.

A system composed by a PC/104+ (it is just a very compact standard PC) with Xenomai (or maybe RTAI), and some sensor nodes (something like

12, but could vary a lot). These sensor nodes are basically composed by a DSP/MCU/DSC (not the same one on every node) and some sensors and actuators. The sensors can be anything so i will not give any fixed description, but a good example would be a Brushless motor (with the control routine inside the MCU/DSC), and 4 to 5 sensors with a max sample rate of 2ksps. Basicaly the PC/104+ should get all the data from sensor nodes (the MCU will handle the communication on the node side) perform some processing and send back some reference to the actuators control routine. The whole system should work with a 500us period. The max acceptable latency between the PC/104 ask for the data and the reception should be 100us, and the maximum latency for the actuators command should be 70us (bewtween teh pc104 send and the node receive). From all the commercial standard availables, all i could find was Ethercat and Firewire, that have a chance to handle this communication..Any idea? Just a final comment. The system should have the minimum amount of cables possible and the max distance between the PC104 and the nodes is 3m.

Thanks!!

Reply to
Sink0
Loading thread data ...

As for reducing cables, look into Zigbee.

formatting link
and other makers offer boards with Zigbee.

Otherwise, I think ethernet might be a good choice. Or USB 3 perhaps. Much depends on the 'horsepower' in the node/sensor units I guess.

Reply to
1 Lucky Texan

As for reducing cables, look into Zigbee.

formatting link
and other makers offer boards with Zigbee.

likely, it's data rate is way too slow, it claims low latency, but that might also be to slow for you.

Otherwise, I think ethernet might be a good choice. And power over ethernet (POE) could be a way to reduce cabling - at least power cables) Much depends on the 'horsepower' in the node/sensor units I guess.

Reply to
1 Lucky Texan

I need some high Reliability in this system, and wireless is not that reliable. Anyway, i cant belive Wifi, or any other wireless interface controlled by a RT Linix could achieve my Real Time requirements... just to make it clear, 100us is for a round read, and not a single node...

But thank you!

Reply to
Sink0

If you have an industrial background and want something that works better than spec'ed, go for CAN BUS.

If you're an academic and just experimenting and most probably do some very different things with the same boards next year, go for ethernet. Possibly start with raw ethernet frames or static UDP this year (for the latency), and go ARP + TCP next year. Or skip the first step for convenience. Porting UIP or LWIP is a good place to start.

Best regards

Reply to
Marc Jet

What SIL level is this robotic system required to have? ... (based on the Hazard Analysis and Risk Assessment work you have obviously already done. You have done that haven't you?).

--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

Not yet becouse we are going to work on a research enviroment and its all very experimental. The robotic system its for rehabilitation purposes, and human motion analisys, so we are going to need high rel on this.. but we dont need any certification for now. Thats the rules here (i am not from US). We are not really worried about that for now as there are lots of safety requirements implemented mecanicaly, so, on the worst case scenario the system would not work properly, but would not cause any harm to any person. All the actuators are very low power (100W or less) due to some security restrictions, and all them got a properly placed mechanical lock.

Any way, i am developing myself a system with these requirements from the scratch using FPGA, and i am already on a intermediate stage, but i always like to check new ideas as i dont want reinvent the wheel.

Marc, CAN would be perfect, but it is too slow, and i cant belive the arbitration scheme used on CAN could be used on a 50-100Mbps communication system. Ethernet, is fast for big packages, but VEEERY slow for small and distribuited ones (thats the reason for the existency of EtherCAT) due to a big latency between packages.

Thank you!

e quoted text -

Reply to
Sink0

I think you've got a tough row to hoe, and I can't think of a strong reason to favor one over the other. I _suspect_ that you'll end up with Ethernet, either running one of the real-time Ethernet protocols and most specifically not using TCP/IP, or running your own home-rolled Ethernet protocol. I also think you'll be spending some amount of your time and energy dissuading the OS on the PC-104 side from ever sending anything long.

Look at high-speed USB, too. I don't think you want it, but it has speeds to rival the practical FireWire versions.

Finally, I rather suspect that you'll never hit bandwidths that would really require that sort of speed -- if you've got some robotic contraption with cable lengths of three meters, then I doubt that you'll have any loop bandwidths greater than 100Hz. That's getting down to allowable sampling rates of 1kHz or even 500 if you push on it, and _that's_ getting down to speeds where the CAN bus starts making lots of sense.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

You might also look at Token Ring. It's architecture 'might' be a little better for your app than ethernet. Though I have no idea about cost/availability of components.

Reply to
1 Lucky Texan

Token Ring/ARCnet might work well for robotics, but it seems nothing has been done since about 2001 and I doubt components are available.

Reply to
1 Lucky Texan

you might also ask over at;

comp.dcom.lans.misc

Reply to
1 Lucky Texan

You have not nailed down how many nodes, but KISS is always best. If you use a Stub.Star RS232/485/422 at 1MBd, that's bog-standard parts, and you can send 10 bytes in 100us, but the Stub.Star shifts the bandwidth issues from the link, to the Stub. eg You need 16 UARTs to serve 16 star points, which should bold onto PC/104 easily, and the higher bandwidth is on the daughter PCB, NOT the links. Debug/modify/Test of Stub.Star is also very easy.

RS232/422 allows 10 bytes in both directions. inside 100us

Choices are SPI or parallel blocks, from the usual suspects of Maxim (I see they now have a SPI UART with Profibus speed spec & many do Profi bus drivers) NXP, Exar, etc

Numbers like MAX3107, SC16IS762, XR20M1172 for SPI, or try XR19Lxxx for a Dual Parallel model, Line Drivers included !. If you choose larger FIFO models with HW handshake, you can even load all channels, and launch all syncronised with a handshake line.

-jg

Reply to
Jim Granville

h

That's exactly what we are discussing. TCP/IP does not make much sense with internal nodes. Dealing with IP addressing scheme is annoying, especially if we only have one master and many slaves.

You don't need high speed USB for low latency. Full speed is good enough, as long as you code it properly.

We are running RUMBA (Rumba is not Samba) over ADB (Android Debug Bridge) on PXP (Point multipleXer Point) using USB (Universal Serial Bus).

In this case, USB host is the master and devices are connected with endpoints.

Reply to
linnix

Yup. I just wanted to make it explicit, so the OP wouldn't make the beginners mistake of equating "Ethernet" with "TCP/IP".

I know there's Ethernet protocols that are pretty good at soft real-time, and I've been told in a water-cooler discussion or two that there are protocols that schedule the time critical stuff to go out when the network is quiet (to avoid the inherent nondeterministic behavior of Ethernet's back off and retry collision avoidance scheme), but that's about _all_ I know.

Good point. And the highest-speed whiz-bang low-latency network in the world is gonna be crap if you code it wrong -- so coding it right is no barrier.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

PC)

and

data

node

the

I would seriously reconsider your requirements for 2 KHz sample rates. I believe that it is driving you into a set of requirements that are difficult to achieve. Most robotic systems have much lower control loop frequencies, more like 100 Hz.

At 2KHz your are likely not only to have communication problems but also computing problems - not enough time to process the data and implement control algorithms, and act on results.

Since you have intelligence in the sensors some processing of raw sensor data can be done in the sensor (i.e. filtering) which will further offload processing from the central processor.

Also, consider methods that would eliminate the need/latency/overhead associated with polling sensors for data.

--------------------------------------- Posted through

formatting link

Reply to
TC

(hint -- if it's for sampled-time control, having the sensors send autonomously at the sampling rate is a big help).

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Well, most of the high sample rate sensors wont be related to mechanical sensors, but to biosignals sensors.. and there is a whole field of study on how to process that data on real time, and send some command before your body can even proccess its own signal. I am talking something that can range between 20Hz to 300Hz.. so thats why the high sample rate, and i cant just filter it becouse some theories makes use of the frequency composition of the signals. Sending the data only when its change is ok, and will be implementing with a tolken ring logic topology (for now on a M-LVDS Bus), but on i must consider a worst case scenario, where everything is changing all the same time, and probably that is going the be the most unstable movement. The 2kHz control routine is a good number, most of the system around the world use some number close to that. Longer control loop might lead to some undesirable behaviors with the state of art control routines. Of course to find a more robust one, is one of the big challenges.

About USB, i cant belive i can get to that lattency in special if i am talking with a single cable to lots of nodes. Any good example that i could sample 12 different slaves on 100us? Well, i cant see how to make use of Ethernet without all the basic overhead.. most o the messages will be as big as the 64 Bytes of data.. or close to that.. And both Ethernet and USB are undesirable due to the phisical topology. Star is not good, TOO many cables. Most is acceptable is one cable (with many wires inside) for data and log powering, and 2 cables for actuators powering.. crossing each joint. EtherCAT is good becouse it does not need a Router, HUB or anything other than the EtherCAT controller. FireWire can Daisychain..... So a RING, or Bus topology would be the prefered ones.

Anyway i am tired now (kinda late here) so i will think again on the sugestiosn tomorrow. Thanks!

Reply to
Sink0

No, but you can do it with 6 slaves directly. I am talking to my Android phone with a 32MHz PIC at around 12,000 packets per second. So, 6 slaves would be around 2,000 per second. You can achieve more with layers of master/agents/slaves. Namely, one main master talking to multiple agents, and agents talking to multiple slaves.

The 500msec ethernet lantency will kill you, so to speak.

Reply to
linnix

Sorry, I meant TCP latency.

Reply to
linnix

Well, as for bus structure with "many wires' you might take a look at GPIB (IEEE-488) and SCSI.

Reply to
1 Lucky Texan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.