Networking miltiple (60) slaves to a master picaxe

[guyba]

Hi
I"m working on an art/robotics project. We chose PICAXE as our microcontroller when I read (somewhere) that the new picaxe 28x1 supports the i2c protocols and allows to network 1 master chip to up to 120 slaves via a 2 line bus. My artwork requires 60 slaves (basically 60 interactive objects that each is controlled by a slave picaxe that get infor from a master picaxe.

Yet when I was reading teh i2c tutorial it stated that theoretically this can be done.

I was wondering if any of you networked more then 10-15 slaves to a master chip via 2 line bus ? DO you think it would work ?

Guy

 

[BeanieBots]

Sounds like a great project. 60 slaves!
Never tried more than 4 myself but see no reason why it shouldn't work.

Things to consider are speed and distance between devices. With so many slaves, any amount of distance is going to add capacitance to the lines which could be a problem if trying to run at high speeds.

Also, you don't need to limit yourself to I2C and hence the 28X1. You could also consider serial comms either all connected together or daisy chained. Again, if there is a long distance between devices daisy chaining might be a better option. I have 10 08Ms daisy chained all passing their data on to the next in line and finally down to the master which then tells each one to do based on what they have "seen".

Maybe if you could describe the layout in a little more detail and how much/often data needs to be passed, the gurus can come up with some optimised options that would be reliable from both a hardware and software perspective.

 

[Technical]

This will work, but only if your i2c bus signals are transmitted correctly (i2c is not designed for long distances). How far apart are the individual units?

 

[guyba]

BeanieBots & technical thanks for the advice - Here is a better description of what we are hoping to achieve -

The artwork is composed from a grid of 60 robotic objects (8x8 with no corners). The spacing between them is 1 meter. So affectivly the whole grid is 8x8 meters.

We would like The master to recieve 60 numbers from an external source (MAX/MSP program) and send via serial 1 number to each of these objects. each slave supposed to turn a motor forwadrs and backwards to a specific target as specified by the number. Once all the slaves finished moving the motor they need to send back to the master a "done" signal so the master takes the next set of numbers. We are hoping that the whole cycle will repeat every 1-3 seconds.

So thats it...
what sort of hardware/software design would you recomend ?
thanks
Guy

 

[Brietech]

This sounds pretty cool. If you are only sending 1 "number" to each slave, I2C is probably overkill. If you use serial (someone with more experience than I will have to explain how to do it with fanout that high), you can just send all 60 bytes (or words...how big is your number?) in a row, preceded by something like a "#" symbol, and each slave will just wait to get the string and skip the appropriate number of bytes (i.e. slave 1 will read the first number, and ignore the rest. Slave 2 will read the 2nd number, and ignore the rest, etc.).

It might be a lot easier to just wait the maximum amount of time any of the slaves will take, and then go ahead and send the next number after that.

 

[BeanieBots]

That's a lot of cable and I would have concerns about using I2C with that amount of inherited capacitance. It could be even worse if there is a conductive backing to the project. I would certainly recommend testing with the full grid and maybe just a few ICs prior to committing to such a layout.

Not sure how much you want to give away but it is very hard to advise without knowing more details and what is important for the project and what is not. For example, is feedback essential or could you just 'assume' it achieved position? Does everything need to move at EXACTLY the same time? If yes, how exactly? and the list goes on...

Have you considered the use of 'Hobby Servos'?
These are totally self contained units with a rotary arm that moves through about 90degs.
They are sent a continuous stream of pulses where the width of the pulse determines the postion of the arm. There is no return signal to indicate position has been acheived but unless heavily overloaded they always go to where they have told to go.
There are many contol boards available including one from Rev-Ed which can control 21 servos so you would only require 4 boards which in turn could all be controlled by one PICAXE.

 

[hippy]

Serial ( SEROUT/SERIN ) would seem to be the easiest solution. The single serial line is fanned-out or chained through each of the 64 receiving PICAXE's.

Stopping the transmitting PICAXE from sending anything further until all have completed their task would probably be best achieved by using a single open-collector 'ready' line with a pull-up which each PICAXE can access.

Any PICAXE which is busy pulls that line low, only when all have finished their task will the line go high and the transmitter can send further data.

The wiring would be no more complicated than for I2C. Four core cable could daisy-chain or hub-wired to each controller carrying both signal lines, 0V and power.

