Low Cost Linux Controller

[i-Bot]

I've been using the Bifferboard with dynamixels for a while and find it an amazing efficient Linux controller at such a low price.

Following discussion with Limor on how to better exploit this board, I have made a preliminary design proposal here:
http://robosavvy.com/site/index.php?opt ... 5&Itemid=2

The board is targeted at robots requiring performance in the 10ms time frame. Communication over WLAN, bluetooth and other media is integral at low cost using tiny USB devices.

The Bifferboard processing power, whilst not stellar, enables the board combination to publish and provide the supported robotic service resources, and still have available local processing power.

Reuse of existing applications and drivers is exploited where possible with emulation of existing hardware. The design is modular and not restricted to Robotis, and will support components from Hitec, Kondo, Robobuilder, and the new clone suppliers.

Design will be licensed under GPL and Creative Commons, though if sufficient interest is shown here, Robosavvy will stock and support it.

Target price is 50UKP ! Are we crazy ?

So, your chance to comment, influence, or support.



-------------------------------------------------------------------------------------------------------
-- [[ Limor: i've copy-pasted the description from the article page to the forum so that all information is in one place ]] --
-------------------------------------------------------------------------------------------------------

Based on my recent experience with the low cost Bifferboard and various interfaces, I now propose a new support board for the Bifferboard.

This description concentrates mainly on the hardware features, the software features, including architecture will be better explained in another post.

Bifferboard is a low cost (30 GBP) linux controller:

- 150MHz Intel 486sx compatible cpu
- 32 MB SDRAM, 8MB Flash
- High Speed (480Mbps) USB 2.0 Host Port
- 1 watt power consumption (200mA @5v)
- 55mm x 28mm x 21mm (weight 15g)

While Bifferboard includes Ethernet interface PHY on board, this is of little use in mobile robots, so not used.

It is proposed to use only the main processor board and not the existing support board with power supplies, switch, LED , connectors and Ethernet magnetics.

Bifferboard does incorporate High Speed USB 2.0 interface, which is a low load on Bifferboard CPU; offers high bandwidth, and low cost peripheral support (WLAN, Bluetooth, Flash, video)

To support the Bifferboard for mobile robot application, three functions are added:

1) Power Supply to support Bifferboard and attached devices

2) USB Hub to expand number of USB Ports

3) I/O Controller to support real world devices (servos, sensors,
communications)



Software will be open source and distributed under GPL License
Documentation and hardware designs will be distributed under Creative Commons License

Bifferboard
As described above, the Bifferboard will be used without the existing I/O board, so external power supplies are required.

Serial debug and JTAG connector direct to board are retained.

Existing GPIOs are not used, except for the Reset and Boot to I/O processor to enter device firmware upgrade mode.



Power Supplies
- Power supplies are required for the Bifferboard at 1.8V for the CPU core and 3.3V for the I/0

- The USB hub and USB devices requires 5V supply

- The I/O controller and attached I/O devices require 1.8V core, and 3.3V or 5V for I/O

The proposed power supply:



Most likely based on Allegro A4490 triple buck regulator

No power switch is proposed on the board, and it is intended that power to servos is distributed external to the board. This enables servo power to be cut without reset of Bifferboard.

USB Hub

Since USB is primary I/O channel to Bifferboard, the single USB port must be expanded to sufficient ports.

External hubs are low cost, but have high demand on space and flexibility.

It is proposed to incorporate a 4 port USB 2 high speed hub into the robot board.

The hub will likely be based on low cost and low pin count GL850 type and only have single transaction translator.

Connectors will not be standard USB due to size and cost.. Low cost adapter cables will be available or direct wiring used.



I/O Controller

The I/O controller is the most demanding part and the design is based on target functionality, and the proposed software architecture.

Software architecture and proposed implementation will be described in a separate article, but is based on the Dynamixel protocols to ensure compatibility and performance.



I/O controller will support physical Dynamixel devices connected to the 1M bps serial busses compliant to AX or RX Robotis interface. These may be Robotis or 3rd party.

New physical devices are proposed to support legacy PWM servos, and to offer functions required for more complex robot sensors.



I/O Controller features will be available as virtual Dynamixel devices. And will include:

- Analog and digital I/O controller ports presented in manner similar
to Jon Hylands I/O module
- I2C controller to interface to the I2C interface on the I/O
controller

- Multicast controller to provide SYNCREAD function and multiple serial
bus management

- Robobuilder Proxy to map Robobuilder serial protocol to Dynamixel
protocol

