Time for a Bot Board redesign, what features should we add?

[robodude666]

@wowy7

that would be awsome

yes i agree there should be a feature like that

I personally agree with you

You guys could put a bootloader on the atmel so we can access the data using simple SERIN/SEROUT commands. Like this type of syntax:

To read digital pin:
R, pin#a,…pin#N example: R, P#1, P#3, P#5

To write digital pin:
W, pin#a,…pin#N example: W, P#1, P#3, P#5

To read analog pin:
AR, pin#a,…pin#N example: R, P#1, P#3, P#5

To write analog pin:
AW, pin#a,…pin#N example: R, P#1, P#3, P#5

Then there could be some extra commands like: version, PWM support, about (always gotta have an about)… And don’t know… some other stuff…

PWM:
PWM, pin#, frequency, duty

PWM Example:
PWM, P#3, 100, 50
Will PWM pin #3 at 50% duty at a freq of 100Hz

I think this will benefit many users and will make the Mini-ABB the most amazing development board ever!!

Hows this idea? A prototype board which can be plugged on the top of the Mini-ABB with a perf board and/or a solderless board

[linuxguy]

@robodude666

Would it be possible for you guys to add some I/O extensors or whatever its called? To give us more I/O ports =D What about having an ATMEL on board for that and going through the atmel via serial to get I/O data? Sort of like a small SSC-32 onboard but for general I/O stuff ?

I have three Microchip MCP23017 16 Bit I/O Expanders on the I2C bus with an Atom PRO right now. That gives a total of 48 additional digital I/O pins. It’s available in 28 pin dip, qfn, and a couple other packages I don’t quite understand yet. There is also an 8 bit version - the MCP23008. It would be nice to have at least one of these on a bot board to take the place of the pins we lose to analog I/O. I am going to experiment and connect a PING sensor to the MCP23017 and see if it works.

I2C is really cool, and now I finally understand it. I sure hope Jim runs with the production of Open Servo boards and related products. I see possibilities for very small motor controllers (regular motors, not servos), etc. A motor controller that can speak I2C, PWM, and maybe even SPI would be so awesome!

8-Dale

[robodude666]

Wow, these MCP23017 are nice!!! Do you know if you can PWM the pins on it via sending I2C commands very quickly? If you can, that would be amazing!

[linuxguy]

@robodude666

Hows this idea? A prototype board which can be plugged on the top of the Mini-ABB with a perf board and/or a solderless board

I had thought this would be a good idea at one time, but after thinking about it more I don’t think so. There are not that many signals that would be useful on stacked boards. There would be power, ground, two I2C lines, two or three lines for serial I/O, and I’m not sure what else. I’ll have to check the pinouts of the Atom PRO. You could route those few signals between boards from a single connector with a cable.

I definitely would like to see the hardware I2C and Serial I/O pins brought to a pin connector with power and ground.

8-Dale

[linuxguy]

@robodude666

Wow, these MCP23017 are nice!!! Do you know if you can PWM the pins on it via sending I2C commands very quickly? If you can, that would be amazing!

I don’t know yet, but that is one thing I want to check out. I already know I can write to the device in either 8 bit (two ports) or 16 bit mode (single large port). I am sequencing 29 LEDs using 3 of the chips right now. I am going to try reading a PING sensor from one of the unused ports next.

8-Dale

[robotdude]

Ok, looks like the only real do-able addition to the BotBoard would be a dedicated I2C port. There just isn’t much room to add much even with the BS2 PS2 controller port removed. I have some real confusing issues with I2C support. I have read that the pull ups are different values for different devices, speeds, etc. What’s the best way to handle this. A trimmer pot with a resistor in series? The resistor would be the minimum value, say 500ohm, or 1k, and the trimmer would be say 50k? This would allow fine tuning of the pullup. Is it just one pullup or more. I need I2C for dummies. LOL

BTW the PS2 port will be moved to pins where it will work with the Atom 28 and the Pro 28! No more soldering pull ups on the back of the board.

[paulp]

or put one of this dil sockets so can use a respack

[italian_guy299]

BTW the PS2 port will be moved to pins where it will work with the Atom 28 and the Pro 28! No more soldering pull ups on the back of the board.

I like that

[linuxguy]

@Robot Dude

Ok, looks like the only real do-able addition to the BotBoard would be a dedicated I2C port. There just isn’t much room to add much even with the BS2 PS2 controller port removed. I have some real confusing issues with I2C support. I have read that the pull ups are different values for different devices, speeds, etc. What’s the best way to handle this. A trimmer pot with a resistor in series?

Would a jumper selectable pull-up resistor be a possbility? I’ve used both 1K and 4.7K with the Atom PRO I2C and haven’t noticed any difference. I have three devices on the I2C bus now and am adding an EEPROM.

@Robot Dude

BTW the PS2 port will be moved to pins where it will work with the Atom 28 and the Pro 28! No more soldering pull ups on the back of the board.

I’m sure this will be a very welcome change! This is one reason I have steered clear of the PS2 controller for remote control. I didn’t want to have to change anything when switching between the Basic Atom and Atom PRO.

8-Dale

[sn96]

Since we are talking features vs. periphials, and there is limited real estate on the board, I would rather have Blue Tooth vs I2C. If both I2C and Blue Tooth can fit, that would be a plus.

