SoR Project: standardization for robots

[Admin]

To get the ball rolling, this thread will be used to discuss coming up with and implenting standards for robots that we make.

For those who do not understand the advantage of standards, let me explain with an example. Everyone knows USB connectors right? Well what if every company that make computer parts had their own connector, can you imagine the annoyance it would be to have 5 different connectors for 5 different parts? With a standard, everyone agrees to use USB and everyone is happier.

Well we should do the same for robots - we all agree on dimensions, voltages, screw sizes, connectors, methods of communication, etc. That way when we open source our robot, its really easy to adapt someone elses robot part to our own robots.

Now I'll leave the floor open before I say any more . . . What would you see as very useful to be standardized? Should we have multiple classes of standardized robots (big robots vs small robots, etc)?

[hazzer123]

I don't know if you have had time to read through the Community project thread yet, but these things are currently being standardised for that.

We have currently agreed on dimensions, voltages, connectors and methods of communication. So the community project might be just what you are looking for.

I really recommend you have a read through the thread. Another experienced opinion will help the project greatly 

[Admin]

Actually, I made this post based on the community project.
(yeap, I finally replied to that loooooong thread)

And . . . I forgot to post what Dunk has already written up:
http://docs.google.com/View?docid=ddp2r5j8_24hhf75vck

(oops!)

[Admin]

Ok I just read through all of Dunks standards . . .

For physical size, what if we did multiples of .5" (12.7mm) instead of 1.5" (38.1mm)? The larger size is a bit constraining I think . . . And this is per dimension (X, Y, and Z), not squared area . . . Like I can see some projects being in a rectangular shape . . . or a box shape . . .

PCBs should have a 3.5mm (1/8 inch) hole in each corner allowing for M3 (4Gauge) screws. (exact position TBA.)

1/8", I agree. This also allows for 4-40 screws too, which is much much easier to buy in the US than a metric screw. 1/8", 4-40 holes is already my personal standard for all of my robots.


For battery plugs, I suggest a 3 pin connector - ground, Vcc, NC. This is how RC is already done, and nothing bad happens if the connector is accidently put in reverse.

UART header pins should also bring power in a 5 pin header like this: Vcc, GND, SCL, SDA, (NC).

I think you mean Vcc, GND, Tx, Rx, NC?


And one more standard:
All connector pins must have labels next to the pins - no one should be forced to refer to a schematic just to find the darn ground pin or Tx pin . . .

[ed1380]

YOU CAN DO A RECTANGULAR BOARD IF YOU DO 38X76

WE ALREADY TALKED ABOUT IT

SRY ABOUT CAPS. NEED IT FOR PS

O YEAH AND MY SIG HAS THE GOOGLE DOCS

[Admin]

Ideas keep popping into my head . . . sorry for posting too much . . .

We would need to encourage use of these standards . . . once we have a good draft of it, I'll contact companies and let them know this is what we support and encourage them to try to follow as many of our standards as they can. Also to get their thoughts . . .

[Trumpkin]

You can never post too much . yeah I think that's a good idea.

[dunk]

hey Admin,
welcome to the party!

I think you mean Vcc, GND, Tx, Rx, NC?

nope. we definitely mean Vcc, GND, SCL, SDA, (NC).
the plan is for a modular approach all communicating on an i2c bus.
communication specs here: http://docs.google.com/Doc?docid=ddp2r5j8_21dgt72qgz&hl=en

For physical size, what if we did multiples of .5" (12.7mm) instead of 1.5" (38.1mm)? The larger size is a bit constraining I think . . . And this is per dimension (X, Y, and Z), not squared area . . . Like I can see some projects being in a rectangular shape . . . or a box shape . . .

yea. this is a tough one. 38mm was chosen as it matches 1.5" closely. nobody outside the US uses inches but a considerable number of people on the forum are from the US...
the importance of having a set size comes into play when people want to stack modules. the bus connectors need to be in the same position.
i'm not saying 38mm is the right decision, just that we need *a* decision.
.5" in my opinion is too small to form the sort of mounting grid we were talking about though....