The addition of SYNCREAD to the Dynamixel protocol improves performance in the interface with the Bifferboard.

Other Dynamixel protocol extensions may be added if needed to provide
stream interface as add on the existing memory map approach.

The processor proposed for the I/O controller is the Atmel AT32UC3B1128. This processor has the required I/O ports and adequate performance.

While the above software will be developed for the I/O controller, alternative software may be written to run direct on the I/O controller. The AT32 is already supported under libbioloid and freeRTOS.

The AT32 has integral device firmware upgrade (DFU) over USB and will be invoked using GPIO pins from the Bifferboard.



I/O Processor has integral USB Full Speed device interface. A high speed interface would have been preferable, but no controller with the required I/O ports was found at a reasonable price.

Physical Layout
The board will be physically small as possible with a footprint of about 65mm by 40mm and a height of 21mm with the Bifferboard installed.

[billyzelsnack]

Do you think that this little guy is fast enough to wifi transmit video to a desktop machine for processing and have enough left over to control dynamixels?

[i-Bot]

I have not run video through the Bifferboard, though there are some guys here who have:
http://groups.google.com/group/bifferbo ... bebc109b9#
They may be able to give some performance data.

I guess I would have some concern on maintaining target response time on dynamixels when this is running. It does raise some questions we had about delegating more functions to the real time I/O controller by adding a pose+transition, or even motion manager to the I/O controller.

What are your thoughts ?

[limor]

Do you think that this little guy is fast enough to wifi transmit video to a desktop machine for processing and have enough left over to control dynamixels?

Assuming the control of the dynamixels is based on an SYNCREAD API between Bifferboard and AT32 then the Bifferboard has to receive compressed servo status data from the AT32 100 times/sec. it then sends control commands to the AT32 at whatever rate it wants.

What the Bifferboard does to decide what control commands to send the AT32 is up to the programmer and will vary from simple gait management to very complex stuff. This depends on the programmer and on availability of CPU resources at the Bifferboard.

Once the Bifferboard side control is defined (by the programmer), there may be ways to reduce the CPU load on the Bifferboard by delegating some intelligence to the AT32 or even to the Dynamixel servos. but it completely depends on the type of control system that one wants to implement.

For example, if all you want to do is gait orchestration, you can pretty much put the pre-defined gaits on the AT32 and do some orchestration on the Bifferboard. (reducing the CPU load on the bifferboard)
IF you want to do compliant gait that senses the environment and change the gait upon changes to the typical response pattern from the servos.. then you may need to manage the gaits at 100Hz in the Bifferboard and react to changing environment by interpolating gaits or whatever. (high CPU load on the Bifferboard)

[limor]

Regarding the 2 UARTs that are meant to interface with the robot:

(a) can both UARTs have all interfaces for RX, AX, Kondo, Robobuilder plugs and interfaces?

(b) can both UARTs be allowed (via switch) to have 2 separate power sources?


The first request would be needed to widen the scope of audience. This is necessary in order to justify manufacturing hundreds of boards professionally in order to bring the retail price to the bare minimum, which is RoboSavvy's intention. [ RoboSavvy will send i-Bot the needed servos for testing ] FYI: Kondo Just launced a 600$ ARM9 Linux board that runs at 200Mhz compatible with KHR3.

The second request would allow for robots that have 2 sets of LiPo and/or to mix servos from different manufacturers on the same robot.

[billyzelsnack]

I would just like to offload all the real work onto my desktop machine without requiring a tether.

[limor]

I would just like to offload all the real work onto my desktop machine without requiring a tether.

It is to be one of the supported use-cases for the interface board with the Bifferboard - to relay the SYNCREAD functionality over wifi to a remote PC. latency permitting.

[i-Bot]

I looked again a the UART Options.

First it appears that although the AT32UC3B1128 has 3 UARTS, one is not accessible . Three UARTS are accessible on 0128 variant. How important is having 3 UARTS ?

Each UART and interface circuit can be soft configured to 3 wire TTL(AX Bus), 4 wire TTL, or RS485(RX Bus). AX Bus and RX Bus can work simultaneously with id ranges set in the multicast controller. 4 Wire TTL and AX/RX bus can work interleaved if 4 wire is using master slave polling (Robobuilder, KHR). The choice of what connectors to populate is a tradeoff of board real estate, and to a smaller extent cost.

I was hoping to keep servo power off the board, and have it as a control board. Making the board capable of power distribution especially if multiple batteries and switches will increase size considerably. Your thoughts ?

[limor]

