A community project for the summer perhaps?

[Fredrik Andersson]

I can't really agree with that. The communication connections between the modules should be in the shape of wires. We should go for simplicity yet flexibility. The stacking model could still be achieved with wires, so wires only is my opinion. If we want to stack then, the connection pins should go out horizontal from the pcb or else have the pcb's stacked with more space between so that a wire can be connected to an upward pin and then be bent out.

[dunk]

I think we should come up with a standard dimension for the boards, so that brackets with the same dimensions could be designed. Preferably square formed, right? That means you can put the boards in four different directions to get wires and such in the preferred direction.

i think this standard should only be applied to the PCB versions of the boards. people making their versions on strip board can make them whatever shape they like.
when writing up documentation we should include Eagle PCB layouts. standard size. standard mounting hole position.
i think putting the power connector and i2c bus connector in a uniform place be a good idea too.
i hadn't considered the advantages of making them square but now you bring it up i agree.

we also want a standard connector type.
i would recommend something that fits on standard header pins. this way we can just use header pins on the boards and make up cables to go between them.
standard header pins also fit the standard hole spacing of solderless plug blocks and strip board.
to connect to the header pins i recommend http://www.molex.com wire-to-board crimp connectors but these require a (fairly cheep) crimper so maybe someone else has a better idea?

we also need a power standard.
i think any board without it's own regulator should receive 5v.
does anyone think we need a 3.3v supply? personally i think 5v is a better choice and people can regulate down to 3.3v if they need on a particular board.
most projects will need at least one board with access to a higher voltage. this will be needed for power regulator boards as well as any board driving higher voltage components (DC motors for example).
it should be encouraged to allow for a large range of input voltages here (5.5v to 14v ??) but i think we should leave the exact operating voltages up to the board designer to allow for different modules servicing a wide range of applications.
i would recommend we use a different connector type for higher voltage connections to allow for higher power draw as well as preventing accidental mis-wiring of high voltages to delicate components.

as for the communication standard between boards, i'm working on a prototype implementing the ideas i put up in the doc here:
http://docs.google.com/View?docid=ddp2r5j8_21dgt72qgz
i have most of the code written and i'll be able to test it on boards i already have.
hopefully i'll be able to get it compiled and tested later this week.
i'm not a great programmer so if someone else out there is welcome to completely rewrite it but i feel we need a working prototype that people can modify to suit their application.
my code runs on the AVR atmega8 platform but should be easy to port to other AVR platforms (including Admin's Axon).

i've only been talking about the electronics side of this project. obviously there are still a lot of decisions to be made about the mechanical components.

so, things that i'm presuming are decided: (please comment if anyone disagrees!!)
 - it should be possible to build boards on stripboard etc but PCB versions are encouraged.
 - PCB versions of boards should be square and of one of several set sizes.
 - inter module communication should be by either UART or i2c and should not conflict with packets of the format described here: http://docs.google.com/View?docid=ddp2r5j8_21dgt72qgz even if they don't require that format to operate correctly.
 - any microcontroller (or microprocessor) type is acceptable as long as it can be made to operate within out list of standards.
 - logic components will be 5v tolerant or have buffering within the module to accept 5v I/O.
 - modules not accepting 5v input but taking a higher voltage will have a voltage regulator capable of acting as a power bus to other modules.
 - connectors between modules should fit onto standard header pins.
 - standards should only be applied to modules where necessary for them to inter operate with other modules. if a module does deviate from our standards though it should be made clear in the documentation for that module.

things we still have to decide: (please add to this list!!)
 - standard board sizes (for PCB versions only). i think we need more than one. and something that converts between inches and mm easily... multiples of 1.5inches ~ 40mm...
 - connector type suggestions.
 - minimum acceptable documentation. i think we need parts list (with links to suppliers where applicable), estimated cost, links to any required software, detailed step by step instructions (with pictures if applicable), any code should be well commented, any more???
 - licencing. who owns this? how do we stop someone else from patenting out work? i think we need a template Open Source type licence  that anyone can copy into their project.
 -

any one disagree with anything in the summary?
anything to add?


dunk.

[cooldog]

I am sorry, but I am not very clear in how much this stuff costs. Approximately how much will it cost depending on:

1) Some people are willing to donate some parts that they have. (minimum)

2) Nobody donates anything and every part must be bought. (maximum)

This is like the only website specializing on ROBOTICS, not just instructables with like 5 tutorials. This is like a whole database with tons of information, so with a good letter, we might be able to convince some company to sponsor this project.

I'm just trying to think about the groups:

1. Engineering (mechanics)
2. Programming
3. Circuit designing
4. Fundraising

Anything else?

NASA

[dunk]

