Squirrels have fuzzy tails.
0 Members and 1 Guest are viewing this topic.
[..] 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. [..]
HiI'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.
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.
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.
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.
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...
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)
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.