Blue tooth to me is a feature vs. a periphial and the components are very small and take little board space. Perhaps you could even program the Atom wirelessly vs. using the USB port?

So it goes like this:

• Remove the DB9 and replace with a USB.
• Add Blue Tooth.
• Add I2c if space permits.

Just some thoughts.

[paulp]

SN96

Bluetooth modules become obsolete quickly, the ability to direct connect a device is more important than embedding the device.

USB requires registering with Microsoft and won’t work on all platforms

[italian_guy299]

@SN96

Since we are talking features vs. periphials, and there is limited real estate on the board, I would rather have Blue Tooth vs I2C. If both I2C and Blue Tooth can fit, that would be a plus.

Blue tooth to me is a feature vs. a periphial and the components are very small and take little board space. Perhaps you could even program the Atom wirelessly vs. using the USB port?

So it goes like this:

• Remove the DB9 and replace with a USB.
• Add Blue Tooth.
• Add I2c if space permits.

Just some thoughts.

Absolutely agree on this one. I wouldnt mind if the board was a little bigger to fit these features if you had to. I think wireless is deffinately the way to go, that way the board can stay on the bot and be programmed. Just think what kind of applications this can fit!

[sn96]

@PaulP

SN96

Bluetooth modules become obsolete quickly, the ability to direct connect a device is more important than embedding the device.

USB requires registering with Microsoft and won’t work on all platforms

I agree, you would not want to only have Blue Tooth which is why you would have a USB interface. I’m thinking in terms of the majority of consumers that would buy the ABB board. I2C is not for everyone but it is nice to have for the more advannced users.

It’s just a thought.

[linuxguy]

@PaulP

USB requires registering with Microsoft and won’t work on all platforms

How does USB have to do with Microsoft? USB certainly works under Linux and FreeBSD.

8-Dale

[paulp]

If you just have the TX, RX and GND pins present as on the SSC then you can add anything you want, RS232, USB, WiFi, Bluetooth, Radio Telemetry or TTL straight to another board.

Instant USB…

sparkfun.com/commerce/produc … cts_id=198

Instant RS232

sparkfun.com/commerce/produc … cts_id=133

Each one of these that gets embedded pushes the cost of the device up by that much. Plus the cost of USB drivers and Virtual Port drivers

[linuxguy]

@SN96

So it goes like this:

• Remove the DB9 and replace with a USB.
• Add Blue Tooth.
• Add I2c if space permits.

Bluetooth can be added through a serial module, not requiring USB to connect it. Sparkfun has many different serial Bluetooth modules available and a great tutorial on how to connect and use them. I don’t think Bluetooth should be an option on what is suppposed to be just a carrier board for a microcontroller. A USB host controller would be nice to have on it though, along with I2C.

8-Dale

[paulp]

When you plug in a Generic USB device into a Windows P.C., If it can’t recognise the Device by its transmitted Identifier it will disable it.

That is why, lower cost devices always say dont plug the unit in until you’ve installed the drivers.

If the serial identifier is known by Windows it will prompt you for the correct drivers rather than disable it.

This doesn’t happen on Linux. USB is not part of the Core system as it is in XP. Its installed at boot as a driver not as a service.

[sn96]

@PaulP

When you plug in a Generic USB device into a Windows P.C., If it can’t recognise the Device by its transmitted Identifier it will disable it.

That is why, lower cost devices always say dont plug the unit in until you’ve installed the drivers.

If the serial identifier is known by Windows it will prompt you for the correct drivers rather than disable it.

This doesn’t happen on Linux. USB is not part of the Core system as it is in XP. Its installed at boot as a driver not as a service.

So what are you saying? No USB and No Blue tooth? only I2C? I havent heard any suggestions as to what you would want to see on the ABB.

For me Blue Tooth would be a fantastic addition (My opinion) I don’t think the technology is changing so fast that by the time you get the product out it has undergone a 180deg. change. The blue tooth products on spark fun have been on the website for a long time. My Microsoft PDA phone can connect to my friends Black berry with no problems, The compatability is very diverse.

Blue tooth would enable a wide range of uses not to mention wireless.

[italian_guy299]

I agree, it would be a much better idea because you can run the robot and find where your programming errors are and than correct them quickly and wirelessly with no strings attached. I think its just really a time and cable thing really. But it would really solve the “my USB DB9 adapter dosent work” problems.

[paulp]

@SN96

So what are you saying? No USB and No Blue tooth? only I2C?

I have said what should be there. The TTL level I/O pins for serial data.

If you go Bluetooth you cant adapt to USB or RS232, none of them are interchangeable.

If the TTL serial is there then with the addition a 1 single module, as I posted above, you can go anyway you want. It would be much more versatile and keep the price right down.

Its exactly how the SSC-32 has it implemented.

I think there may be some misunderstanding exactly what serial data is. USB, RS232 Bluetooth etc are all highly specialised methods of carrying serial data over distance. They all start at low level as either CMOS or TTL level as they come out of the chip.

Someone mentioned stackable units. This is more like pluggable. Plug the Technology you want into a socket on the board.

One thing you may not have considered is that if you have a wireless unit on the board then it cannot be put inside a robot that has a metal or fibreglass hull as this disperses or blocks the signal. Also you may have to present the unit for FCC (Home Office in the U.K.) approval.