First it appears that although the AT32UC3B1128 has 3 UARTS, one is not accessible . Three UARTS are accessible on 0128 variant. How important is having 3 UARTS ?

2 is better than 1 which has been the most there ever was on an interface board till now.

I was hoping to keep servo power off the board, and have it as a control board. Making the board capable of power distribution especially if multiple batteries and switches will increase size considerably. Your thoughts ?

The board's components can be powered from battery1. UART1 is powered from battery1. UART2 can be powered from battery1 or battery2 (requiring a switch). battery2 doesnt have to be routable to the voltage regulators. just as an alternative source for UART2. This tiny switch (plus 2 input power interfaces instead of one) can provide a lot of unique functionality IMHO.

[limor]

I've made a list of our objective "Killer features" for this new board.

Introduction:

Since the emergence of the hobby robotics market, robots have always been controlled microcontrolers with very limited abilities. The ability to control the robot using embedded Linux brings a world of new possibilities and opens up the robotics world to a wider audience. Having a more powerful CPU means being able to perform more interesting robotic activities such as image processing and dynamic gaits.


Following the footsteps of the revolutionary 1Ghz RoBoard, we would like to design a low-cost, small form-factor board that when linked to any embedded linux board, will serve as the most versatile robot brain.


General features:

• Targeted as bridge board between serial servos and embedded PC (such as Bifferboard, gumstix or a PC/laptop)
• Targeted as a general multi serial servo type robot controller board with support for lots of I/O.
• Can interface with all Robotis, (SpringRC/Up-tech), Robobuilder and Kondo ICS3 servos.
• Facilitates attaching USB devices to robot - web-cam, wifi, sound
• Small form factor - the aim is to get it to around 4cm x 7cm and 2cm height with the Bifferboard, which should fit into all available humanoid robot packs.
• Target retail price ~ $70US [ or sub $100US with BifferBoard ]. I don't plan for RoboSavvy to make much profit on this board, although I would like other robot shops around the world to sell this board and therefore there needs to be some margin. Hopefully the board will appeal to at least 500 people and that will lower the BOM and assembly costs.
  --- Your input at this stage is critical in order to get it right the first time and lower its cost ---

Hardware:

• 2 serial ports, each one can be linked to 3-wire or 4-wire ttl servo busses. Allows mixing servo types on the same robot
• Each serial interface can be routed to independent power supply (ie: support dual battery and/or dual type of servos)
• Support for 6V to 24V input - LiPo
• AT32 chip - 32 bit low cost 60mhz chip with USB and 3 serial ports. i-Bot has code that can emulate FTDI but with less overheads and lower latency than a standard FTDI chip. PC thinks he is talking to FTDI.
• USB hub chip - provide multiple USB devices and 5V power to embedded PC. one port taken by AT32 and 4 available for PC and other devices such as camera, sound, SD card. - This is the first ever robotic board that incorporates a USB hub
• Lots of I/O pins and through-holes including A/D and I2C - everything you want to connect to your robot will be supported out of the box - from IMUs to encoders
• provide on-board interfaces to attach a BifferBorad with no soldering --> The first ever robotic Linux board for under US100$.
• No PWM servos control from this board in order to keep the size to the bare minimum -- enough of those on the market (the only caveat is that it would be great to have a pseudo Dynamixel protocol to control servos, so maybe a clever PWM servo control board will be developed later)
• micro-SD - (maybe) lets the AT32 access to lots of flash memory for saving gaits and such. It will also allow the Linux to see that same SD card while at the same time seeing the FTDI port. USB interface shared by 2 firmwares on the AT32. This saves one USB port taken by memory stick. downside is that micro-SD interface takes up real-estate on the board and adds cost.
• fuses - (maybe) it is important to provide over-current protection but these things are expensive and take up board real-estate.
• voltage measurement (maybe) - to warn of LiPo low voltage. This can be achieved by the user in software by querying the serial servos that do have voltage measurement circuits.

Opensource Software:

• firmware for FTDI emulation
• firmware for mass-storage class giving access to onboard SD card
• firmware for communicating with serial servos
• firmware for optimal "SYNCREAD" cycle of broadcast-then-query all servos.
• firmware for providing API to PC for abstracting reading/writing to servos, sensors, I2C etc.
• Linux/Windows software for capturing and playing standard gait "servo orchestration"
• Linux/Windows software for adaptive control using 100Hz or so control loop to demonstrate adaptive gaits and compliance

[Stephane]

Hello Limor,

