On May 4, 12:02=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:> On 05/04/2011 04:36 AM, Sink0 wrote: > > > > > 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. > > 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. =A0I _suspect_ that you'll end up wit=h> 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. =A0That'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.> 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. =A0You 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.
Which embedded system would you use?
Started by ●May 4, 2011
Reply by ●May 4, 20112011-05-04
Reply by ●May 4, 20112011-05-04
On 05/04/2011 03:06 PM, linnix wrote:> On May 4, 12:02 pm, Tim Wescott<t...@seemywebsite.com> wrote: >> On 05/04/2011 04:36 AM, Sink0 wrote: >> >> >> >>> 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. >> >> 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. > > 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.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.> >> 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. > > You don't need high speed USB for low latency. Full speed is good > enough, as long as you code it properly.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.> > 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. > >-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●May 4, 20112011-05-04
>On May 4, 2:42=A0pm, 1 Lucky Texan <alcky...@swbell.net> wrote: >> On May 4, 6:36=A0am, Sink0 <sin...@gmail.com> wrote: >> >> >> >> >> >> >> >> >> >> > 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 standardPC)>> > 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 sensorsand>> > 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 thedata>> > and the reception should be 100us, and the maximum latency for the >> > actuators command should be 70us (bewtween teh pc104 send and thenode>> > 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 betweenthe>> > PC104 and the nodes is 3m. >> >> > Thanks!! >> >> Token Ring/ARCnet might work well for robotics, but it seems nothing >> has been done since about 2001 and I doubt components are available. > > > >you might also ask over at; > >comp.dcom.lans.misc >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 http://www.EmbeddedRelated.com
Reply by ●May 4, 20112011-05-04
On 05/04/2011 06:45 PM, TC wrote:>> On May 4, 2:42=A0pm, 1 Lucky Texan<alcky...@swbell.net> wrote: >>> On May 4, 6:36=A0am, Sink0<sin...@gmail.com> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> 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!! >>> >>> Token Ring/ARCnet might work well for robotics, but it seems nothing >>> has been done since about 2001 and I doubt components are available. >> >> >> >> you might also ask over at; >> >> comp.dcom.lans.misc >> > > 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.(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 http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●May 5, 20112011-05-05
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 by ●May 5, 20112011-05-05
> ... > 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?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 by ●May 5, 20112011-05-05
On May 4, 8:28=A0pm, linnix <m...@linnix.info-for.us> wrote:> > ... > > 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? > > No, but you can do it with 6 slaves directly. =A0I 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. =A0You can achieve more > with layers of master/agents/slaves. =A0Namely, one main master talking > to multiple agents, and agents talking to multiple slaves. > > The 500msec ethernet lantency will kill you, so to speak.Sorry, I meant TCP latency.
Reply by ●May 5, 20112011-05-05
On May 4, 10:15=A0pm, Sink0 <sin...@gmail.com> wrote:> 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!Well, as for bus structure with "many wires' you might take a look at GPIB (IEEE-488) and SCSI.
Reply by ●May 5, 20112011-05-05
On May 4, 10:15=A0pm, Sink0 <sin...@gmail.com> wrote:> 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!Well, as for bus structure with "many wires' you might take a look at GPIB (IEEE-488) (and SCSI 2 or 3.) ******HS488, a higher-speed GPIB transfer protocol, scales the maximum data transfer rate of ANSI/IEEE Standard 488.1-1987 up to 8 Mbytes/s by removing delays in the 3-wire IEEE 488.1 handshake. HS488 is implemented in hardware as a feature of the TNT4882C GPIB controller ASIC, and thus imposes no additional software overhead during HS488 transfers. Because HS488 is implemented at the hardware level, your application code requires no modification to take advantage of high- speed GPIB. Using the HS488 protocol, the GPIB Controller hardware can automatically detect compatible devices capable of using the HS488 handshake to transfer data. If the Controller does not detect an HS488 capable device, it automatically defaults to the standard IEEE 488.1 3- wire handshake to complete the data transfer. The HS488 protocol employs the same proven, high-speed, data streaming techniques used in VME, PCI, and Fast SCSI. ****** from; http://zone.ni.com/devzone/cda/tut/p/id/4552
Reply by ●May 5, 20112011-05-05
On Wed, 4 May 2011 04:36:51 -0700 (PDT), Sink0 <sink00@gmail.com> wrote:> 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.Since the distances are that short, have you looked at for instance PCI Express ? This is of course point to point, but at x1, the cable consumption would not be that bad. Are all data actually used in real time (e.g. in a PID controller) or is most used for later analysis, in which case it would make sense to collect a few samples and send it in a single longer message. If there are a large number of nodes physically close to each other, but far away from the master controller, using direct wire connection to concentrators near the nodes and then use some CAN/Ethernet protocol to the master controller. I guess you also need some clock distribution system, so having direct wire connections between the nodes and concentrator is not that bad idea. As you said EtherCat might be an option even direct connection to each node, but the total cost might be quite high.