Serial will allow instructions to be sent to single, groups of, or all receivers if that were desired. Reasonably high baud rates can be achieved.

Depending upon what each receiver does, it may be possible to use smaller PICAXE's (08M/14M) or use larger PICAXE's to control more than one square/motor. That could save controller costs and provide money for other uses elsewhere.

Some more detail on what each controller does and how the type of motor and how they are controlled may produce some helpful suggestions.

 

[steliosm]

guyba do you have a blog/something so we can check out your project?
It does sound to me like an ITP project.

 

[Wrenow]

Do you really need the feedback to the master, or do you just need to know that the motor went to/stopped at a particular position? You might find it easier to do with regular hobby servos *they are designed for proportional positioning, of course), and some serial servo controller boards. The Picaxe boards can run 21 servos each, and pololu.com has a tiny one that runs 8 each that can be daisychained to up to 256 servos, I seem to recall.

Just a thought on a different approach to the mechanical and capacitance issues I see you encountering.

Hope it helps.

Wreno

 

[Ralpht]

As far as distances go with I2C, try using a 82B717 extender chip. This extends the range if the I2C buss. It's a simple and easy to use 8 pin dip chip - I2C in and I2C out with the usual pullups. I'm reliabily using the I2C at distances of 50Mtrs. The chip can be hard to get at times but well worth it.

 

 

[guyba]

Hi all

Thanks you all for the valuable suggestions. I’m starting to see that there are a few options available in order to network 60 picaxe slaves to a single master. However all options create a few more variables and hence there are a bit more questions...

But first some of you requested more information on what are we doing – so here is a very generic description. I will make it as short as possible...

The project is called “MEART – the semi living artist” in which I have been developing for the past 6 years with a few colleagues. In this project we explore the possibilities of interfacing real living neurons to a mechanical body. Until now we interfaced the neurons (growing in a Petri dish) to a drawing machine. More information about the project (images as well as the artistic and philosophical framework) you can fine here – http://www.fishandchips.uwa.edu.au
Now we are planning to build a new body to this semi living artist. The neurons are grown on a special dish that has 60 electrodes fitted on its surface. Each electrode can record the electric activity of the neighboring neurons. We plan to create 60 sculptural robotic objects. Each of the objects will represent the neural activity that occurs in the Petri dish in Dr. Steve Potter’s lab in Atlanta. This dish contains networks of tens of thousands of brain cells grown in vitro on a scale of a square millimeter. The behavior of a moving part of each sculptural form will be directly dependent (in real time) on the electrical activity of the neural clusters of each receptor electrode mounted on the Petri dish. The interface between the robotic object and the neurons will be done via the internet. Furthermore, the audience will be able to interact with the neural network by either touching, moving through or simply by being in the space. These activities will be collected in the gallery using sensing technology, converted into stimulations and sent to the neural network in Atlanta as information about “what is happening in the gallery”. That’s it in a nut shall. Here you can check out a simulation of how we want it all to look like - http://www.fishandchips.uwa.edu.au/meart2.html

