Get the SoR Robotics Android App on Android Market for FREE. See this forum post for details.
0 Members and 1 Guest are viewing this topic.
PCBs should have a 3.5mm (1/8 inch) hole in each corner allowing for M3 (4Gauge) screws. (exact position TBA.)
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?
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 . . .
QuoteI think you mean Vcc, GND, Tx, Rx, NC?nope. we definitely mean Vcc, GND, SCL, SDA, (NC).
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....
I meant the Tx and Rx for the UART, and SCL and SDA for I2C. Or am I confused?
So this measurement is for hole locations and not board dimensions, correct?
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.
I think we should used the metric system, not the British imperial royal system. Tongue
can you suggest a way to differentiate between i2c devices when you do a broadcast to 000?
does anyone care about making these boards fit a nice round number of inches?
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.
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?
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.
Stackable boards is so 80's...
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.
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.
That being said, I still think its important that the 'brain' hardware is designed for an easy interface to a PC.
Each sensor a device on the bus or a sensor controller on the bus?
The comm on the devices (which typically have an ATmega uC onboard) is all done through the hardware UART.
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...
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?
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....