Author Topic: Community Project - Module Housing (Read 25961 times)

hazzer123 · « **Reply #30 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.

TrickyNekro · « **Reply #31 on:** April 26, 2009, 01:16:41 PM »

Mini Lipos is equal to a lot of trouble.......... no no......

HyperNerd · « **Reply #32 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.

TrickyNekro · « **Reply #33 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....

hazzer123 · « **Reply #34 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

Ro-Bot-X · « **Reply #35 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.

Razor Concepts · « **Reply #36 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.

TrickyNekro · « **Reply #37 on:** April 26, 2009, 07:51:18 PM »

Quote from: 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.

Exactly

dellagd · « **Reply #38 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

)

TrickyNekro · « **Reply #39 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

madchimp · « **Reply #40 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!

TrickyNekro · « **Reply #41 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?

SmAsH · « **Reply #42 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!

dellagd · « **Reply #43 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.

hazzer123 · « **Reply #44 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 ) 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...)

dellagd · « **Reply #45 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 I²C
thay have magnets on them to stick together and can, as long as they are connected to the I²C 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

hazzer123 · « **Reply #46 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 -

Using parts easy to obtain for anyone in the world (minimal geographic/financial problems)
Being easily built by people with only the most modest equipment (assume only soldering iron)
Very modular - maybe even as low as a making single-servo I2C controller

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!

SmAsH · « **Reply #47 on:** April 27, 2009, 06:49:34 AM »

Quote from: 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...

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

just a question, what does a servo controller do? sorry for noobish-ness, never used one $:-\$

hazzer123 · « **Reply #48 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.

SmAsH · « **Reply #49 on:** April 27, 2009, 07:12:35 AM »

ahh ok, thanks for that

and i thought it was 127 on the I2C line?

hazzer123 · « **Reply #50 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/

SmAsH · « **Reply #51 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...

TrickyNekro · « **Reply #52 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...."

hazzer123 · « **Reply #53 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!

SmAsH · « **Reply #54 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".

HyperNerd · « **Reply #55 on:** April 27, 2009, 10:16:55 AM »

Did anyone take a look at my previous post?

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

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 I²C, 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 I²C 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 I²C.

hazzer123 · « **Reply #56 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

Single analogue sensor module
Single servo controller module
Scanning sensor module (Servo + Sharp IR/another sensor)
Alphanumeric LCD module
Graphic LCD module
7 seg LED module

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.

TrickyNekro · « **Reply #57 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...

hazzer123 · « **Reply #58 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

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.

TrickyNekro · « **Reply #59 on:** April 27, 2009, 12:13:58 PM »

Yes... I know that about the modules........ whatever... I2C if that is.....

News:

Author Topic: Community Project - Module Housing (Read 25961 times)