2

Author Topic: Looking for 'distributed' design information  (Read 1142 times)

0 Members and 1 Guest are viewing this topic.

Offline obiwanjacobiTopic starter

  • Full Member
  • ***
  • Posts: 57
  • Helpful? 0
  • You can PIC any micro controller - what AVR!
Looking for 'distributed' design information
« on: April 22, 2013, 01:30:42 AM »
Hi

I'm looking for a schematic -or other information- of a 'distributed' design. With distributed I mean that there is not (just) one central CPU/MCU but that there are several smaller MCU's for dedicated tasks that then communicate (over a bus) with each other and a central 'brain'.

So there might be small MCU's for each wheel controlling its speed and rotational direction and giving of events whenever it slips (or something) / managing its force/sensor-feedback etc.
All of these 'slave' MCU's are attached to a bus and receive their commands from that and send events back (I think). On central MCU is in charge of orchestrating / coordinating all the slave controllers.

My goal is to make a modular robot (kit?) that can be extended and adpopted easily.

If you know resources, anything on this type of design I would be very interested.

Thanx,
Marc

Offline Jon_Thompson

  • Jr. Member
  • **
  • Posts: 37
  • Helpful? 1
Re: Looking for 'distributed' design information
« Reply #1 on: April 22, 2013, 03:21:42 AM »
Have you considered the I2C bus? It's integrated into most of the Atmel chips.
You can still do a lot with a small brain.

Offline obiwanjacobiTopic starter

  • Full Member
  • ***
  • Posts: 57
  • Helpful? 0
  • You can PIC any micro controller - what AVR!
Re: Looking for 'distributed' design information
« Reply #2 on: April 22, 2013, 03:34:40 AM »
Yes I have considered several standards. Problem with I2C is that it is not meant to 'span any distance' - more than say one board. I am somewhat concerned about EMI (motors/solenoids) corrupting data on the bus v.s. transmission speed.

I also would not mind to implement a custom, somewhat more elaborate bus that would solve these problems as well as be a little more 'multi-threading'. Perhaps have separate physical 'channels' (wires) for different type (or ranking) messages and events.

Thanx for the suggestion.

Offline jwatte

  • Supreme Robot
  • *****
  • Posts: 1,343
  • Helpful? 81
Re: Looking for 'distributed' design information
« Reply #3 on: April 22, 2013, 03:36:38 PM »
I've run I2C at 400 kHz across several feet, and it works fine. Use shielded twisted pair and you'll be fine against EMI, too. (I just ran free wiring; worked well enough on an RC monster truck.)
I2C is also nice because it's multi-master, and it allows easy daisy chaining without extending the number of wires. I really like I2C.

I've also tried SPI, but it's a less useful bus on Atmegas, because the programmers also use the SPI bus, and you have to somehow isolate your chip from the bus while you're programming it, which ends up being super annoying if you want quick iteration. While SPI could run at 4 MHz, I went back to I2C because of its superior usability.

Finally, many servos use a multi-drop serial bus. This can be an engineered long-distance bus, like CAN or RS-485, which require individual driver chips, or it can be simpler TTL-level UART. You can even do a single-line UART bus, like the Dynamixels do, where the return data only goes on the wire after the master has initiated a request. Or it can be full duplex, like the Dongbu Herkulex servos. Either way, you need a "master" to negotiate who gets to talk, whereas with I2C, that's taken care of by the bus.


Offline waltr

  • Supreme Robot
  • *****
  • Posts: 1,943
  • Helpful? 98
Re: Looking for 'distributed' design information
« Reply #4 on: April 22, 2013, 06:04:51 PM »
Yep, Jwatt covered most of the hardware buss options.

To get some additional ideas look at the various motor controllers (not drivers) as well as RC servo controller boards, sensors boards, etc that have an embedded processor.
Pololu, SparkFun and others have these boards that typically interface to the main processor through some sort of serial bus. Download the manuals to see the command protocol these boards use.

Offline obiwanjacobiTopic starter

  • Full Member
  • ***
  • Posts: 57
  • Helpful? 0
  • You can PIC any micro controller - what AVR!
