Society of Robots - Robot Forum

General Misc => Misc => Topic started by: Trumpkin on April 22, 2009, 06:49:43 PM

Title: Community Project - Module Housing
Post by: Trumpkin on April 22, 2009, 06:49:43 PM
Here are my ideas for housing of modules for the community project:
#1 (see cube.png which is an example of a servo module) Each module is housed inside a cube with four metal plates on each side for power and the i2c bus. problems would be:
hard to keep all plates in contact
plates could be easily bridged
#2 Same as #1 but instead of plates you could use 4 bolts that would supply both a mechanical connection between the cubes and an electrical connection.
I think It would be really cool if we could build the housing for the modules in such a way so that you wouldn't need a chassis. Does any of this make sense or am I going off in the completely wrong direction? Feel free to post your ideas in this thread.   
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 22, 2009, 06:54:19 PM
i thought we were just having boards that are stackable via standoffs, i didn't know about the block thing? i don't really think it would be logical as there are too many ways something could go wrong with this, ie. someone places block upside down and boom, gets placed on a piece of metal accidentally, the robot goes over bumpy terrain and they come apart... in general this is an alright idea but i really cant see it happening because of some peoples weird requirements.
Title: Re: Community Project - Module Housing
Post by: Ro-Bot-X on April 22, 2009, 10:43:47 PM
I like the idea of having inteligent cubes that house a microcontroller, a motor, sensors, perhaps even a small LiPo battery. Teoretically we could use them to create more complex robots, eventually something like the Replicators. However, technology is far away from that. Something with limited movement and conectivity can be created, but for now conectivity is an issue. Most of the designs I've seen use a second smaller motor for locking the cubes together.

Get a servo, sandwich on one side a LiPo, on the other side a distance sensor, light sensor or whatever, mount it in a lightweight cube, have the contacts like circles on the sides something like this: center - power for charging, next circle SCL, then SDA, then at the exterior GND. This will leave the corners for locking cubes - need some locking mechanism ideas here. The microcontroller can be a tiny85.

Now these cubes or whatever shape they'll be are appendages. There has to be a brain cube, and perhaps a vision cube, but they can be fuzed together in one. Other cubes can be wheeled cube, gripper cube... Also some cubes may bend and others rotate.

This way a complex robot can be built from this cubes and programmed to re-shape itself when it is appropriate, it can walk, or drive, or both...
Title: Re: Community Project - Module Housing
Post by: madchimp on April 23, 2009, 01:22:01 AM
As neat as the cube idea would be.. I think it would drive cost way up and make it less flexible. I think if you guys want to do the cube idea awsome, you should go for it but it should be a another project based on the modules created from this project. I do like the idea of having some sort of plastic housing though. I can't remember where or which thread but someone brought up the idea of using rj45 connectors or something similar between the modules which I though was a pretty neat idea. I think having plastic boxes that can be connected with some sort of basic plug system would be far less intimidating for new users. I also think the modules should be designed so they can be used without the enclosures as well. If this project were to make a certain style enclosure popular and inexpensive it might also get other people to design their boards to fit in them, creating a standard for board sizes. What I kind of envisioned for the housing would be a three piece unit the top, bottom and the sides as one unit. Then if you wanted to stack say two modules in the same location on your robot you use one bottom two side units stacked and then the top cover.  I also think using the axon as a basis for the size of the boards is a good idea, because it's already out there. The axon could be considered a full board then you could have variants on that like a quarter board half board and even boards one and a half times the axon. (also from someone else somewhere in the threads) If we do that then we already have the sized figured out hole placement is already sorted and the dimensions are already posted on this site. I'm sure I left something out but I'm getting tired and I just hope what I wrote is coherent lol.
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 23, 2009, 05:41:35 AM
this is an alright idea but i have to agree with madchimp about the expenses, i think it if were to do this at all we should build the modules first and if they're popular take a look at boxes.
Title: Re: Community Project - Module Housing
Post by: dellagd on April 23, 2009, 06:27:01 AM
Here are my ideas for housing of modules for the community project:
#1 (see cube.png which is an example of a servo module) Each module is housed inside a cube with four metal plates on each side for power and the i2c bus. problems would be:
hard to keep all plates in contact
plates could be easily bridged
#2 Same as #1 but instead of plates you could use 4 bolts that would supply both a mechanical connection between the cubes and an electrical connection.
I think It would be really cool if we could build the housing for the modules in such a way so that you wouldn't need a chassis. Does any of this make sense or am I going off in the completely wrong direction? Feel free to post your ideas in this thread.   

magnets?
Title: Re: Community Project - Module Housing
Post by: Asellith on April 23, 2009, 06:53:54 AM
The beauty of this project is just like an open source software project it can be taken in several directions by different people. I think if someone was to find a premade mass manufactured module housing then great let us know it will go in the documentation. If someone wants to design a stackable custom enclosure that clips together and has either space for ribbon connectors to the different boards or as was mentioned earlier something like an RJ12 or RJ45 connection to link them then great. A good enclosure design could help but shouldn't be mandatory.

