Bioloid I/O firmware

[limor]

This was posted on the previous thread.
Here's some basic C code that works with Pepper's V1 board:
http://robosavvy.com/Builders/limor/Pep ... -works.zip

[limor]

I really think we should focus on what's the shortest path to having an affordable board for all Bioloid fans. RoboSavvy can take on the cost of manufacturing the board in limited quantity and offer it to the public initially at-cost to cover expenses (at least the first batch).

It is a very simple board:

1) AtmegaXX
1.1) boot loader (so no need for programmer pins)
1.2) operating at 3.3V to ease connecting gyro & accellerometer
2) 3.3V voltage regulator
3) 4-pins that drive the connetion to the Bioloid 1-wire bus
4) Bioloid female socket
5) Atmega I/O ports connectable via holes or pins on the board


Approach 1: create an independent new custom board (such as suggested by Pepper and Hylands)

Approach 2: create a daughter board to an existing controler board, that would only deal with the "4-pins that drive the 1-wire bus" and maybe also do the 3.3V voltage regulation if needed.

Approach 3: contact a maker of an existing cheap Atmel board (such as Olimex) and see if they can come up with a really simple and cheap solution to complement their existing board.

feedback welcome !

[JonHylands]

Regardless of what other people decide, I have to go with approach 1 for what I need - the space constraints are simple too tight. The foot pressure sensor boards I am doing are 1" x 3/4", and on that board I have to fit a bus connector, a programming header, an ATmega168, and 4 2-pin connectors for the pressure sensors, plus a voltage regulator.

My software is coming along nicely - I have the control table set up, with special handling for the EEPROM values versus the RAM values. I can do arbitrary READ_DATA and WRITE_DATA commands (as well as PING). The IMU is hooked up, and the six 10-bit values are feeding into the corresponding RAM registers in the control table at 100 Hz. I'm also updating the LED from the LED register, so if you write a 0 or 1 to that location, it turns on/off the LED. You can change the ID of the sensor as well, since that is just another location in the control table.

Right now, the only issue is the UART code I am using is the standard UART, which assumes two data lines. Once my brother gets the UART module from the ATmega128 extracted and generalized, I'll be able to use that in my code, and actually read the response packets I am current sending off to /dev/null...

I also need to spend some time robustifying the code, specifically doing range checks on control table reads & writes, marking some of the control table locations as read-only, and that sort of thing. I'm using the response delay to pause before sending the response packets, but I haven't integrated the baud rate or the status return level.

http://www.huv.com/blog

- Jon

[pepperm]

Limor

I am beginning to think that we could either just use the Baby Orangutan board from Pololu with a simple and very daughter board for the whole project. You can see a photo of my test assembly on another thread. This would be good especially if we adopt Jon's "no driver" approach to comms on the single wire interface. I am investigating this right now.

In this case the daughter board could carry voltage regulators or just a 5V accelerometer like the MX2125 or AXL202, or better.

The other approach would be to take the Baby Orangutan board and re-deisgn to remove the motor drive chip and maybe add an accelerometer in it's place. Then manufacture this board. The components, especially the MLF processor are really beyond all but the most dedicated home constructor (with a reflow oven) so would have to be put on at manufacturing. The Orangutan is sold for $30 so it must be manufactured for less, but in what quantity I have no idea.

What are your thoughts?

Also just noted that you say the serial llink is a 4 pin connector. A slip I guess because it is a 3 pin one.


Jon

How does your code handle the USART Txd and Rxd lines just being shorted please? Are doing something with disabling USART input when transmitting data and putting the Txd line into input or high impedance when listening for data?


Everyone

I've spotted a slight problem with the Baby Orangutan mother board. The problem is that on the Orangutan board the LED is connected to PortD.1, the same port used by the USART for serial data out. This isn't too much of a problem in its self other than we can't easily turn the LED on and off when the pin is used as the USART output pin.

So I propose a small mod to the Orangutan board. You need to cut the short track that comes from a via that comes through to the back of the Orangutan PCB between the PB5 and PD0 I/O pins. Then run a fine bit of wire from the via to the PD2 pin. The LED will then operate on PortD.2.