Re: Looking for 'distributed' design information
« Reply #5 on: April 22, 2013, 11:55:01 PM »
Ok thanks.

My idea for giving each wheel (for example) its own processor was not so it could be controlled over a serial bus -which is what all these prefab boards seem to do, or am I wrong? - but to have autonomous parts (as much as possible) that only communicate on a more abstract/logical level.

For a wheel it might not make a great deal of difference but for a leg (with several joints) the details of how to manipulate the parts and register the feedback etc. is what that local MCU would manage. Such a leg would accept 'simple' commands that perform complex tasks and would also send events (on the bus) when it hits something (for instance) or report its health or report some stream of tactile info (for a hand the pressure it needs to hold an object - or whatever).

The central brain only has to deal with these 'simple commands' and listen to the events and make its decisions. You could even have different parts listen/react to each other.

Do you know of any standard board that will allow me to do that?

Offline obiwanjacobiTopic starter

  • Full Member
  • ***
  • Posts: 57
  • Helpful? 0
  • You can PIC any micro controller - what AVR!

Offline Jon_Thompson

  • Jr. Member
  • **
  • Posts: 37
  • Helpful? 1
Re: Looking for 'distributed' design information
« Reply #7 on: April 23, 2013, 07:44:35 AM »
Have you thought about simplifying the design and having perhaps one MCU per leg? It'll be a lot easier to program.
You can still do a lot with a small brain.

Offline obiwanjacobiTopic starter

  • Full Member
  • ***
  • Posts: 57
  • Helpful? 0
  • You can PIC any micro controller - what AVR!
Re: Looking for 'distributed' design information
« Reply #8 on: April 23, 2013, 11:26:37 AM »
[..] for a leg (with several joints) the details of how to manipulate the parts and register the feedback etc. is what that local MCU would manage. [..]

I thought I said that, but yes - 1 MCU per leg is what I'm thinking of. The 'unit' one MCU manages must make sense - in that respect a MCU per wheel is probably a bad example.

I was pondering this a bit further and you could even make sub-systems. For instance I could wire all leg-MCUs together and let it be managed by a sub-system MCU that would do only transportation/movement of the robot. But I will save that for later. Perhaps it makes more sense to bundle all sub-systems into one central MCU, possible with multiple cores to 'disconnect' each sub-system from each other.

Offline Pogertt

  • Full Member
  • ***
  • Posts: 60
  • Helpful? 3
  • Pogertt
Re: Looking for 'distributed' design information
« Reply #9 on: May 03, 2013, 10:49:24 AM »
Hi

I'm looking for ~~~~~~~~~ several smaller MCU's for dedicated tasks that then communicate (over a bus) with each other and a central 'brain'.

So there might be small MCU's for each wheel controlling its speed and rotational direction and giving of events whenever it slips (or something) / managing its force/sensor-feedback etc.
All of these 'slave' MCU's are attached to a bus and receive their commands from that and send events back (I think). On central MCU is in charge of orchestrating / coordinating all the slave controllers.



You have just described the Parallax Propeller.                                                        http://www.parallax.com/tabid/407/Default.aspx
Mmmmmmmm....Cookies

Offline tinkerbee

  • Beginner
  • *
  • Posts: 5
  • Helpful? 0
Re: Looking for 'distributed' design information
« Reply #10 on: May 17, 2013, 02:05:10 AM »
If you actually need the units located remotely from each other, why not use old fashioned USB 2.0 ?  USB transceiver available on many affordable (<$5) MCU's these days.  Make one the master hub, it can act as a data concentraotr for the rest of the slave units.  This way you can put HMI (human machine interface) on the master unit, and all the slave units can be identicaly (Easier to produce multiple units?)

Offline Graynomad

  • Full Member
  • ***
  • Posts: 79
  • Helpful? 7
    • Skype - grayn0mad
Re: Looking for 'distributed' design information
« Reply #11 on: May 17, 2013, 08:46:18 AM »
I would use CAN, it's designed for just this sort of application, it's robust enough to be used in critical systems in vehicles and is multi-master by default but you can of course implement a master/slave protocol if you want.

Also you can make a 32-bit node with ONE chip and a regulator. Can't get any simpler than that.