a few comments came in there while i was writing...
stackable or not...
so i'd like the power and i2c connectors to be in the same position on all boards as it makes sense to give people the option of stacking those.
for general purpose I/O though i don't think it applies. why would you want to connect them between boards?
it would be good to put general purpose I/O at the edge of boards so people can use right angled header pins for those if they want another board on top.


dunk.

[Ro-Bot-X]

Dunk, I read the communication protocol proposal and I have to say it is beautifull. We should go for it.
You say you can have sample communication programs for each node? That would be nice to test out.

[garriwilson]

NASA

anything is possible when you put your mind to it 

How are you guys trying to get together and work on this? By location? Or you want to use a program to talk like AIM. Skype is a really good program, it has chat, webcam, and you can do conferences with as many people as you want to talk to.

[cooldog]

skype is so cool i just got it. i use it as a securrity system for my room

http://www.instructables.com/id/Remote-Security-w%2f-Skype/

[Asellith]

If we do this right we could get the first initial prototype stuff for free. Maybe not the pcb boards but most of the components and sensors could get sampled out to us. If a company is asked to supply several parts for a robot design that will become a standard for a 1400 member group they might be willing to give free samples. Also if the project is done correctly as someone mentioned earlier we could have Sparkfun and others sell and make the modules for us and I assume everyone will agree that most of the profits can go to more R&D as well as to admin to cover the costs of the site. With Admin's new board coming out we could make some serious improvements to the hobby robotics community.

As far as a standardized controller we could make 2 designs one for avr and one for pic the circuits themselves and even the code wouldn't be that different. The pinouts might change a bit but as long as they output the proper communication protocols then you could have several different sets.

[Fredrik Andersson]

Guys, please, please, keep this thread as on-topic as possible. Given that we only have this thread to discuss the project so far we have to keep it clean and focused.

Also, please read the whole thread. I noticed in several posts it seems like some still think it's about building one single robot, and thats definitely not the case.

Let's get on topic. Dunk, your prototype design seems really accurate. That's precisely what it should be like. I have yet to read up about the I²C so I can't really say anything more. What about the slave devices? What for? I'm sure I'll understand when I've read up about it though.

