I’ve recently been focusing on making open hardware “reference designs”. Kovan is the codename for a circuit board I designed, intended for autonomous robot control applications (fun fact: all my codenames are metro stops in Singapore). I think Kovan could benefit many niche applications, particularly those that are less cost-sensitive and require a more integrated solution than a cable-spaghetti of daughtercards plus a Raspberry Pi or Beaglebone plus USB dongles.
Kovan is highly integrated, and incorporates features such as an FPGA. The use of an FPGA to interface with the control inputs and outputs offers a unique opportunity for developers to create very precise, low-jitter control loops in VHDL or Verilog, leaving the CPU free to do other tasks. For example, the reference FPGA design uses a system clock of 208 MHz for the servo pulse width controllers, allowing for a 5-nanosecond pulse resolution programmed using 24-bit control registers.
You can grab the source for the hardware through these links: gerbers, schematics in PDF format, 3D STEP model of the circuit board, the native Altium designer source files, and the FPGA source code in verilog. Updates and new developments on the board will be posted and archived at the Kovan wiki.
The next natural question is, of course, ‘how much and where can I buy one?’ This is where things get a little bit unusual. When I release a “reference design”, it means that a third party would market the product. An example of this is the Kickstarted Safecast X geiger counter based upon the geiger counter reference design that I released in January. I’m not producing the geiger counter — International Medcom has instead picked up the design and they are producing and marketing it.
In this case, Kovan is being used by KIPR for the botball educational robotics program. Botball also had a Kickstarter campaign to pre-fund the initial build. Below is the video they produced to promote their product.
While the fully integrated controller won’t be available for sale until early next year through Botball’s store, Adafruit is kind enough to distribute a limited quantity of the motherboards on my behalf in their store. I plan on making a couple dozen boards available to interested developers who can’t wait until the full kit is available through botball. The board alone plus power supply is available for $249, whereas the full botball kit shown in the video above, including LCD, battery, case, software, etc., will go for around $400.
The reference development environment for Kovan is based upon the OpenEmbedded Angström distribution, similar to the system used by the Beaglebone. The firmware version we’re shipping inside the Adafruit boards comes with gcc and Python pre-loaded, so you can get started right away with development — no need to set up cross-compilers. You can download and build your own firmware from source if you want by following this guide. Note that this firmware is different from the one that will be provided with the Botball version, in that this firmware is entirely open source and is targeted toward developers with prior programming experience.
Keeping with a tradition started on this blog long ago, the first user to correctly guess or otherwise determine the number of vias on this circuit board will win a free Kovan board as a prize!
More about the Hardware
Features
Kovan integrates onto a single PCB all the features you need to build a self-guided robot:
- Actuator capability
- 4x 1.2A H-bridge motor drivers
- 4x servo drivers
- Sensing capability
- 8x 10-bit analog inputs (5v/3.3v gang-selectable input range with individually programmable pull-ups)
- 8x digital I/O (5v/3.3v gang-selectable levels with individually programmable pull-ups)
- Rapid-prototyping headers (each I/O pin has adjacent +/- power rails so as to simplify sensor biasing)
- 3-axis accelerometer
- Connectivity
- 802.11b/g wifi
- 2x USB 2.0 ports (suitable for video input via webcam)
- 2x 3.3V UART (one console, one expansion)
- IR rx & demodulator
- IR tx (modulation to be done in FPGA)
- UI
- LCD + touchscreen connector (natively supports 3.5″ screen)
- Mono audio output
- Pushbutton and status LED indicators
- Optional digital video output driven by the FPGA (NeTV users might recognize the motif)
- Processing
- Linux 2.6.34 running on 800 MHz Marvell ARM w/128 MB DDR2 + 2 GB microSD for firmware storage
- FPGA co-processor enabling hard real-time control extensions & advanced image processing extensions
- Battery
- Integrated 2-cell Li-Ion battery charger (C=1.5A)
- Board runs for about 4 hours on a typical 1800mAh 2S1P Lipo RC pack (no motor load condition)
- Battery plug uses Molex rectangular housing 0039013022 (Digikey WM1021-ND) with crimp terminals Molex 0039000207 (Digikey WM3116CT-ND)
- Note: battery or battery emulator required for proper operation – board will not boot otherwise. For battery-less operation, it’s recommended to power the board using a 7.5V power supply (such as Digikey 62-1169-ND) plugged into the battery socket using the above Molex connectors. Do not simultaneously use a battery emulating power supply and a primary power supply, as this would cause the battery charger to attempt to charge the emulating power supply!
Looks pretty useful, I like the idea of a FPGA to drive the control IO coupled with a normal CPU to handle the rest.
My guess, and I have no experience with hardware design so it could be completely off, would be 250 vias?
My guess: 1517 vias :-)
Nice board! But why the archaic ARMv5te CPU? Why not for example a BeagleBone CPU?
It’s actually a custom core by Marvell…so even though the instruction set is old, the performance is a bit higher than the equivalent ARM implementation, and it hits a higher MHz than most cores of that generation. So, the integer performance is probably comparable to that of the Beaglebone’s CPU. That being said, it meets KIPR’s requirements and it’s the devil I know.
There’s a new board I’m working on, for a different application space, with a more modern core but it’s also a much more expensive chip…
pxa166 is definitely a reasonable choice. It’s the first PXA that is supported in the kernel as mach-mmp, which means it will be supported with all the latest kernel features in the future (single zImage, device tree, common clock, …), unlike the pxa950 that are actually ARMv7 but are part of the “old” mach-pxa hierarchy. It also doesn’t seem to require a closed source GPU driver, unlike most of the more modern SoCs.
I’m guessing 1648 vias :)
My guess: 1414 vias. :)
1337 vias
1517!
Aww… Hugo beat me to it. :(
I was sitting at work designing a board in Altium when I saw this, so it was too easy to just check :-)
Haha, same here!
1518 vias! You guys with Altium clearly forgot that J701 can be considered a huge via. :)
Can you provide more info on the FPGA? Everything else is common. How does one load the FPGA firmware from Linux?
The FPGA shows up as a block device, /dev/fpga. To initialize the FPGA, you first call an IOCTL on the device which pulses the program pin (there’s a helper program to do that). Then, you cat your bitfile to it, and it blasts the cat’d data out the serial programing pins to the FPGA.
Looks great, but doesn’t seem like it has enough I/O’s to run a practical robot. The Roomba had at least 25 I/O’s (a few analog in, 12-15 digital in, and around 10 digital out). However, some of that is in peripherals already on your board (h-bridges, IR, etc.). I remember being surprised at the amount of I/O signals used to control such a seemingly simple robot – it made the search for processors challenging.
Though with the FPGA interfacing to the outside world, you could build a decent I/O expander board and use a fast serial protocol to get the quantity of I/O’s you would need.
We’re also pushing a robot kit at the moment – but into a more cost sensitive market – here in NZ we have a kids school robot competition (“RoboCup”) – it’s intended to encourage learning programming at the high school level – sadly in practice it has meant building stuff with the lego kits – at $500+ a piece a robot soccer team costs over $1000 – only really available at schools with parents who can raise lots of money – there are smart kids at poor schools too
We’ve done an arduino based kit that’s intended to be assembled by kids as a first soldering project (all through hole parts except one that we do for them) – NZ$25 – open source hardware so feel free to steal it
http://www.taniwha.com/~paul/dspace.robot
Dual h-bridges, USB serial, 3 servos, 6 sensors – we happened to choose the same pinouts as Seeed’s Grove boards, but 0.1″ rather than 2mm so now we provide both pinouts on the board
2000 vias.
1,890 vias.
What do you think of Altium?
I am trying to do a Marvel + 2 chip DDR2 layout in Eagle. It is a lot of killer manual work trying to get the DDR2 layout right. It has caused me to look around for another CAD package. Cadence might be what I want for features but is on a completely different planet as far as price goes. Altium is still expensive, but in the realm of possibility assuming I can live on canned tuna for a few years. :-)
I love Altium. Then again, I’ve been using it for like, over a decade, so it’s like a second skin to me when I do board design.
I’ve played with the other tools from Cadence, etc. and they don’t feel nearly as tight or as well integrated. Altium has great 3D integration, which is key if you’re doing cased consumer products with tight geometries. Layout is fast, intuitive, and the design rule suite has a grammar complicated enough for me to automate & manage even complex rule decks with multiple impedance controls, plane clearances, and rule exceptions. Reworking existing IP (mix & match schematic, layout) into new designs is also pretty clean with Altium.
Altium’s weakest point compared to other tools is probably signal integrity, but it’s good enough for me to get boards up using DDR3-1066 SO-DIMMs without too much pain. If you can afford it, I highly recommend it.
I also use Altium professionally, and have been using it for about a decade too, and love it. I’ve only scratched the surface with Allegro & PADS (as my employer already had available licenses for both, so I had to justify the purchase of Altium), but from what I’ve seen they are more suited to a cleanly separated workflow where someone does design capture, then another does the layout, and the layout guy does nothing but layout, ever. As such, these tools have more in the way of “power features” but unless you’re spending years doing nothing but layout, you’re unlikely to be making good use of them. I find Altium has much better support for an iterative workflow, where I can change the schematics and libraries during layout and check things in layout and libraries during schematic design. Altium feels like one cohesive product, whereas the other tools from what I’ve seen feel more like a loosely coupled bunch of tools that you can use however you like. The later is of course more powerful if you need it, but since I only do board design perhaps 10-20% of the time, I appreciate something cohesively unified and simple to pick up again after a gap working on something else.
I also want to stress the great 3D integration Bunnie mentioned… for me I find that it’s invaluable even if you’re not designing consumer products with tight enclosure geometries – it also helps catch design mistakes much sooner and helps you really visualise every aspect of your layout and reason about it. For me, when I started using it, it essentially eliminated all instances of wrong footprints, connectors the wrong way around, and similar issues.
Usual disclaimers, but I too strongly recommend it!
Very nice bunnie! Did you consider the Zynq platform at all? Not enough LEs in the PL fabric?
Zynq == way too expensive :( but I would love to use it someday in a product, it’s very sexy.
What’s the bit about Altium and 1517 vias? Is it a reference to that youtube video? I’m going to guess 937 vias.
Is that an empty spot for DDR2 above the FPGA?
I’m guessing 1432 vias.
Then again impressive the very eveningwear might appear, your actual existing workload indicates the foremost to your business.
i have seen a handful of mobile browsers and applied a few of them, they are nonetheless somewhat slow;