So… back to my questions - Each of the 60 objects has a 12V DC geared motor which is used to move a cartridge up and down vertically over a distance of 2 meters (BTW – the cartridges will draw on the objects once it got to the target). The motors are fairly high current they run at 500 mA but they draw 1 amp on start up therefore we are looking at using the L298 or the LMD18201 to drive the motors. (Does anyone know of another suitable motor driver ?)
Feedback is necessary! We don’t want to make any assumptions and need to know when did all motor stopped to get the next set of instructions from Atlanta.
It seems that various replies have suggested that in addition to i2C I can use serial communication either "fanned out" or chained together. I’m assuming that this refers to connecting up in parallel or series. Does anyone know if either of these configuration would work? What is the better way to go if we consider efficiency and debugging in case something goes wrong? Does any one have a simple schematic of either option that you can send and we could test? (a picture is worth a 1000 words

Apologies for this long post but… I hope one of you could help us here…

Thanks

Guy

 

[D n T]

Could you set up a grid 8 x 8, you would have to portC or the like to get the 16 outputs from the same chip, but could you use a coordinate type of system to trigger each 08 chip?
The 08 could have one input connected to the horizontal wire and one to the vertical wire, when it gets a high on hoizontal and a low on the vertical it could extend, then when the signal is reversed, it would retract. one of the signals ( horizontal, or vertical could be analogue and each 08 on the wire could be coded to activate on a particular analogue signal, enabling inivdual unit control ( 250 + per line)

Just a thought.

 

[hippy]

With respect to fanned out or chained, each unit would be driven in parallel. The only difference is how the single wire is run around the display, from Hub to A plus Hub to B plus Hub to C, or Hub to A, A to B, B to C. It can be either or a mix.

For debugging, serial is undoubtedly better. To monitor what is happening on the bus, all that is needed is a PC running a suitable data capture and reporting tool. The network cable would connect straight into the PC's serial port just like any other receiver. The PC can also be used to send commands to the units during development to check everything is working.

There are PC to I2C interfaces but they are not cheap and are more difficult to use.

 

[BeanieBots]

Hmm, begs the question at what stage can you be accused of being cruel to a robot? Could become as controversial as how to charge a battery<img src="wink.gif" width=15 height=15 align=middle>
anyway...
Thanks for the decsription and links, explains what you're doing nicely. Great project.

As for the comms, either fan/hub or daisy-chain will work. They are indeed similar to series/parallel. With fan, one central device 'talks' to all the slaves at the same time. Think pictorially of a spoked wheel. In a daisy-chain, the first device talks to the second which then 'passes' the message on to the third etc. etc. I don't think one is any better than the other but there are pros and cons with each.
With a hub, sending to the slaves is easy but for the slave to send back to the master can be tricky to avoid all 'talking' at once.
(might be simple in your case if they only need to say &quot;job done&quot.
In a daisy-chain, the code in each 'link' will be a little more complex but has the advantage that it also acts an amplifier/buffer for signals going over a long distance. A disadvantage is that if a link 'breaks', everything from that link onwards also goes down. You can also mix and match with several hubs daisy-chained together.
Hopefully somebody will give a better insight than mine.

Some of your choices may well be dictated by budget, skill and timeline. You have not indicated any of these.

How would I do it?
That would depend on who was paying and it's intended future.
If it was a project for a paying client with no budget contraints and reliability was important, I would use ready-made modules off the shelf using industry-standard protocols. That would also allow A.N Other person to 'service' it after I had gone without the need to learn what I had done.
The sort of modules I would use would be &quot;CANBUS&quot; and/or &quot;MODBUS&quot;. These are units used in industry and automotive applications. They use a very reliable comms protocol (safe for fly-by-wire) and PC interface cards are available. (VERY expensive option)

If I was doing it for my own amusement on a low budget, I would buy a bunch of cheap 'hobby servos' and hack them for the motor drive units. Replace the feedback pot with whatever position sensing device you have on your robot parts and connect the motor drive outputs to your motors. It should be possible to locate the 'error' signal on the servo control board. Test the signal with a comparitor (or simple op-amp) and use it to drive a logic level &quot;job-done&quot; signal.
The modified servos could then be driven by a servo controller board. As already mentioned, Rev-Ed do a board that can control 21 servos. Would be worth searching to see what others are available.
Then, the only signal that needs to go to each of the robot parts is a servo pulse to tell it where to go and a logic level that comes back once it gets there. You then have the choice of hub or daisy-chain if you use several servo control boards.

Another option, but probably cost prohibative, would be to use PC rackmount motor controllers. These are complete motor controllers that plug into a 'standard' rack system such as VME and are sent 'commands' via a data bus. Only motor cables and feedback signals go between the moving parts and the 'rack'. This is how powerfull precision robots such as those used in car manufacturing are typically controlled. By having all the controllers on a high speed bus allows very complex spline movements to be made where all the motors work together in real time at high speed.

Pros and cons which ever way you turn!
The choice is yours.
Somewhere on this forum someone posted a link to the &quot;wooden mirror&quot; project. I can't find the thread but I'm sure google will get you to the project. I understand that was done using 'hobby servos' with no feedback to the main controller.

 

[hippy]

My use of daisy-chained has been ambiguous; I should have said, single-wire multi-drop bus.

 

[Wrenow]

The further explanation is, indeed, a big help. Hobby servos would be difficult, as is, due to the 2 meter throw. As to feedback, keep in mind that hobby servos do have feedback, but that it is just internal. Which leads us to the Openservo project.
http://openservo.com/

The boards are available from http://pendragonrobotics.com/OpenServo.html

It might be just the local electronics motor control package you need, and also provides, as I recall, various types of feedback to the processor. You will, of course, need to add a position sensor. I am not sure, but am thinking one of the little IR distance sensors (many have up to a 80 CM range, some may be long enough, though) might be semi-elegant. I am thinking the ultrasonics would have too wide a beam pattern for your application.

Just some additional thoughts.

Also, for the motor control, if you separate out the feedback and positioning functions, you can get by with a simple, off the shelf ESC (electronic speed controller) commonly used in robotics and R/C - like a servo, runs off of a simple servo control signal at TTL levels to control those 12v motors. You will want either a marine or robotics model, as the aircraft ESCs are forwards only, and car models usually have a 1-2 second delay going between forward and reverse, making positioning more difficult. However, you are probably better off with the openservo approach, methinks.

Wreno

 

[guyba]

Thanks you all for the suggetions and creative ideas.

We would like persue with one of the 2 suggested configuration - Fanned out or daisy chained. Yet I&quot;m not sure about how the pin configuration and how practically its all wired up. I hope I dont ask for too much but can anyone help me with a circut or schematic diagram of the pin configuration in both cases ? and maybe a sample of code.

This would be much appriciated !!!

Guy

 

[guyba]

I have a feeling that no one saw my last post as, from some reason, the thread was not marked as one that has a new post...

so I&quot;m reposting my question. If I&quot;m wrong and people just dont have the answer for it - please accept my appology for postiong the same question.

Thanks you all for the suggetions and creative ideas.

We would like persue with one of the 2 suggested configuration - Fanned out or daisy chained. Yet I&quot;m not sure about how the pin configuration and how practically its all wired up. I hope I dont ask for too much but can anyone help me with a circut or schematic diagram of the pin configuration in both cases ? and maybe a sample of code.

This would be much appriciated !!!

Guy

 

[BeanieBots]

I think people may be put off giving further advice for two reasons.
First off, it's not something that many will have exact experience of and therefore cannot give first hand advice. (ie the 8X8 as apposed to data comms)
Secondly, your recent questions are bordering on &quot;please do it for me&quot;. The pinout is going to depend on your chosen solution and even then it will largely be down to you to assign which pin(s) you want to assign to the serial comms.

To connect two PICAXEs together for serial comms, pick an output pin on the sender and an input pin on the receiver and connect the two together, job done.
(you also need power going to each chip which just happens to include the common 0v that is also required).

It almost like,
&quot;I want to paint a portrait, should I use oils or watercolour?&quot;

It will be YOU that needs to program the PICAXEs to do their tasks so it needs to be YOU that chooses the configuration (or combination) of the options discussed so far. Most of the pros and cons have been covered.
Have a good read of the programming manual and familarise yourself with the serin/serout commands.

Have you dismissed the open/hobby servo suggestions? This will have an influence on any further suggestions.
Do you have motor controllers? I mean CONTROLLER not just the driver chip. You can't just switch a motor on and wait until some signal comes along and then switch it off, unless the motors move VERY slowly. That is why there was so much talk about SERVOS.

Perhaps come back with some more specific questions that maybe are not so obvious after a bit of familarisation with the product range. People here are always very willing to help but interestingly there is always more advice offered on specifics rather than generalisations.

Edited by - beaniebots on 23/07/2007 18:59:27

 

[sedeap]

***********
Sorry, but looks like too big for me.

but... no one talk about IR management?
because this looks like send one &quot;do&quot; and receive one &quot;ak&quot; back only.

)

 

[moxhamj]

This is a huge project and would take many months and a big budget.

1) Just getting one unit to work is the first step. A two metre throw is a bit of a challenge but one solution could be a stepper motor coupled to a length of threaded rod. It would need a carriage eg two pieces of aluminium pipe. Look at how the carriage works in an inkjet printer. As the load resistance is predicatble, the stepper could go to one end, trip a microswitch then count a certain number of pulses to get to the correct position. I think I would take about 1 week of full time work getting one of these working.

2) Comms from master to each unit. The fanout for a LS or HC chip is 20, so you can do 60 units with a single HC4050 or similar.