dunk.

[Admin]

I think you mean Vcc, GND, Tx, Rx, NC?

nope. we definitely mean Vcc, GND, SCL, SDA, (NC).

I meant the Tx and Rx for the UART, and SCL and SDA for I2C. Or am I confused?

yea. this is a tough one. 38mm was chosen as it matches 1.5" closely. nobody outside the US uses inches but a considerable number of people on the forum are from the US...
the importance of having a set size comes into play when people want to stack modules. the bus connectors need to be in the same position.
i'm not saying 38mm is the right decision, just that we need *a* decision.
.5" in my opinion is too small to form the sort of mounting grid we were talking about though....

oooooohhhh ok I understand now.

1.5" multiples for stackable boards, sounds fine for me. I was thinking of devices and sensors that were definitely smaller than 1.5", but I guess they do not need to be stacked . . .

So this measurement is for hole locations and not board dimensions, correct?

Hmmmm the Axon has hole dimenions of 2.342 x 2.342, not even close . . . kinda too late for me now . . . my goal was to make the board as small as possible . . . I guess I can write up a tutorial on how to make adaptors for it to fit a 3" x 3" setup.

[izaktj]

I think we should used the metric system, not the British imperial royal system. 

[paulstreats]

Thinking about the i2c standards, have you thought of any way to set addresses on the fly? instead of each module needing a preprogrammed address.

Maybe the bus master can regularly scan for a device at address 0000, if a device responds the master can then allocate it with a new address meaning that the bus can be dynamic. There are several problems in this system that will become obvious at an initial power up but this can be worked out quite easily. There will be less problems with a dynamic system than with a preconfigured system. Also when a device comes on line, maybe it can transmit its name and purpose and standard commands to the master or upon request so if your master module is connected through uart to a pc, you can extract modular information, commands and help data through hyperterminal of everything on the bus.
Also one step closer to modular scripting

[dunk]

I meant the Tx and Rx for the UART, and SCL and SDA for I2C. Or am I confused?

o, hang on, you do mean for the UART there.
yup. that was a typo in the doc.
fixed now.

So this measurement is for hole locations and not board dimensions, correct?

both really. the idea being so different boards can fit into standard robot bodies.
if someone was to design a robot chassis they would put a grid of mounting holes at the correct spacing to fit the 38x38mm boards.
these would then also fit any multiples of that size. the bus connectors would still line up, etc.
did you see the proposed module templates on the original thread?
http://www.societyofrobots.com/robotforum/index.php?topic=2765.msg21178#msg21178

Thinking about the i2c standards, have you thought of any way to set addresses on the fly? instead of each module needing a preprogrammed address.

Maybe the bus master can regularly scan for a device at address 0000, if a device responds the master can then allocate it with a new address meaning that the bus can be dynamic.

interesting idea.
can you suggest a way to differentiate between i2c devices when you do a broadcast to 000?
they could all pick a random address and then compare for duplicates...
to be honest i think dynamic allocation of addresses would make the i2c section of the microcontroller code *far* more complicated for relatively little gain. i don't think it is much work to give unique static IDs to each module.

maybe it would be worth making the i2c address manually changeable over the i2c bus though.
this way if someone ever produces these modules commercially it would be possible to supply them all with the same i2c address and then plug them into the bus one at a time to change them when you first take ownership of the module.

I think we should used the metric system, not the British imperial royal system.  Tongue

so here's a question that went unanswered the last time we were discussing sizes:
does anyone care about making these boards fit a nice round number of inches?
for example if we were to make the standard unit 30mm it would be 1.181inches. would anyone argue this would be a Bad Thing(tm)?


dunk.

[Ro-Bot-X]

About the hole center positions. Can we make it 5x5 grid units instead of 7x7 units? The units are set for 0.025in.
Also the horizontal connectors on ONE side have to closer to the middle, so the tip of the pins would touch the edge of the board. These connectors are optional, but the vertical connectors would need to be placed EXACTLY in the same place on all boards for stacking.
On the 76x76 boards, we also need connectors on the upper half?