How many pins will be needed for an I²C connection? About the crimp connectors, is something in the line of this what you meant (couldn't see it at Molex because the search server was down or something like that): http://www.asianproducts.com/showproducts.php?item_id=P11143553282150939&pic=big
No, wait, this is exactly what you meant, right? http://www.societyofrobots.com/electronics_wire_connector.shtml and yeah, a crimper tool is needed then...

I agree on all the power standards you came up with. Those are values used often in robotics so that should work well when interfacing sensors, microcontrollers and so on.

"PCB versions of boards should be square and of one of several set sizes." I disagree here. At least the mounting holes should be of standard size. I am very much into setting standards for brackets and such, so that the distances between joints and such is know and we can thereby add some advanced movement features.

[dunk]

Let's get on topic. Dunk, your prototype design seems really accurate. That's precisely what it should be like. I have yet to read up about the I2C so I can't really say anything more. What about the slave devices? What for? I'm sure I'll understand when I've read up about it though.

an i2c master can send data to and request data from an i2c slave.
i2c slave devices can only reply to an i2c master, not initiate communication.
as i'm proposing an i2c multi-master system the masters would be able to act as a master or as a slave.
"so why bother with slaves?" an i2c slave takes less microcontroller programming and therefore can use cheaper microcontrollers.

How many pins will be needed for an I2C connection?

2 signal wires for i2c. i tend to run a ground wire with them as well.

About the crimp connectors, is something in the line of this what you meant

yup. any of those will fit standard header pins. i use the Molex ones but it's not critical which model.

"PCB versions of boards should be square and of one of several set sizes." I disagree here. At least the mounting holes should be of standard size. I am very much into setting standards for brackets and such, so that the distances between joints and such is know and we can thereby add some advanced movement features.

hmm. so while i agree in theory, some modules will just take up less space than others.
on my current bot i have i2c motor controllers with an attiny45, an h-bridge chip, a power connector and a few header pins. they are about 40mm square.
it doesn't seem to make sense to use a full size board for something like this.
maybe if a standard board was 80mm square we could also have a 80x40mm so 2 could occupy the space of a standard board, still using the same mounting holes....

on the other hand, had i decided on a set of standards when i designed them i might have put all 4 motor drivers on one board....
i think this sort of issue would be taken care of by my suggested opt-out clause. to quote my self:

- standards should only be applied to modules where necessary for them to inter operate with other modules. if a module does deviate from our standards though it should be made clear in the documentation for that module.

so with my motor controllers, it clearly does not make sense to use a full board so i'd just document the fact clearly and make an effort to make them compatible with the mounting design of the standard modules....

anyway,
in other news,
my rewrite of my "i2c to UART" board firmware appears to work as expected so i'll make and test a demo board and document some instructions on how to build, compile and program.
don't know how busy this week will get at work but should have it done by the end of the week...
everyone alright with Eagle for board schematics?

dunk.

[SmAsH]

hmm...yes you guys and girls do have a good point but if only we could grow a few money trees eh? i think you should find a group of like 3-8 people in one state and then they can get together...get my point....
i think you should make a poll will all the states and see how many people are in each state then well get them to talk... anyway do what the community decides. i really hope this project takes off..
good luck

~smash

[airman00]

its not only states , there are plenty of people around the world

[cooldog]

like me (canada)

[ed1380]

I agree that mounting holes should be made in multiples of 40mm.

everything else is over my head

I've scavanged a fair amount of stuff. mainly wires and connectors. and some switches, so i might be able to help out that way

[Ro-Bot-X]

Having the holes spaced 40mm apart will do. If someone needs a bigger board 2.5"x2.5" for example, just use the same PCB layout but extend the border of the board to that dimensions. The only problem would be if someone wants to make a smaller board. So the minimum space necessary should be designed.

on my current bot i have i2c motor controllers with an attiny45, an h-bridge chip, a power connector and a few header pins. they are about 40mm square.

Dunk, is that a single motor driver? does it have encoders? can we make also a dual motor dirver (if it's a single motor driver)?

What should be the commands for a motor driver? (regardless if it uses servos, dc motors or steppers)
I thought about this and maybe it is easier to give the distance it needs to travel in cm or inches and the heading angle from curent position. Should it return anything, like current heading angle, distance travelled...? What about speed settings?

[Fredrik Andersson]

Those features would be neat for a motor driver. We should of course implement them. However, that makes the motor driver pretty advanced, so we should make different versions of motor drivers for those who only needs the most basic functions like just driving the motors, forward and backward.

[Ro-Bot-X]

Those features would be neat for a motor driver. We should of course implement them. However, that makes the motor driver pretty advanced, so we should make different versions of motor drivers for those who only needs the most basic functions like just driving the motors, forward and backward.

I don't see any reason to have both features on the same controller. Simple "Left-Forward" "Right-Forward" commands and complex "Forward 52 units" can coexist. We can make a lookup table for commands starting from simple to complex and execute them as needed. The firmware can also check the existance of encoders and use them for complex calculations.

The reason for a motor controller is to do complex stuff that will free up the Main MCU. It needs to be able to send PWM signal to the motors and count the encoder pulses. It may also need to use PID to make the robot go straight. Of course, the PWM signal will be different for the 3 types of motors, but the rest should be the same.

I'll start a list of commands, please add to it if I miss something:

LeftForward
RightForward
LeftBackward
RightBackward
Stop (Brake)
SetSpeed % (0-100)
SetLeftSpeed %
SetRightSpeed %
Set TurnSpeed %
SetAcceleration (1,2,3...) //this sets how fast the robot will get to the setted speed
SetLeftAccel %
SetRightAccel %
SetUnits (cm or inch)
Forward units #
Backward units #
Turn # (degrees) //pozitive numbers turn clockwise, negative numbers turn couterclockwise

[Ro-Bot-X]

The firmware will need to be pre-set for a standard phisical robot setup. Each user will change the parameters as needed for it's own particular design. For example:

Wheel diameter
Distance between wheels
Encoder clicks per wheel rotation
Max motor speed RPS

[paulstreats]

Why not have it set up so the master controller can be programmed with that info and then relay it on start up to the devices for them to calculate

[Rebelgium]

Just to get back on the question for a seperate forum for this project:
I don't agree. The point of the SoR forum is to have a database of info, so if one searches for something in the electronics forum , the answer might be in the project forum, and he doesn't find an answer...

I suggest to title every thread for this project like this:
"SoR PROJECT: blablablabla"

[Fredrik Andersson]

Just to get back on the question for a seperate forum for this project:
I don't agree. The point of the SoR forum is to have a database of info, so if one searches for something in the electronics forum , the answer might be in the project forum, and he doesn't find an answer...

I suggest to title every thread for this project like this:
"SoR PROJECT: blablablabla"

Forum can both mean the forum page as a whole or a category for threads. I'm sorry for the misunderstandings.

[dunk]

ok,
i've been putting some thought into PCB sizes.

of the guys based in the US, how much of a pain is it for you to work in millimeters?
i know it would be unpractical to use inches in most of the rest of the world...

here's what i propose:
we should pick a standard unit of 38mm which is approximately 1.5inches (1.496inches).
this is intended as a compromise between metric and imperial sizes.
38mm is an odd number and 1.5inches is not the exact size.
i believe both are perfectly workable numbers though. the amount of error in inches is tiny.

robot bases should be laid out to accept boards of 38mm with mounting holes in each corner. (exact distance from each corner to be decided.....)

i accept 38mm square is too small to do much with. it's only meant as a standard unit.
most practical boards would be 2 of these units square. 76 x 76mm (3x3 inches).
this size would be large enough for an atmega16 and lots of I/O pins...
one of these larger boards would still fit onto the same robot base as the mounting holes would line up with the smaller boards.

this way boards could be made up in a lot of configurations but still fit the mounting holes on a "standard" robot chassis.
38x76mm, 76x76mm & 114x76mm would all be acceptable configurations although the standard 76 x 76mm would be the target size.

how does this sound?


dunk.
(waiting the test PCB for the i2c program to etch....)

[Asellith]

PCB design:

Each module will be constructed on the same pcb but with a good board design and the same MCU it might be possible because the I2C pins will be in the same place and the power. The extra work on PCB design would pay off in production run costs by making more boards. If we do a duel AVR/Pic design we could have a pic based board and an AVR based board. just some ideas.


Obviously those who don't want to purchase boards can free form the design without any problem as well. I just think a production run every several months by the board controlled by Admin or another representative could make PCBs available to everyone for cheap. If we order like 100 boards of this size we might be able to get them cheap. I did a quick calc with express PCB software and it looks like we can get a 2 layer board top and bottom with solder mask and silk screen for $465 in a quantity of 100. Thats under $5 per board plus shipping to each individual person. Thats cheap and it only goes down for more orders. If we get a uniform PCB design going then we should be able to make that an option for everyone. I am almost sure they drill the holes in the boards as well. I need to check that and will look into it later today after work.

Jonathan Bowen

[Rebelgium]

Just to get back on the question for a seperate forum for this project:
I don't agree. The point of the SoR forum is to have a database of info, so if one searches for something in the electronics forum , the answer might be in the project forum, and he doesn't find an answer...

I suggest to title every thread for this project like this:
"SoR PROJECT: blablablabla"

Forum can both mean the forum page as a whole or a category for threads. I'm sorry for the misunderstandings.

I know, I'm saying that there should not be a separate sub-forum.
I'm saying that if there needs to be a thread about the motor drivers for example, place it in the electronics sub-forum and call the thread "SoR PROJECT: motor drivers".

This way people searching in a sub-forum will still find the results.

[maverick monk]

this is confusing and WAY over my head, Ill see If I can do somthing arm-wize since that would be fairly simple.
btw, what are we using as our mechanical standerd, does a 3inch on each side cube sound good? 80mm x 80mm x 80mm?

also power, how are we doing power? a central cube for power and regulation? I can do that easily.

[ed1380]

umm. mav. we aint making a robot. we making module that can be connected to make a robot.

i personally am with the idea of a subforum for the SOR project. it'll be alot easier to find threads about it, than having to look in every section for the SOR PROJECT heading.

and people who use the search function (like they should) will still find those threadds

[Fredrik Andersson]

umm. mav. we aint making a robot. we making module that can be connected to make a robot.

i personally am with the idea of a subforum for the SOR project. it'll be alot easier to find threads about it, than having to look in every section for the SOR PROJECT heading.

and people who use the search function (like they should) will still find those threadds

Yeah, those are the arguments i was thinking about as well. The forums are very active as it is now, and if we put all the threads about the SOR project it will be pretty stashed.

[maverick monk]

edited it, i jumped the gun on posting after reading 1.5 pages  

[hazzer123]

I vote for a sub-forum also. I haven't ever used advanced search to specify which category, and have still found the answer to my problem no problem.

[dunk]

Each module will be constructed on the same pcb but with a good board design and the same MCU it might be possible because the I2C pins will be in the same place and the power. The extra work on PCB design would pay off in production run costs by making more boards. If we do a duel AVR/Pic design we could have a pic based board and an AVR based board. just some ideas.

i'd certainly like to see a generic base module that was flexible enough for people to use in a variety of ways.
maybe an atmega16 or similar with all useful I/O pins terminating in stackable connectors that allowed a piece of regular strip board to be stacked above it and whatever components the user wanted could be soldered in place on the strip board.
this way someone could have a bunch of these versatile module PCBs made and distribute.

i'd see this as another kind of module though. no need to make all possible modules use a board like that.
i suspect if it was designed correctly this would be one of the more popular modules though...

I vote for a sub-forum also.

i think this is Admin's choice.
one of the things i like about this forum is it's simplicity and the fact you don't have to dig through loads of empty sections to find the one you want.
while i do think this project has the potential to require it's own section i don't think we are there yet.


dunk.