3) Comms from each unit to master. This is the complicated part and has consumed long forum posts in the past. The simplest idea is to have no feedback. Each unit gets its signal and has its own picaxe driving its own motor with feedback and each unit is assumed that it gets to the correct position. If you must have feedback of some sort to the master, you can use digital or analog. Digital can be daisy chain or fanout. The fundamental problem with both is the 'hang' with serin, which means any picaxe chip waiting for serin data stops doing anything else, and this means it can't process two serins at the same time. I can explore this in lots more detail if you like. There is a workaround that I am working on at the moment using slow serial comms eg one byte per second sort of speed, and not using serin. A picaxe can then poll a number of inputs and check for highs and lows and convert these into bytes all at the same time. With 8 to 1 lines for a picaxe 18, one could convert 60 lines to 1 line with 9 chips, and HC multiplexer chips will be cheaper than using picaxes. The other option is to use analog voltages rather than digital, and this is by far the quickest comms system as a picaxe can send out analog voltages using PWM and can read a number of voltages using ADC. You could do the analog multiplexing using 4051 chips.

I think the data comms will be the easy bit. The hard bit will be getting just one of these units to work and then minimising all the costs and simplifying the build so that 60 can be built in a reasonable amount of time.

Edited by - Dr_Acula on 24/07/2007 00:38:04

 