I propose that the vertical connectors be mounted exactly at 9 units from the closest edge.

[paulstreats]

can you suggest a way to differentiate between i2c devices when you do a broadcast to 000?

You spotted the initial power up problem.

My thoughts would be that all modules would have to have at least a limited master function to allow them to scan the 000 address, if the address is free then register itself there, if not then wait 50ms or so and try again.

There are also other benefits to this like your robot could interconnect with other robots easier, or a dynamic connection to a docking station could be made or to a data update system.

The only reason why usb has taken over the connectivity world is because of its dynamic addressing, it would be a shame not to learn from the example and go back to the old days of having to have everything pre defined.

Once the initial code is made, it is copyable and pasteable with probably no changes needed at all giving everybody their communications interfaces.

I could work towards such a system and check its feasability if you like

Also, have you managed to implement a code interrupt on i2c receive?

[Admin]

does anyone care about making these boards fit a nice round number of inches?

Doesn't bother me any. As long as the specifications already convert the units its fine.


A suggestion on holes . . . what if the holes were really really close to the corners, so that the holes were open? Almost like a C shape instead of an O shape? It would be just as functional, and allow for more real estate room on the board.

[ed1380]

i think the idea about dynamic addressing is great, but sadly i wont be able to help y'all with it 

[dunk]

My thoughts would be that all modules would have to have at least a limited master function to allow them to scan the 000 address, if the address is free then register itself there, if not then wait 50ms or so and try again.

the address 000 is reserved as a broadcast address (anything sent to 000 is received by all nodes) but i get your theory.
as all the nodes will be powering on at the same time we would need to have each module delay a random amount of time before attempting autoconfiguration in the hope that it didn't choose exactly the same time slot as another module.
the module going through autoconfiguration could then hold the i2c bus until it was done, then release the bus so the next module could go.
it is possible but i think it would be too expensive in resources for more lightweight microcontrollers.
the i2c slave code i wrote for my motor controllers allready fills all the available flash on an ATtiny45.

we also need modules to be reliably addressable. for example if i have 4 motor controllers on my bot, one for each wheel, i need to know which one is which. no point having a random address on a motor controller if i don't know which wheel it is controlling.

we could give each module a unique ID the same way USB and ethernet interfaces do it but if we are going to do that, why not just give it a unique i2c address....?

so, while it would be a very interesting project, i'm not convinced the benefits outweigh the overhead for this project.

About the hole center positions. Can we make it 5x5 grid units instead of 7x7 units? The units are set for 0.025in.
Also the horizontal connectors on ONE side have to closer to the middle, so the tip of the pins would touch the edge of the board. These connectors are optional, but the vertical connectors would need to be placed EXACTLY in the same place on all boards for stacking.
On the 76x76 boards, we also need connectors on the upper half?

i'm afraid that's a bit tough to follow Ro-Bot-X.
i agree all the bus connectors need to be in *exactly* the same position on each board.
i'm fine with 5x5 grid units.
for your other points, why not make up some Eagle templates? or CAD? maybe a picture will explain it better...

A suggestion on holes . . . what if the holes were really really close to the corners, so that the holes were open? Almost like a C shape instead of an O shape? It would be just as functional, and allow for more real estate room on the board.

the problem with that is if someone wants to bolt 2 modules next to each other. while the bolts will go through there will be no space for the nuts or screw heads.


dunk.

[JonHylands]

I'm going to weigh in here, and perhaps not be popular, but such is life...

I think stackable boards is the wrong way to go about building modular robot parts. The beauty of USB is that the connector is standard, and the protocol is standard, but the shape/size of the actual device is irrelevant. Stackable boards is so 80's...