Oh by the way, you don't have to do this but on the Accelerometer version of the board I have decided to use the PC2 pin on the daughter board as a 5V line. Then a single connector on that side of the board will connect you to the I2C, low baudrate serial, GND and 5V. This provides for easy connection of external devices. I have cut the pin that would go from the daughter board to the Orangutan board so that PC2 does not get permanently connected to 5V.

[JonHylands]

Jon

How does your code handle the USART Txd and Rxd lines just being shorted please? Are doing something with disabling USART input when transmitting data and putting the Txd line into input or high impedance when listening for data?

The code basically disables the Rx side when transmitting, and disables the Tx side when receiving. If you're interested in looking at it, the source is here (written by my brother Dave):

http://websvn.hylands.org/filedetails.php?repname=Projects&path=%2Favr%2Fbioloid%2Fbioloid.c&rev=0&sc=0

I'm going to put up a pre-release of my code, which is in pretty reasonable shape to look at. It isn't fully tested, and I'm still waiting for the new UART module from my brother, but it will give you an idea of what I have done.

This implements most of what we need for a Bioloid sensor.

http://www.bioloid.info/tiki/tiki-download_file.php?fileId=78

Comments and feedback are welcome...

- Jon

[pepperm]

Here is a picture of the back of the Baby Orangutan board with the daughter board and accelerometer mounted on the other side to show the mods required.



Mark

[limor]

pepperm,

regarding the 4 pin - what i meant was that in the Robotis-recommended circuit for driving the 1-wire bus, they use 4 pins RX, TX, PD6, PD7 on the ATmega8.

Please have a look at Olimax board based on ATmega128 (US$30)

http://www.olimex.com/dev/index.html

has 5V regulator and no need to hack the board if we go with JonHyland's software solution.

[limor]

they also have the Atmega16 and Atmega32 prototype boards

smaller board but not sure if it has voltage regulator
http://www.olimex.com/dev/avr-m16.html

[pepperm]

Limor

Sorry for the misunderstanding of the pins.

The board you show is certainly useable but it is a bit big at 47mm square isn't it. At that size I could make a board with everything on it I suspect. The 128 processor is more capable though and has 2 USARTs which would be good.

The mega12/32 board are also a possibility but again are big compaired to the Orangutan, and no voltage regulation.

Do you think there will be a problem getting the Baby Orangutans?

Mark

[JonHylands]

The ATmega128 is a little bit overkill for a sensor board. I'm using the Olimex ATmega128 board as my CM-5 replacement, but in my opinion (for a sensor board) it offers nothing useful (other than 2 hardware UARTS) that the much smaller and simpler ATmega168 has. The other big advantage to the ATmega168 is that it comes in a DIP form package for prototyping, which is nice.

My brother put together a bit-banged, timer-based one-pin transmit-only UART that runs on the ATmega168, which I use as a debugging console, so only having one UART is not a big deal. That code is in his public repository, so anyone who wants to use it is welcome to.

- Jon

[pepperm]

..... it offers nothing useful (other than 2 hardware UARTS) that the much smaller and simpler ATmega168 has.
- Jon

I wish the 168 had 2 USARTs, but it only has 1, USART0 sadly. It's the same as the Mega8 but with more (and longer lasting) flash, a higher top clock rate and twice the number of PWM channels. Unlike the mega8 though it will run at 16MHz on anything above 2.7V (if I read the spec sheet correctly).

Mark

[JonHylands]

I wish the 168 had 2 USARTs, but it only has 1, USART0 sadly. It's the same as the Mega8 but with more (and longer lasting) flash, a higher top clock rate and twice the number of PWM channels. Unlike the mega8 though it will run at 16MHz on anything above 2.7V (if I read the spec sheet correctly).

Mark

No, at 3.3 volts you can only run at 8 MHz (well, 10, but we need 8 for the USART).

From the front page of the data sheet:

"ATmega48/88/168: 0 - 10 MHz @ 2.7 - 5.5V, 0 - 20 MHz @ 4.5 - 5.5V"

You can still do 1.0 Mbps at 8 MHz though.

Like I said, not having the extra UART isn't that big of a deal - I have a console logger that will log at up to 38,400 baud off any of the normal I/O pins of the ATmega168.

- Jon