I have toyed with a similar project for some time, but my purpose was rather to build a main board and do everything in firmware. Of course, I don't have the ambition to rely on a webcam, or even to have wifi connectivity (bluetooth or zigbee uart bridge woud be enough for me), so I can stick with microcontroler-class processing power.

Though the finality of your board is not the same as mine, my considerations can give you some inspiration.

Because I have programming background on this architecture, and they provide more power than AVR for slightly upward cost, I have rather been considering ARM MCUs. More specifically, I settled for NXP's LPC17xx, which features USB (including host mode), 4 UARTs, a few PWM, I2C, SPI, C.A/N, 100MHz clock and low latency interrupt modes. I acquired a couple of pieces from DigiKey for 7.29 euros each
Using one of the I2C or SPI, I would connect a PIC to serve as IO hub. I would rather rely on the IO Hub to generate PWM because the ARM doesn't have so many of them.
Last, I considered having an IMU onboard, and optional wireless connectivity.

Unfortunately, work has been keeping me away from hobby for some time and this project is not much more than a handful of chips in my storage for now...

Good Luck with your project!

Stéphane

[i-Bot]

I have put together some draft schematics based on ideas and feedback already received.
They are in the my file area:
http://robosavvy.com/Builders/i-Bot/Bif ... fbase2.pdf
I can make the Eagle sch file available if anyone prefers.



The serial interfaces are designed to support 3 wire TTL for Dynanmixel AX type servos, 4 wire TTL for Robobuilder duplex type servos, and RS485 for RX/DX/EX type servos. Each UART can switch in software between types, even allowing a single UART to support different types simultaneously. I still have to check how the Kondos would fit into this !

The jumpers allow battery power to be put onto the servo connectors to support minimal configurations. The links may be removed to support more complex multibattery arrangements where battery power is applied direct to the servos.


The interface to the Bifferboard is through the High Speed USB 2.0 interface. Other than this, only a couple of GPIO are used to optionally force the I/O processor into device firmware upgrade (DFU) mode to update its firmware if required.
The integrated USB 2.0 HUB allows the I/O procesor to connect up to 3 USB 2.0 High/Full/Low Speed devices. There is some checking to do on the actual hub IC because of reports of performance dependancies. The objective is to to integrate a peformant hub, so eliminate these issues.
USB ports are brought to a right angle header rather than USB connectors. USB connectors and cables tend to be large, expensive, and inflexible. Adapter cables will be provided, though often direct wiring for tiny USB devices is best. The Input to the USB Hub is also brought to the right angle header so the board can be used with other Linux or XP controllers though an adapter cable if the Bifferboard is not present.


A triple power supply providing 5V, 3.3V and 1.8V is provided, with sufficient capability for the board, connected USB devices, and other I/O devices needing 5V or 3.3V. Fuses are provided on the board supply and the supply to the servos. No switches have been added due to their demand on board space. Anyway two switches may be required to separate the servo power from the processor power(kill without reboot!)
Some feedback would be appreciated here if greater power flexibility is required at the likely expense of board size, and to a lesser extent cost.
I did not comit any A-D channels for battery voltage or internal temperature monitoring in this design.


The AVR32 IO processor brings out as many analog and digital ports as possible, and provides I2C two wire interface and SPI bus interface.
I did not put a micro SDcard on the board due to space, though this could be added.

Here is what we might see as a board profile. The objective was to arrange the IO connectors around the Bifferboard in minimum size.


Your comments would be appreciated.

All hardware designs will be made available under a creative commons license when finalised.

[chrisvo]

The Kondo ICS3 servos use 3-wire TTL almost identical to Dynamixel AX servos except they operate at 5V logic. I use an identical circuit except without the 47R resistor on my KRS-2552HV (KHR-3HV servos) with success. If I put the resistor in, it won't communicate.

The serial interfaces for Kondo ICS3 run at 115200 8E1. But the servos support up to 2M baud rate if you need to do hard-core feedback control.

Kondo also has a circuit schematic of their KCB-1 (programmable servo controller that supports ICS3.5 protocol) on their web site but it's locked with a password -- let me know if you want a copy.

Stéphane: I'm using NXP LPC17xx series in my own version too! But I have the same dilemma too - work keeps me away from my hobby lately...

[limor]

i-Bot, looking forward to see the alternative design you proposed (offline) involving 2 separate boards stacked up. one including the USB hub and voltage regulator and a second including the AVR32, SD card and connectors to serial servos.

[gclaudiu]

This looks great i-Bot! I'm looking forward to see this project going live. Really interested to buy one once is ready ^_^