I've been using the Bioloid system for a while now, and building new devices for its serial bus. The concept is your central "brain" computer doesn't interface with any hardware itself - it just talks to the bus. Each sensor and each actuator is a device on the bus, with its own micro-controller. They all understand the same protocol, each has its own ID (which is just a number stored in EEPROM), and since it is a master/slave bus, there is never any bus contention. Devices are daisy-chained, and the actual physical bus is 3 wires - power, ground, and data.

This way, you can use pretty much anything as your central computer, as long as it can interface to the bus. The bus runs at 1.0 Mbps, so there's lots of capacity. For plugging in larger "brains", I have a USB board that plugs into a USB port of your PC/gumstix/hammer, and provides direct access to the bus as if it was a serial device. AVR ATmega series micro-controllers can interface directly to the bus, with no extra hardware required.

I'm not saying you should use the Bioloid bus - what I'm saying is think more modular. If you want to add new capabilities, don't stack another board - plug in another device.

- Jon

[Admin]

In support of Jon, I think USB is a good way to go - mainly as it allows an easy connection to a PC.

Its only like $4 in components to add USB to any module.

Stackable boards is so 80's...

Although I like the idea of stackable . . . I've never actually had a reason to do this . . . ever . . . I'm divided now . . .

[dunk]

I think stackable boards is the wrong way to go about building modular robot parts. The beauty of USB is that the connector is standard, and the protocol is standard, but the shape/size of the actual device is irrelevant. Stackable boards is so 80's...

ooo. i remember the 80s...
to be honest i don't really care whether the boards stack or not. what i am interested in is a common communication system between modules.
however, i don't see any harm in the boards stacking or plugging together on the same plane as it adds a lot of flexibility in the way they are used. it will still be an option to connect them with a standard cable.

I've been using the Bioloid system for a while now, and building new devices for its serial bus. The concept is your central "brain" computer doesn't interface with any hardware itself - it just talks to the bus. Each sensor and each actuator is a device on the bus, with its own micro-controller. They all understand the same protocol, each has its own ID (which is just a number stored in EEPROM), and since it is a master/slave bus, there is never any bus contention. Devices are daisy-chained, and the actual physical bus is 3 wires - power, ground, and data.

sounds very similar to what is being proposed here, although with a few subtle differences...
who owns the communication method Bioloid is using? i'm presuming it must be bit-banged in software on all microcontrollers?
i'm in favour of i2c as a communication method over a proprietary one wire system.
i'd also see being tied to a single master on the bus as a drawback rather than a benefit. i2c can operate as single or multi master. people would be free to operate with one master if bus contention is a concern or configure for multi-master operation for applications where timing is less of an issue and they have need of it.

In support of Jon, I think USB is a good way to go - mainly as it allows an easy connection to a PC.

i'd agree that it's good to be able to connect the bus to a USB port but i would not like it to be a requirement.
a lot of my projects don't get connected to a PC.
i don't think Jon was suggesting we put a USB port on every module, just using it to illustrate a point.


dunk.

[Admin]

i'd agree that it's good to be able to connect the bus to a USB port but i would not like it to be a requirement.
a lot of my projects don't get connected to a PC.
i don't think Jon was suggesting we put a USB port on every module, just using it to illustrate a point.

Thinking about it a bit . . . I guess multiple UARTs aren't very common yet, making this very constraining . . . would be nice if Atmel would put a USB output on their mega chips . . . and USB is kinda useless for those who want bluetooth . . .

That being said, I still think its important that the 'brain' hardware is designed for an easy interface to a PC.

[JonHylands]

The comm on the devices (which typically have an ATmega uC onboard) is all done through the hardware UART.

If you need another UART for the sensor/actuator, you can use something like an ATmega162, which has two hardware UARTs.

The bus master owns the bus, and it is the "brain" device - typically a PC/gumstix/hammer/whatever. Or it could be another micro-controller.

I don't mind I2C, except that its too slow to run 25-device humanoid robots, when you want to update and read from each device 30 times a second...

- Jon

[paulstreats]

is the speed constraint to do with the pull resistors on the bus?