EDIT: Personally I love the idea of a distributed system and with 32-bit processors available for about $3 why not have an ARM at each node. I do have a biased opinion though as I am currently designing just such a system, think Arduino Due with 2MB RAM and two full-spec CAN ports plus about 20-30 nodes that perform various functions.

______
Rob
« Last Edit: May 17, 2013, 08:56:53 AM by Graynomad »
Scattered showers my arse -- Noah, 2348BC.

Offline obiwanjacobiTopic starter

  • Full Member
  • ***
  • Posts: 57
  • Helpful? 0
  • You can PIC any micro controller - what AVR!
Re: Looking for 'distributed' design information
« Reply #12 on: May 17, 2013, 09:05:24 AM »
Wow that sounds really cool!

Do these modules also talk to each other or just to one central brain?

The other day I was thinking about how you would let certain (types of) modules work together without having to go through the brain all the time. I figured you would have to have some sort of 'language' that you speak on the bus. Each type of device can have their specific dialect (or extensions) to communicate their unique abilities. But how to coordinate tasks in a distributed way... not sure about that yet.

Offline Graynomad

  • Full Member
  • ***
  • Posts: 79
  • Helpful? 7
    • Skype - grayn0mad
Re: Looking for 'distributed' design information
« Reply #13 on: May 17, 2013, 09:29:55 AM »
Quote
I figured you would have to have some sort of 'language' that you speak on the bus.

You are probably looking for what is known as a "publishing/subscribing" protocol which is basically what CAN does well.

This means that a node publishes some information, let's say the voltage of the battery, it just spits the data onto the bus with little thought to whether it's used or not. Any number of other nodes can subscribe to the "battery voltage" frame and do with it what they will, node #2 might just display it on an LCD, node #30 might send the value to a remote device via an Xbee, node #14 may shut it's non-critical functions down because the voltage is getting too low. etc etc.

Such a system can be largely independent of a master and in fact in many applications there may not be a master at all. In your case you would have a master but that's not to say that other nodes can't carry on talking to themselves as well.

In general this is a very robust model as a single failure in a master does not necessarily cause the system to fail.

Currently I am working on the "master" node, it has a SAM3X8E processor (same as the Arduibo Due) and as I said 2MB of external RAM and two CAN ports plus ethernet, microSD, very well protected IO, battery backup and some other goodies. The nodes will each have an LPC11C24 processor, this is a 32-bit ARM with a full CAN controller and transceiver built in, hence my comment about a single chip node being possible although of course you would normally have some IO conditioning as well.

When the hardware is done we plan to write a simple network layer that works on top of CAN, but that's a way off yet.

Here is a 3D render of the master board, it's just 2.1x3.2" in size, about the same as an Arduino Uno.



We will finalise the design in a day or two then I will start laying out the PCB. After that we'll start designing nodes.

The initial design was geared more towards monitoring and control of machinery and solar power systems, but the secondary aim was to think about using it for robotics although I confess to not knowing a lot about robots.

______
Rob
 
« Last Edit: May 17, 2013, 09:33:22 AM by Graynomad »
Scattered showers my arse -- Noah, 2348BC.

Offline obiwanjacobiTopic starter

  • Full Member
  • ***
  • Posts: 57
  • Helpful? 0
  • You can PIC any micro controller - what AVR!
Re: Looking for 'distributed' design information
« Reply #14 on: May 17, 2013, 10:41:18 AM »
You are probably looking for what is known as a "publishing/subscribing" protocol which is basically what CAN does well.
In general this is a very robust model as a single failure in a master does not necessarily cause the system to fail.

Yes, I know about publish subscribe and although its a nice pattern I could not see how you would be able to build say a hexapod where each leg is a separate module and still coordinates with the other legs. When one leg fails, the idea is to keep on walking (although not as graceful as before  :P ). So I can see publishing information on the bus with pub-sub, but what information would you need to successfully walk a hexapod? On startup each leg could publish its presence together with a type and unique instance ID for instance. But then each individual leg would have to keep track of all other legs (and other modules they might be interested in). Not sure if that is the way to go. I was hoping for a more 'swarm'-type of an approach. Where each leg 'senses' its neighboring kin but doesn't know about all the others... Another problem is that I totally suck at math. So any math 'models' I came across in my research are wasted on me  :o