A good design would be something as modular as the modules (that sounds weird) Anyway. If you design the enclosure to clip to each other in every direction then it could get really cool. So you can have a grid of 4 modules all clip together in a square that then by flipping over and screwing the modules in upside down will let you stack another set of 4 on top to "close" the box. That might be really cool.
Title: Re: Community Project - Module Housing
Post by: HyperNerd on April 23, 2009, 10:48:26 AM
Has anyone seen the Servo Erector Set from Lynxmotion? (http://www.lynxmotion.com/Category.aspx?CategoryID=73) What if we made some modules that fit the hole pitch on those parts, so the frame of the robot could be made very easily, and changed if necessary.
I agree with the idea of RJ45 connectors on the modules, as that gives 8 wires to use for whatever purposes need be. The Lego Minstorms NXT is a perfect example of a module based system, and I love it so much I bought 2 kits!

 -HyperNerd
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 23, 2009, 03:45:05 PM
this is actually starting to seem like a really good idea to me, but if this is for noobs and we have a lipo battery that can easily be connected wrong.... if we are going to do this we need to make then polarized otherwise they could be screwed over in 20 seconds.
with the plate idea, would all four sides be the same, ie. power- power+ i2c i2c?
but what about all the unused ports on the axon? if we encase the axon in a case the user can use any of the axons I/O ports. this may drive hobbyists who are more advanced away from it.
would it be appropriate if the axon was on top of one of the boxes using standoffs and the I2C cable running into the box contacting the plates, that way you can still access the programming pins/usb and all the I/O.
Title: Re: Community Project - Module Housing
Post by: dellagd on April 23, 2009, 06:02:51 PM
my idea was to have the 4 plates and magnets like this
it would hold it on and also because of the 4 plates the battery cant be hooked up wrong.
we would also have lots of diodes for protection
Title: Re: Community Project - Module Housing
Post by: Razor Concepts on April 23, 2009, 06:07:08 PM
Isn't this like sort of like designing the shape of a car before actually figuring out how to fit all the engine and electronics in it?
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 23, 2009, 06:20:51 PM
yep, that's pretty much it. as i said though, i think we should design the modules and get them working on pcbs before thinking about this.
Title: Re: Community Project - Module Housing
Post by: dellagd on April 23, 2009, 07:03:58 PM
think  we should start a new post for designing the PCBs and electronics?
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 23, 2009, 07:06:40 PM
yes, but shouldn't some of these topics be in other sections? like this one in mechanics?
Title: Re: Community Project - Module Housing
Post by: dellagd on April 23, 2009, 07:11:48 PM
yes, and the PC board topic in electronics
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 24, 2009, 12:34:52 AM
i was thinking about some ideas for this today and was wondering about the flexibility of these "boxes"... will there be any way to change something on the pcb if something were to go wrong? or if we needed to reprogram the chip? anyway, i was thinking of a hinge system with some kind of catch so the lid wouldn't just fly open any old time, what do you guys think of the idea to be able to open the boxes to change/repair the modules?
Title: Re: Community Project - Module Housing
Post by: Trumpkin on April 24, 2009, 07:58:18 AM
I was planning on the boxes being able to open. Just a hinge on one side and a screw on the other should do it.
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 24, 2009, 03:17:08 PM
yea, that'll be great as it allows people to do mods/put new electronics in their boxes and let them connect up.
and dellagd, to your pic a few posts back, there is power bus down the bottom then there's also the colored dots... do they both carry the bus?
Title: Re: Community Project - Module Housing
Post by: dellagd on April 24, 2009, 04:05:30 PM
the 4 circles with blue and red are magnets
the + and - are positive and ground
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 24, 2009, 08:55:42 PM
ahh i see how it works now! but i think there should be a way that prevents you from physically plugging them in the wrong way, like a socket in each corner with a distinctive shape to it.
Title: Re: Community Project - Module Housing
Post by: dellagd on April 25, 2009, 08:49:14 AM
I see what u mean. give me a sec I'm skteching it up.
like this?
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 25, 2009, 03:46:45 PM
well, not the plates themselves but more a bolt that will sit there. but is removable by just pulling.
attached is a general image of what the boxes will look like.
Title: Re: Community Project - Module Housing
Post by: dellagd on April 25, 2009, 05:12:28 PM
cool!  ;D looks like a good idea to me
Title: Re: Community Project - Module Housing
Post by: Trumpkin on April 25, 2009, 06:20:00 PM
Quote
attached is a general image of what the boxes will look like.
Don't mean to be rude but if you think about it that won't really work since you could only plug male into female, it doesn't look very professional either.
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 25, 2009, 06:22:42 PM
gahh! just an idea... brainstorm people! im generally not too good at designing things :(
Title: Re: Community Project - Module Housing
Post by: dellagd on April 25, 2009, 08:01:22 PM
this project is still in the designing stage. all we are doind here is ideas. nothing is final.
Title: Re: Community Project - Module Housing
Post by: HyperNerd on April 26, 2009, 06:35:58 AM
I think Trumpkin has got a point...
The connectors could only be plugged in one way round, so some modules would end up being the wrong way round.
(Anyone remember the wooden train set you played with as a kid, and how annoying it was when you ended up with two ends that had the same connector on them)

So, here is my intended (although complicated) solution:
The module is a box on its own. On the side of each module is a ring of 8 spring loaded protrusions, 4 contact rings, and a pivot point dead in the center. A plate / circuit board consisting of the magnets, I2C connection plates, and a matching ring of contacts on the back. 8 holes are drilled in the board, which line up with the 8 protrusions on the module. The board is then mounted to the pivot point.
This maintains the polarised nature of the magnet / plate combo, but allows the module to be rotated and locked at 45o intervals, so it would not face in the wrong direction.

Confused? I don't blame you. Here are some sketches to clarify.

 -HyperNerd
Title: Re: Community Project - Module Housing
Post by: dellagd on April 26, 2009, 06:53:53 AM
I like it
the more flexible the better
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 26, 2009, 07:09:57 AM
Maybe making these things would be easier if they used simple magnets to connect physically together. If the plastic was transparent to IR light, then a simple asynchronous IR link could be made between neighboring blocks.

I think it would be prettier and simpler. We are electronics guys after all, try to reduce manufacturing complexity for electronics hardware.

No physical problems with connection orientation and male/female connectors either.
Title: Re: Community Project - Module Housing
Post by: HyperNerd on April 26, 2009, 12:36:18 PM
That is a very ingenious idea, but what about power connections?

Anyway, if IR is used, here is my contribution to the hardware/programming aspect of all this (the word 'node' may be used interchangeably with 'module' or 'block'):
Hardware:
Each node has a unique ID consisting of a 8-bit type code plus an 8-bit ID number, resulting in a 16-bit word which is unique to that node only.

Software
Reset
Host controller sends an 'ID' command to the modules connected directly to it, which then repeat this process to all the modules around them. (I am assuming all 6 sides of the cubes can communicate)
Each node builds up a code of all the nodes around them, and sends this to the node who issued them the 'ID' command. This results in the host controller knowing exactly which nodes are connected, and where they are in relation to each other. This map is then forwarded to every node in the network.

Message
When a message needs to be sent to say, the motor controller node (identified by it's unique 16-bit ID), the host uses a wavefront pathfinding algorithm to detect which nodes the message must pass through to get to it's intended target. This is a possible message structure:
[header]
source node ID
destination node ID
[body]*message data*
When the message passes through a node, the node sends back a confirmation byte to the sending node, following the same path as the original message.

Error
If a node is removed from the network (disconnected), when a message is to / through that node, the sending node will not receive a confirmation byte from the removed node (obviously), and will therefore send a command to the host controller, telling it to rescan the network, so a new layout is calculated.

What do you think guys?

 -Hypernerd
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 26, 2009, 12:55:57 PM
Well in order for the modules to be truly modular, they must be able to function alone. ie they all need their own power supply. Mini lipos in each would be cool. Maybe even the mechanical parts of the cubes could be internal, with a magnetic coupling linking them. 
Title: Re: Community Project - Module Housing
Post by: TrickyNekro on April 26, 2009, 01:16:41 PM
Mini Lipos is equal to a lot of trouble.......... no no......
Title: Re: Community Project - Module Housing
Post by: HyperNerd on April 26, 2009, 01:19:45 PM
The one problem i can see with that is if one module runs out of power before another, ie, the GPS dies and the robot goes into spasm because it has no idea where it is anymore.
Title: Re: Community Project - Module Housing
Post by: TrickyNekro on April 26, 2009, 01:32:25 PM
LiPo need external circuit to operate.... correctly...
Voltage drop too much they are dead......
And I'm not even speaking about high currents...
Also... you need to embed a charger...
Devices running out of power is the least I can think...
You could have a switching regulator or so to do your job....
Plus another battery types ARE heavy....
Autonomous modules aren't recommended at all.....

Basically... we must do thing about the modules first....
Let's say we need a motor controller first... then other things....
We also need a serial LCD module...
We need a time keeping module... or LCD and time module together, so it can also operate as a clock???
A current sensing module...
A voltage sensing module....
Basic things....

I know sometimes you want to have your head to get high....
I do want to make a convertible airplane (airplane to robot, Macross style baby!!!)
But, hey... I do study DSP programming and control theory right now...
What I want to say is... step by step... you aren't gonna do anything if you want to jump from A to W....
You may do something if you jump from A to C but still... you don't know where B is hidden....

Again... Think of basic things first....
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 26, 2009, 02:04:36 PM
Yes it is a bit far-fetched, but I find that dismissing technical limitations for the first stage is an excellent way to come up with some great innovative ideas. While most may be unachievable, you might find one or two that are within our grasp.

I also study DSP and control theory... and hmmm, i always like to fantasize a bit before becoming serious :P
Title: Re: Community Project - Module Housing
Post by: Ro-Bot-X on April 26, 2009, 07:35:10 PM
If LiPo batteries are so dangerous, why all cell phones use them? Is it so hard to use a cell phone battery in each cube? These batteries have a built in protection circuit.

All cubes should be independent. Some will need more power and others less. The purpose of the power connector is to supply power to the cubes that are more power hungry and for charging. There is no need to have a built in charger. A single multi cell intelligent charger could charge all cubes at once through the power rail.

I would build the cubes with a servo motor that is more like the NXT motors. That means a geared DC motor with a quadrature encoder. It can be used to position and hold that position just like a regular servo or it can be used as a continuous rotation motor. A switch could be activated at a certain position to establish a home position for the motor an perhaps to count the completed rotations. The motor controller should use locked antiphase method, this way it can directly adjust the PWM acording to the encoder error, applying more force to the motor as the position is forced to move harder. If the motor is no longer needed, the power to it can be cut off to minimise the consumption.

Also there should be 2 types of motor cubes, one with a bracket and one without. The first type could be used to make pivoting joints, the second type could be used to make rotational joints or driving.

As for the connections, I would use something like a darts target. The center for power, next ring for SCL, next ring for SDA and outside ring for ground. No matter how you twist the modules they will connect properly. In the corners I would use a twist and lock mechanism, something with hooks in a groove and a spring tensioned ball that would protrude in a hole on the oposite module to minimise the accidental disconnecting.
Title: Re: Community Project - Module Housing
Post by: Razor Concepts on April 26, 2009, 07:37:39 PM
Having a lipo/charging circuit in each cube might be a little cluttered. Maybe just have a single "power cube" that supplies power to all other cubes.
Title: Re: Community Project - Module Housing
Post by: TrickyNekro on April 26, 2009, 07:51:18 PM
Having a lipo/charging circuit in each cube might be a little cluttered. Maybe just have a single "power cube" that supplies power to all other cubes.

Exactly
Title: Re: Community Project - Module Housing
Post by: dellagd on April 26, 2009, 08:00:30 PM
I like the power cube idea, but instead of a twist and lock thingy why shouldn't we just do the original idea. holes and pins that go in those holes to keep it from rotating, then some shielded rare earth magnets (so they dont interfere with the electronics, assuming this is even possible  :P )
Title: Re: Community Project - Module Housing
Post by: TrickyNekro on April 26, 2009, 08:04:00 PM
Have we found desired protocol...
I think you suggested TWI....... But I think UART is better.... :p
Title: Re: Community Project - Module Housing
Post by: madchimp on April 26, 2009, 08:40:44 PM
I'm assuming the idea of this being for beginners has been dropped? I highly doubt any beginner unless they have money to burn is going to buy modules costing what these are heading for. For example a cell phone battery in each one? The last time my battery in my cell phone quite holding a charge it was cheaper to buy a new phone!
Title: Re: Community Project - Module Housing
Post by: TrickyNekro on April 26, 2009, 08:52:51 PM
There are Lipo's that don't cost more that 5 - 7$ but these are only for power devices like mp3s or so....
no big deals...
But problem with Lipos is that, (hey ok... I didn't say they explode so easily!!!)
but to operate right... a lot of times.... aka recharging them beautifully...
external circuitry is required...
Also.... I don't enjoy that cube idea.... more cost for nothing...... (only housing????)
Simpler housing method and hey... I got quite used to ATMEL's 10pin (2X5 pin headers)
A full port with power..... Just.... VERY NICE!!!! And practical once you get used to it....

So..... hey guys.... I tell you again... be practical... We don't even know what these cubes will have into them...
Usually package is the last thing a manufacturer worries about.......
Plus getting a battery on each unit????? I'm sorry... But where did you see that????
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 26, 2009, 09:29:47 PM
thanks lefteris, i agree that having a battery on each unit is wayyy out of league and unnecessary, i mean, what would happen if john smith wanted to recharge all his cubes at once but only had one charger! im still thinking that the master should regulate the voltage to the modules @5V via a 4pin connector as not many modules will use more than 5V as the usual voltage needed is either 5V or 3V3. the battery cube is an alright idea but we want these modules to be flexible to peoples needs. what if i had 5 7V2 ni-mh packs laying around, i wouldn't want to go buy a battery cube just so i can run my modules would i? keep these things in mind when thinking up ideas as most hobbyists like us don't have cash flying around our living room do we?
The idea for these modules was to create a set of modules that could interface, be open source and of coarse, cheap!
Title: Re: Community Project - Module Housing
Post by: dellagd on April 27, 2009, 05:47:21 AM
we could simplify it by instead of having metal rings, we just have male, feamale connecters, like the ones on servos, then some magnets to hold them together, madye some latches too.
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 27, 2009, 06:08:40 AM
Actually i am confused about the objective of this project.

Are we building a modular robotics platform? i.e. a load of modules with different functionalities.

Or are we creating a modular robot? i.e. where each module has the same functionality, but when grouped together, they can do more (I swear i saw this youtube video (www.youtube.com/watch?v=VyzVtTiax80 (http://)) posted in a community project thread...) Anyway the idea of the modules interconnecting in such a way is being discussed here.

If the idea is a robotics platform, then great! But i don't see where the cube idea fits in...

(Hmmm.... how do I post a hyperlink to a youtube video without it embedding...)
Title: Re: Community Project - Module Housing
Post by: dellagd on April 27, 2009, 06:15:49 AM
yes I did post that in the master thread
As far as I know, we are making different modules that communicate with eachother through I2C
thay have magnets on them to stick together and can, as long as they are connected to the I2C rails (+ ,GND, SCL, SDA)
can be put in any configuration you want.
the robot desnt morph itself, you put it in a configuration
there will be accelerometer moddules, servo moddules

hope I have this right too
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 27, 2009, 06:26:21 AM
Then i think that using a structure like a cube would severely limit the flexibility of the platform...

For this, we just need nice circuit designs, nice software, nice documentation and tutorials. The people using the platform would just pull up the circuit design, make it, program it (if required) and then use it,

Emphasis on the designs should be placed on -

Maybe my silly idea of magnets and IR links before was a bit silly. But now i think we have something more achievable, i'm quite enthusiastic!
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 27, 2009, 06:49:34 AM
Then i think that using a structure like a cube would severely limit the flexibility of the platform...
i was worrying about this as is would limit the amount of space you have left if you have some clunky cubes laying on your robot and it may limit users interest.
although i think the idea of morphing robotic cubes is an alright one at that, it is a bit far-fetched, and would be quite hard to achieve by a small group of hobbyists (no offense ;) ) if this were to be open source i would like it to be easy to whip up a few modules on a bread/pc board without too much knowledge so beginners don't run for the hills :o
just a question, what does a servo controller do? sorry for noobish-ness, never used one :-\
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 27, 2009, 07:09:29 AM
The controller acts as a layer of abstraction away from the PWM.

It would communicate over I2C and instead of sending PWM signals (and bothering to work out the length of the pulse etc...), you just send a message which tells the controller to set the servo to a certain position.

The advantage... modular, just add as many servos as you want (up to 111 on I2C).

It could also be extended to other more advanced functions. e.g. you could send a command to change the angle linearly between 10 and 90 degrees, over a period of 10 seconds.
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 27, 2009, 07:12:35 AM
ahh ok, thanks for that ;D and i thought it was 127 on the I2C line?
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 27, 2009, 07:23:26 AM
Well there are two sets of eight addresses which are officially reserved on I2C. For sending things like a message telling modules that 10-bit addressing is being used etc. Others are reserved for future expansion.

We could ignore these (and tbh probably will) but 111 is plenty anyway.

Oh heres a good link - http://www.totalphase.com/support/kb/10039/ (http://www.totalphase.com/support/kb/10039/)
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 27, 2009, 07:33:38 AM
your probably right anyway, but if someone needs more than 111 modules i shall fear what they are building...
Title: Re: Community Project - Module Housing
Post by: TrickyNekro on April 27, 2009, 07:50:05 AM
I just don't like the I2C idea cause of some though I have......
It's basically the equality you seek among the modules...
In TWI it's more like master - slave things...
But when using UART you can really use "software" device addresses...
Plus you can manage all devices to be equal with a timeslot system...
Plus... It's extremely easy to prob with a PC....
So you can see if what you think you've been sending is actually correct....

That's my thoughts....

And, I don't know if that also happens with I2C but you can issue a baud boost when all devices
can operate with higher bauds....

Thing is, that the idea of a "power cube" - "main processing unit" - "rooter" is needed....
So... guess what... we must build and ALL agree first on a transmitting protocol, then the
peripheral used for this materialize this protocol...

So hey guys, equality is good, but has responsibilities "aka woman want to be equal but most
of them think they play Carmagedon went driving out on the road.... shit...."
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 27, 2009, 08:06:03 AM
I think I2C is perfect for this.

All robot systems have at least one 'brain' or main controller which naturally acts as the Master. I2C is a multi-master bus so if you seek more equality between modules, then you can set them both to masters.

The master-slave configuration is really neat in some ways though. The hardware/software required to implement a multi-master node is more complicated than the equivalent on a slave-only node. This means that, for things which would never need to initiate transmission (i.e. a servo module) we could use a slower, smaller and cheaper MCU.

Baud boosts don't make sense with a sychronous transmission. The modules will all communicate at the rate of the clock signal. Normally it is 100kbit/s but can probably be pushed to 400kbit/s

I2C is designed for this by the pros at Philips, i think it is definitely the way forward!
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 27, 2009, 08:16:09 AM
I2C has seemed like a good way to go from the start (no offense tricky) especially the fact with the master/slave configuration making it easier to "play with".
Title: Re: Community Project - Module Housing
Post by: HyperNerd on April 27, 2009, 10:16:55 AM
Did anyone take a look at my previous post (http://www.societyofrobots.com/robotforum/index.php?topic=7721.msg59830#msg59830)?

I think my idea is perfect for the the Master / Slave nature of I2C.


Here is my response to various ideas being tossed around:
@power cube
I like this idea, but I think it should be flexible, allowing the user to change the battery for something with higher capacity if needed.

@breadboard customisation
How about a breakout cube with a breadboard mounted in the top, and an interface connector allowing access to all of the breakout cube's processor's I/O pins?


And now for my own contribution:
I don't know how well bootloaders are suited to I2C, but what if we made a programmer cube, with a USB bootloader and huge EEPROM (like 2MB or something), and all the other cubes have I2C bootloaders.
When the user wants to program his creation, he plugs in the programmer cube to his computer, and uploads the program to the programmer cube via USB. The programer cube then stores the entire program (all the separate module programs combined) in it's huge EEPROM.
The programmer cube then sends each part of the program to its respective cube via I2C.
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 27, 2009, 10:44:01 AM
Oh... another reason to not use cubes... Circuits are usually best contained within a shallow rectangular box. There were either be a huge waste of space, or our circuit layouts would be more complex.

Power module sounds great. I like the idea of someone designing a high-current 5V using a switching regulator. A tutorial on winding inductors would be great with that.

Hmmm the programming of each module is a problem we need to solve... But one thing, we should only need to program a module's MCU once. The module software should be well tested and all the bugs caught (if we keep the module simple then there won't be many). Then the module is finished.

Examples of modules i can think of are

I like the idea of extremely simple modules. It might be tempting to use all the IO on a chip, but the smaller the better i think. Hmmm what do you guys think? If we use PICs... they we can use the small 8 pin PIC12Fs that wouldn't be too much of a waste.

Anyway, if any of you require more complicated modules (ie multiple servo module) then there is obviously a requirement for it and you can design one.
Title: Re: Community Project - Module Housing
Post by: TrickyNekro on April 27, 2009, 11:01:32 AM
I just say that a chaotic UART network is better....
Our problem isn't speed of course, both protocols have close speeds...
UART requires more coding for sure... And.... ok.... if you prefer I2C it's your shot after all....
But don't think I2C requires less coding in a multimaster system......

It may be easier for some applications using I2C.... but still I support that it should be used as a secondary bus....


PS... Smash... no offence...we simply talk here and display our ideas...
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 27, 2009, 11:28:41 AM
Well normally i would be quite 'up' for reinventing the wheel. I learnt the little bit that i know by doing it :P But with a project which could be so influential in the growth of SoR and hobbyist robotics, i think we should use the tried and tested method.

USART is designed for communication between two nodes. I2C is designed for a network of nodes. Modularity is ingrained in I2C.

Another thing... there are a lot of sensor modules which use I2C as their primary method of reading out measurements. Using a different communication protocol would mean we would need more intermediate modules (e.g. an I2C to SoR-USART module), just increasing the complexity.  The wide availability of I2C compatible hobby electronics means that choosing something else essentially alienates a huge existing resource.
Title: Re: Community Project - Module Housing
Post by: TrickyNekro on April 27, 2009, 12:13:58 PM
Yes... I know that about the modules........ whatever... I2C if that is.....
Title: Re: Community Project - Module Housing
Post by: dellagd on April 27, 2009, 02:17:53 PM
I like the idea of having a node that is just a breadboard and I/O pins. correct me if I am wrong. I2C is like a network that allows microcontrollers to communicate with eachother?
Title: Re: Community Project - Module Housing
Post by: Asellith on April 27, 2009, 04:03:40 PM
The point of using I2C is to make it plug and play well sorta plug and play the main controller needs to be told what to do and if the programmers of the modules do the extra work and develop libraries for each then it is the MCU version of plug and play. This I/O board you want will need to be able to talk to the main controller some how. The main MCU will have a limited range of I/O on its board. Be it the axon or a whatever. An I/o Extension board is not a bad idea but it will still need an MCU to talk to the network. I/O interupts can be messy when using with a mapping program or something along those lines. But if the interupts where handled by their own I/O module and the only thing that happened would be the I/O board would take control of the bus and send info to the main controller when needed. Or if all it does is a programmed motor response then the main mcu just needs to be told it happened and it can go on mapping the room or whatever it is doing while the I/O board talks to the motor controller.
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 27, 2009, 04:32:47 PM
i am really happy to take a look at uart, but it just seems more complicated for beginners to get a grasp on.
about the programmer issue, i really think usb should be a standard or some form of communication that lets usb take hold, maybe a 4pin header the user can plug into that has usb on the other end? most people don't really want to buy a programmer as the good ones are a bit expensive or they don't have a serial/parallel port...
Title: Re: Community Project - Module Housing
Post by: dellagd on April 27, 2009, 05:02:18 PM
a MCU can also be a slave on a  I2C network right?
Title: Re: Community Project - Module Housing
Post by: Asellith on April 27, 2009, 05:07:01 PM
Yes actually most modules will be slaves. There will be very few modules that will not have some sort of MCU on them.
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 27, 2009, 06:31:59 PM
so, the "master" is the  device that is allowed to request info from the other devices. a "slave" not not allowed to request anything but only reply to a master. this is why slave devices are much easier to code because all thy have to do is the dirty work and reply to the master. and i thought for i2c all modules would have to have a microcontroller of some sort if they weren't pre-bought?
Title: Re: Community Project - Module Housing
Post by: dellagd on April 27, 2009, 06:43:39 PM
I am pretty sure you are correct smash
Title: Re: Community Project - Module Housing
Post by: TrickyNekro on April 27, 2009, 07:29:14 PM
having more than one master on the bus requires protocol.... that's for sure...
And implementing a com protocol isn't for absolute vodkas....... :P
Title: Re: Community Project - Module Housing
Post by: Asellith on April 27, 2009, 08:49:35 PM
I2C is a protocol. It inherently handles multi-master. Each unit master and slave have an address. Only difference between a master and a slave is the ability to take control of the bus. Each node waits for the bus to be clear and then takes control by initializing the start bit sequence. Then it transmits its messages and waits for its response. The slave just wait for a master to tell them what it needs them to do and they send back an ACK with or without data depending on what the slave is doing. Any master can take control as long as the bus is not being used.
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 28, 2009, 03:08:24 AM
so, to sum it up. the reason I2C is a good interface to have is because its faster than just using I/O pins because the other microcontrollers (slaves) do all the time consuming and repetitive tasks then let the master take care of the decision making?
and, psssst guys this topic is about the module housings! not communication protocol. if you see needed start a new topic about that ;)
Title: Re: Community Project - Module Housing
Post by: TrickyNekro on April 28, 2009, 05:08:04 AM
Even though you "have" a I2C protocol it's not the protocol I talk about...
Imagine multiple masters co-existing in a same bus....

There MUST be a router that sets the timeslots for each to speak, then the speaker should inform
how much he will speak and with who....

I2C is a method of transmitting data, not a way to behave in public places...
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 28, 2009, 05:23:15 AM
Multi-master I2C requires no router or time-slotting.

Either one master starts transmitting and the others be quiet, or multiple transmitters start transmitting at the same time and they have a 'race'. The winner of the 'race' is the master which sends out a message with the most zeros (ie the lowest message byte). Each of the other masters realise that they didn't win the 'race' and then they wait their turn.
Title: Re: Community Project - Module Housing
Post by: TrickyNekro on April 28, 2009, 05:27:40 AM
Am I confusing something or data collision is a hole in water for every device???
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 28, 2009, 05:28:55 AM
Am I confusing something or data collision is a hole in water for every device???
explain?
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 28, 2009, 05:35:05 AM
ok the data lines are pulled up. So to clock data out, the devices either let the line go and it will be pulled up to +ve (for a 1 bit), or they pull the line down to negative (for a 0 bit).

Say master 1 wants to transmit byte 00101001 and master 2 wants to say 00100101

First both say 0 - they have no way of telling that there is another master on the line so they both carry on.
Again both transmit a 0 - again no way of detecting another master
Both transmit 1 - still no way
Both transmit 0 - "
Master 1 transmits 1 letting the line go free, master 2 wants to transmit a 0, so it pulls the line to ground. The line actually is in '0' state. Now master 1 can detect another master on the line. So it quits and waits its turn. Master 2 is oblivious to this and carries on happy.

The byte which is transmitted is 00100101.

The nice thing is, if both transmit the same bytes, they never realise and they don't need to realise. So its doubly quick compared to a time sharing system :D But thats a very extreme case...
Title: Re: Community Project - Module Housing
Post by: dellagd on April 28, 2009, 05:38:20 AM
I am confused here too
of course it would be better if they just had a race (I rooting for master #2  :D )
but I think Tricky is right. 2 signals can't travel on the same line as far as I know.
but hazzer could also be right. I just don't know enough on the subject to make a definitive answer. also we really need to move this conversation. Right now I am making a new topic "SoR Project - protocol".

EDIT: now I get it. makes sense. I see what you mean hazzer. I post just as you were :P
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 28, 2009, 05:40:23 AM
so your saying there would be no problem with them interfering with each other?
and as i said before this thread is called "module housing" for a reason! http://www.societyofrobots.com/robotforum/index.php?topic=7778.0 (http://www.societyofrobots.com/robotforum/index.php?topic=7778.0)
post this kind of stuff there!
dellagd, imagine two fat guys (masters) running to get into an elevator (line) which ever one gets in first gets in... the other fat guy realizes that the other guy is in the elevator and waits for it to come back (finish transmitting). sorry, needed an easy way to remember...
EDIT: oh shiz, dellagd beat me to it
Title: Re: Community Project - Module Housing
Post by: dunk on April 28, 2009, 06:51:00 AM
ok the data lines are pulled up. So to clock data out, the devices either let the line go and it will be pulled up to +ve (for a 1 bit), or they pull the line down to negative (for a 0 bit).

Say master 1 wants to transmit byte 00101001 and master 2 wants to say 00100101

First both say 0 - they have no way of telling that there is another master on the line so they both carry on.
Again both transmit a 0 - again no way of detecting another master
Both transmit 1 - still no way
Both transmit 0 - "
Master 1 transmits 1 letting the line go free, master 2 wants to transmit a 0, so it pulls the line to ground. The line actually is in '0' state. Now master 1 can detect another master on the line. So it quits and waits its turn. Master 2 is oblivious to this and carries on happy.

The byte which is transmitted is 00100101.

The nice thing is, if both transmit the same bytes, they never realise and they don't need to realise. So its doubly quick compared to a time sharing system :D But thats a very extreme case...
hu?
sorry Hazzer but no.
in a multimaster i2c system a master that wants to take control of the bus takes control of the SCL line.
if the SCL line is high and does not have another master's clock pulse on it then any master can presume the bus is free.
any master can pull the SCL line low for a clock pulse signaling to all other masters that the bus is busy.
on vary rare occasions 2 masters might take control of the bus at exactly the same time so testing for this must also occur.

TrickyNekro, i think this answers your questions too.


dunk.
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 28, 2009, 06:55:46 AM
Hmm u sure? I have seen the system i described in a different protocol. And from this page (http://www.i2c-bus.org/MultiMaster/) it seems the same.

Ahh well, i guess the important thing is that it supports Multi-master and is implementable.

EDIT: maybe the thing i read is the way to sort out the rare condition where they take control at the same time.

EDIT2: Oh.. here is some more info - http://www.esacademy.com/faq/i2c/general/i2carbit.htm (http://www.esacademy.com/faq/i2c/general/i2carbit.htm) -  it's called arbitration -

 I'm quite sure now that i was correct...
Title: Re: Community Project - Module Housing
Post by: dunk on April 28, 2009, 07:15:45 AM
EDIT2: Oh.. here is some more info - http://www.esacademy.com/faq/i2c/general/i2carbit.htm (http://www.esacademy.com/faq/i2c/general/i2carbit.htm) -  it's called arbitration -

 I'm quite sure now that i was correct...
just to be clear,  your EDIT2 is correct.
yes this is one way i2c multi-masters can deal with the *rare* cases when they both end up in control of the bus at the same time.
with a properly operating system this will hardly ever happen.

in *normal* cases the multi-masters just monitor the SCL line to see if the bus is free.
monitoring the data on the bus is not required.


dunk.
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 28, 2009, 07:21:16 AM
Either one master starts transmitting and the others be quiet, or multiple transmitters start transmitting at the same time and they have a 'race'.

Im pretty sure i was correct :P Although my language was slightly fuzzy...

Anyway, i say we should monitor the data on the bus, i.e. always check that when you write a 1 to it, check that it is a 1. Its not a big deal in terms of program complexity and despite the face that its unlikely... its possible and easy to fix. I'd like to cross out as many chances of failure as possible.

And people always seem to get back luck when reliability matters most :P
Title: Re: Community Project - Module Housing
Post by: Weird Fishes on April 28, 2009, 08:24:56 AM
Just to be clear, we've abolished the idea of cubes, correct? I see it this way:

I want to build an autonomous robot that drives around and looks out for obstacles and tries to get to a certain GPS coordinate. Thing is: I need 142 IR sensors (exaggeration for effect), a GPS, 2 cameras, and 4 main MCU's for data crunching(again exaggeration for effect).

With this system, I could go to SoR, get the schematics and parts lists for those modules, send the schems in to a fab house and get myself 142 IR sensor boards, Gps, etc, etc. Then I can assemble all those PCB's and install the boards on my RC car chassis. Quick and painless (except for the assembling of 142 IR sensor boards ;)), plus I have code libraries.

With cubes this scenario is ridiculous. first, I'd have to buy all the cubes, which seem redundant for 99% of applications anyway, and I might as well order the boards too, since I'm getting that product anyway. Hey, my budget just quintupled!? What happened!


Cool, but impractical, and unfitting for this application. This is better served for an individual project, or a product, which is not what we're doing.

No offense to anyone, but I just feel it goes against all of our design goals.
Title: Re: Community Project - Module Housing
Post by: Asellith on April 28, 2009, 09:12:33 AM
I agree. Cubes would be cool for a single project but does not meet the goals of this project. The cubes would work better if every module was a single unit with its own set of sensors/equipment that was standardized and you developed it like a hive system and they all worked together. Now if someone wants to design a housing that could connect the individual modules together and protect them as well as be expandable like the modules then more power to them.
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 28, 2009, 09:36:28 AM
We should definitely take the idea of physical modularity aswell as electronic modularity from the cube design. So all our modules should fit on a 1inch grid, and have holes at each point in the grid to allow stacking of PCBs using standoffs. Of course 1 inch is just an arbitrary choice that can change. I think sth on the scale of a few cm is nice and we should look at making a final decision ok these standards soon.
Title: Re: Community Project - Module Housing
Post by: dellagd on April 28, 2009, 12:31:43 PM
woah woah woah
I want a yes or a no or if it is inbetween give me a reason and what it is
are we doing cubes or not!
Title: Re: Community Project - Module Housing
Post by: Weird Fishes on April 28, 2009, 12:32:43 PM
My vote is a big fat No.
Title: Re: Community Project - Module Housing
Post by: hazzer123 on April 28, 2009, 12:34:29 PM
Mine is a no too.
Title: Re: Community Project - Module Housing
Post by: dellagd on April 28, 2009, 12:37:02 PM
ok now that I think about it my vote is a no too. cubes not as flexable.
Title: Re: Community Project - Module Housing
Post by: HyperNerd on April 28, 2009, 02:18:09 PM
I agree with Asellith, cubes are a good idea, but just not for this project.
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 28, 2009, 02:19:44 PM
my vote has always been a no for this project ;D
Title: Re: Community Project - Module Housing
Post by: madchimp on April 28, 2009, 03:47:19 PM
I've been voteing no on the cube since it was first brought up.
Title: Re: Community Project - Module Housing
Post by: dellagd on April 28, 2009, 05:31:06 PM
if every one says no.. then why have we been dicusing for so long on it?
Title: Re: Community Project - Module Housing
Post by: Weird Fishes on April 28, 2009, 05:32:05 PM
I was thinking the same thing.  ???
Title: Re: Community Project - Module Housing
Post by: Ro-Bot-X on April 28, 2009, 07:32:00 PM
Here are my ideas for housing of modules for the community project:
#1 (see cube.png which is an example of a servo module) Each module is housed inside a cube with four metal plates on each side for power and the i2c bus. problems would be:
hard to keep all plates in contact
plates could be easily bridged
#2 Same as #1 but instead of plates you could use 4 bolts that would supply both a mechanical connection between the cubes and an electrical connection.
I think It would be really cool if we could build the housing for the modules in such a way so that you wouldn't need a chassis. Does any of this make sense or am I going off in the completely wrong direction? Feel free to post your ideas in this thread.   

That's why we have discussed the cubes. Because it was the first idea that came on this thread. Even though I don't think is practical for any kind of robotic project, I think the cubes are cool and allow for automatic robot reshaping or lets say some crude sort of replicators. Throw a bunch of cubes and see how they will interact with the environment, how they will connect together to create a bigger, more capable robot creature, be it biped, quadruped, wheeled or just crawling thing. It is all possible, but it involves lots of research and thought. Not so easy for any noob to use and especially not for any king of projects.

So, if we are not discussing cubes, what other ideas you guys have?

Personally, I think enclosures are not necessary for most robotic projects. Some people disconsider the robots that are a fuzz ball of wires, I somewhat agree, it is nice if you tidy up the wires a bit. Now it would be cool if the modules will be thought out to have the peripherals connected to them so that the wires go out in the same directions, left-right or forward-backward so we can tie them up to get a clean look.
Title: Re: Community Project - Module Housing
Post by: dellagd on April 28, 2009, 08:18:39 PM
thought I might  a well say this. this topic is already 4 pages. we don't want it turning into another 9 page topic.
Title: Re: Community Project - Module Housing
Post by: HyperNerd on April 29, 2009, 12:30:06 AM
I really like the look of robots that are just a stack of nicely crafted PCBs, with no housing. Here is an example:

(http://www.active-robots.com/products/robots/pob-robots/pob-hunter-500.jpg)
Title: Re: Community Project - Module Housing
Post by: SmAsH on April 29, 2009, 12:33:46 AM
ive gotta say, for some reason i just love the look of stacked pcb's, don't know why but i do! they just look awesome.