[Ro-Bot-X]

That being said, I still think its important that the 'brain' hardware is designed for an easy interface to a PC.

Perfectly right. Axon allready has all connection types: USB, USART (->Bluetooth), I2C. This would be a perfect Main MCU.

I am writing this post while I have on the right an add from Phenostream. I look at their OpenStepper made after the OpenServo project. Do we want to build an OpenDCMotor? What is the best approach: a dual DC motor controller or single DC motor controller? Or both? Same goes for sensors... Each sensor a device on the bus or a sensor controller on the bus?

[paulstreats]

Each sensor a device on the bus or a sensor controller on the bus?

I would lean towards having a sensor controller on the main bus, and then another seperate bus with the sensors on

[dunk]

The comm on the devices (which typically have an ATmega uC onboard) is all done through the hardware UART.

interesting.
do you have more info?
i'm presuming half duplex UART with both TX and RX connected to the same line?
is there open source Bioloid firmware or communications standard or did you have to reverse engineer it?

I don't mind I2C, except that its too slow to run 25-device humanoid robots, when you want to update and read from each device 30 times a second...

yes. the maths are not quite that simple if you connect more than one servo to each device but that would be very close to the maximum throughput of the i2c bus.
and in the real world "very close" means "no workey".

to be honest the communication method we have been discussing is optimised for ease of use and flexibility rather than high speed.
maybe people will decide a higher speed bus is preferable....

dunk.

[Ro-Bot-X]

I don't mind I2C, except that its too slow to run 25-device humanoid robots, when you want to update and read from each device 30 times a second...

Well, you don't have to. You can use ready-made Dynamixel servos for that. And humanoids are not so big yet to be difficult to install servos to a single controller. Most important is to have a fast and stable servo controller that a Main MCU can command through the I2C bus.

[JonHylands]

interesting.
do you have more info?
i'm presuming half duplex UART with both TX and RX connected to the same line?
is there open source Bioloid firmware or communications standard or did you have to reverse engineer it?

The protocol is well documented, so it was relatively easy to write our own. The only real trick was hooking the Tx and Rx pin to the same wire. Fortunately, the ATmega series can independently enable and disable the Tx and Rx sides of the UART, so it was doable without any extra glue hardware.

to be honest the communication method we have been discussing is optimised for ease of use and flexibility rather than high speed.
maybe people will decide a higher speed bus is preferable....

That's fine - I'm not pushing the Bioloid bus here, I'm just presenting it as a different way of organizing a robot's electronics. The main controller does nothing (hardware-interfacing-wise) other than talk to the bus over a single interface.

- Jon

[JesseWelling]

CAN works pretty well for tractors but it's not cost effective in this realm.

Jon I haven't double checked your math but I assume you are using 400mhz i2c? Most AVR's can do that...
If going with the I2C idea, you guys should go with a scheme like Devantech sensors. Their i2c address can be changed by writing to special 'registers' (actually just special write sequences, but I digress...).

But really I prefer J1939 on a 1Mbit CAN Bus

[JonHylands]

The Bioloid devices have a really nice feature, that I thought was kind of strange at first, but is definitely a huge advantage.

All of the information about the device, including the ID, and the sensed values, are stored in a "control table".

Here's an example of the control table for the 6-axis IMU I designed:

http://www.bioloid.info/tiki/tiki-index.php?page=6-Axis+Bus+IMU+Documentation

Even the onboard LED is just an entry in the table, which you can set to 0 or 1 to turn on or off the LED. The point here is that there are no specialized commands for a given device. You can read entries from a device, and you can write entries to a device. The command set stays small and very simple, which means building new devices is much easier - all the command parsing and control table code is identical. I've designed and built 3 different bioloid devices, and they share 90% of their code.

I'm not using I2C at all - as I said before 400 KHz is too slow for what I'm doing, and the bioloid bus runs at 1.0 Mbps. And all bioloid devices store their ID in the control table, so it can be read and written to...

- Jon


- Jon