[kranenborg]

Hello Guy,

Just returned from holiday, hoping that this thread has not died completely ...

Interesting project of yours, and if you are still considering serial comms as a solution an adaptation of my &quot;SerialPower&quot; network implementation may be useful. The link to it is given here <A href='http://www.kranenborg.org/ee/picaxe/twowirenetwork.htm ' Target=_Blank>External Web Link</a> (note the link to the pdf document on the site) and it combines two concepts:

1) A serial protocol for communication between nodes (actually, between processes on nodes, bidirectional)
2) Hardware to provide both power and communication on a network of just two wires (your project will not combine power and comms on the same lines, but the hardware of the nodes is still largely appropriate, see below)

For your project I could imagine that:
* Each slave node contains a cheap 08M controller implementing the SerialPower network stack
* The master node driver circuit is used unchanged (because the hardware driver of the master node will allow a large capacitance (i.e. lots of nodes) to be driven (I tested my implementation, it drives 0.1uF (100 nF) of network capacitance without problems) )
* The network communication protocol can be tailored for your application (e.g. sending 4 numbers in each communication frame)
* The network allows slave-slave comms.

Please indicate if you are interested in further discussions

Best regards,
Jurjen
http://www.kranenborg.org

Edited by - kranenborg on 30/07/2007 23:19:39

 

[moxhamj]

Hi Jurgen, I spent a few hours last night putting together a 6 page discussion paper on picaxe networks. My conclusion at the end is not that there is any one perfect network, but rather how to build picaxe routers to interface between various networks. Your network sits in amongst other networks (eg wireless, ultra slow speed serial). I'll turn the word document into html and put it on the web in the next day or so.

My experience is that when more than 10 nodes go on a common bus, data clashes become more common. Thus for interfacing 60 nodes, I might suggest 6 bus lines with 10 nodes on each bus. The bus can be your two wire system. The more detailed discussion is how to route signals between busses, and this can be done by using a xx.yy numbering system for each node, where xx is the bus number and yy is the device number. These numbers appear in the data packet header and tell routers which bus to send the packet to. Thus a packet going from bus 2 to bus 4 does not need to be transmitted to any other busses, and thus lowers overall congestion.

I'm pulling together my experience interfacing with PC to single wire buses, your network, interfacing to the internet, and Stelios' direct RS232 to internet router. An idea that is developing is to build a data packet protocol similar to TCP/IP where every picaxe device has a unique address and if a network is connected in some way to the internet, any picaxe device can communicate with any other device anywhere in the world.

Packets would have a unique random 16 bit header, source ID number, destination ID, number of bytes, bytes and checksum.

I think I might also have a solution to the SERIN hang problem on 1 wire busses. Essentially, any sensor picaxe on a 1 wire bus can either be sensing its environment or listening to the bus but not both at the same time. If the sensor is going to send 'acknowledge' signals it needs bi-directional comms. A solution is for all SEROUTs to the bus to be preceeded by a 1/2 second high. All devices on the bus periodically look for this high and if the line is low, they go back to their tasks. Only if they find a high do they execute a SERIN.

Some more brainstorming might be needed here as one needs a scaleable modular reliable system for 60 devices.