Currently I am working on the "master" node, it has a SAM3X8E processor (same as the Arduibo Due) and as I said 2MB of external RAM and two CAN ports plus ethernet, microSD, very well protected IO, battery backup and some other goodies. The nodes will each have an LPC11C24 processor, this is a 32-bit ARM with a full CAN controller and transceiver built in, hence my comment about a single chip node being possible although of course you would normally have some IO conditioning as well.

Wow, that is a lot of processing power you have lined up there. I too was thinking of having a dedicated bus (I2C) processor but more in the terms of some small ATtiny.

Will you be running Linux on there or something like .NET Micro? (not real knowledgeable about embedded OS's)


Offline jwatte

  • Supreme Robot
  • *****
  • Posts: 1,343
  • Helpful? 81
Re: Looking for 'distributed' design information
« Reply #15 on: May 17, 2013, 11:42:05 AM »
Quote
I could not see how you would be able to build say a hexapod where each leg is a separate module and still coordinates with the other legs.

There are two kinds of failure:
1) The actual leg fails, and the controller knows about it, so it can publish "out of commission" status. Other legs can use this information to compensate what they're doing.
2) The leg may fail, but the controller still things things are fine. This can't be solved with a simple legs-only publish/subscribe model. Instead, you need sensors like "foot contact" sensors and "tilt/angle" sensors, and have the control for each leg take the global behavior of the body into account.

The cool thing with #2 is that you can end up with a robot that auto-balances if you push it, etc.

Offline obiwanjacobiTopic starter

  • Full Member
  • ***
  • Posts: 57
  • Helpful? 0
  • You can PIC any micro controller - what AVR!
Re: Looking for 'distributed' design information
« Reply #16 on: May 17, 2013, 12:32:20 PM »
Driving the leg is only one part of the MCU's task. The other would be to publish sensor feedback (at a more abstract level). Also you would design the system with some sort of heartbeat for each module as well as a repeating command structure. The heartbeat lets the system know that the module is performing as expected. The repeating commands will stop the module from endlessly carrying out its last command when the bus is severed.

or something...  :P

Offline Graynomad

  • Full Member
  • ***
  • Posts: 79
  • Helpful? 7
    • Skype - grayn0mad
Re: Looking for 'distributed' design information
« Reply #17 on: May 17, 2013, 05:53:15 PM »
Quote
I was hoping for a more 'swarm'-type of an approach. Where each leg 'senses' its neighboring kin but doesn't know about all the others...
All legs publish the relevant details but leg #2 only subscribes to leg #3 and #1 etc. I don't think the P/S model precludes what you want to do. Whether or not it's appropriate for a robot I'll leave to those who know more about them.

Quote
a dedicated bus (I2C) processor but more in the terms of some small ATtiny.
AFAIK none of the Tiny's have I2C although you can bit-bang it. If you use RS-485 and async serial the smallest AVR with a UART is the Tiny1634, but when you can get a 20-pin 32-bit ARM with UART, I2C, SPI, ADC etc for less than a $1 I don't know why you would use a Tiny unless you have a lot of experience with them and want to leverage that.

Quote
Will you be running Linux on there or something like .NET Micro? (not real knowledgeable about embedded OS's)
No, apart from the fact that this board really doesn't have resources for Linux there are already so many great boards around that do run an OS it's not worth doing another one. Anyway an OS tends to kill any realtime IO. This board is somewhere between an Arduino and a RPi I guess.

Quote
publish sensor feedback (at a more abstract level). Also you would design the system with some sort of heartbeat for each module as well as a repeating command structure. The heartbeat lets the system know that the module is performing as expected. The repeating commands will stop the module from endlessly carrying out its last command when the bus is severed.
All exactly what we will be doing, so as far as I can tell you are on the right track, you just need a physical medium on which to do it. To that end either RS-485 or CAN, until a few months ago I was planning to use RS-485 and async serial, but I chaged over to CAN because there is so much support for it in CPU hardware.


_____
Rob


Scattered showers my arse -- Noah, 2348BC.

 


Get Your Ad Here