FPGA-based Controller for Kinematic Systems

[wuselfuzz]

A small demo I made today to demonstrate the current IK engine capabilities. Excuse the braindead video format, I pulled it directly from the digicam and don't feel like recompress it on my old iBook.

http://fnord.terror.de/botfun3.avi

[wuselfuzz]

I finally made a yt account.

http://www.youtube.com/watch?v=5x8y48BBUAw

[TXBDan]

very impressive, man. Those movements look fantastic.

I'm not a big programmer (I'm a EE) so i've been struggling a bit about how to handle these algorithms in code. Especially the body translations and rotations. I still can't fully wrap my mind around that. I'm slowly digesting your code. Its pretty smart to me to make a bot struct and use a sort of current and goal "frame" with the structs..

I currently have my IK engine for a single leg with the "hip" as the origin of the frame. I'm a bit confused though on how to get it working with a single bot frame and all the six leg positions talking in terms of the main frame. When I calculated forward kinematics this was easier because i used matrix equations to define a frame at each joint. You just multiply down the path and it all works out. For the IK, i'm just using some geometry/trig and my brain is melting...

btw, did you mean for the youtube link above point to a frog demo? Did you make that as well?

[wuselfuzz]

Back from my Boston trip, fixed some transport damage and found some time for tinkering a bit again.

btw, did you mean for the youtube link above point to a frog demo? Did you make that as well?

Ooops. Was supposed to be this one:

http://www.youtube.com/watch?v=uINYeGkGkdE (yt version of botfun3.avi).

I also made a bit of progress with my cheap sensors. Still investigating, but here's a teaser:

http://www.youtube.com/watch?v=bDYR954u1xc

[Matt Denton]

Hi, good to see your fully YT enabled now, saves some big downloads

Those sensors look like they are working pretty well!!

[wuselfuzz]

Images/vids from my server are currently offline, because the server's gone for good - I shared one physical server with 3 other people using xen virtual machines, one of the neighbor VMs got hacked/exploited or something and the whole subnet containing our VMs was blocked by the ISP. New one coming up soon.

Project status:

1. I didn't pursue the sensor idea much longer, because I ran into trouble with my chalk/carbon mix. When the powder is ground too fine, the whole mix suddenly becomes totally non-conductive. Sand instead of chalk might work better, because grains of sand don't break down on pressure.

2. I ordered some electronics, specifically one FPGA board and one Eddy 2.1 ARM9 CPU module. At first, I'm porting my project to the new FPGA board. This is almost done, I made a new carrier board for distribution of servo signals for the new FPGA board and already ported the plasma system over. The last to-do is designing a new memory interface, because the new board's RAM is 8 bits only while the Digilent board had 16 bit RAM. The CPU uses a 32 bit data bus, so there's some glue logic necessary. The old design transferred data between the CPU and RAM on the rising and falling clock edge to hook the 16 bit RAM to the 32 bit CPU. This is obviously no longer possible, so I'm thinking about clocking the RAM at twice the speed of the CPU and transferring 4 bytes in a single CPU clock cycle. On the new FPGA, the CPU synthesizes for clock speeds up to 38 MHz, the board has a 66 MHz OSC, so the CPU is running at 33 MHz now (25 MHz previously, as the old board had a 50 MHz OSC and the design synthesized for a maximum clock speed of about 29 MHz).

Pictures:





I also started designing a PCB layout for the carrier board, the final version will probably include a MAX3232 LVTTL<->RS232 level shifter and a few 74HC08 for multiplexing the servo outputs (this saves 14 I/O pins on the FPGA).

When everything works again, I'll try hooking up the Eddy module. Tinkering with that is a bit problematic, because the connectors on the Eddy module are for pin headers in a 1.27mm grid.

[blegas78]

That's a very nice little FPGA board, it really gives the hexapod a polished look. I look forward to seeing it run with the new board!

[wuselfuzz]

News Flash:

HARDWARE

Complete assembly:



Lower Body part, electronics are inside the hexapod. MAX3232CPE with some caps for
RS232<->LVTTL level shifting on the left, ROK 101 007 bluetooth module in the middle.

Those modules are connected to two UARTs on the FPGA via a 6 wire
cable (GND, 3.3V, RXD, TXD, RTS, CTS - CTS/RTC currently unused).



This is the board that's mounted just below the upper body part, where the FPGA board is
plugged into from the other side. Power on the top right. 2x UART on the pin header in the
lower left corner. 18x3 pin headers for servos. The pin header in the lower right corner
originally were the UARTs, but without power supply, just GND, TXD, RXD.



Whole assembly again, servos not plugged in yet. FPGA board on top, plugged via two 2x20 pin headers
into board mounted on the upper body.



Top view:



Servos plugged in, serial cable in the foreground, serial board with maxim chip behind
and the small "Pömpel" is the bluetooth antenna.



A couple more images and highres versions: http://wuselfuzz.de/hexapod/images/botpix090713/



FPGA CODE

I had some issues with the new FPGA board, but it's looking brighter now.

At first, I ported the CPU + Bootloader ROM + UART over to the new board. Since the new board
has a 66 MHz OSC (which is halved in the FPGA design), I decided to let the CPU run at 33 MHz.

So the bootloader was working, but the RAM on the board is different to the Digilent board - the
S3 Starter Kit board had 1 MB of 10ns 32 bit RAM, the new board only has 70ns 8 bit RAM.

And that megabyte of RAM was where my code was running from.

For now, I used more of the FPGA internal RAM blocks to get a whopping 16kBytes of memory
- 8k bootloader "ROM" which is just preinitialized RAM and another 8k block at the same memory
location where I previously had 1 MB.

A few tests then have shown that servo control and the bootloader actually work.

The maximum amount of RAM I could get from the FPGA RAM blocks is 24kBytes. (12 blocks
with 2k each, I need 4 blocks to form 8k 32 bit RAM).

And the external RAM on the FPGA board is slow.

The demo code running in the youtube video is ~50kbytes large.

My current idea is to implement another CPU on the FPGA, a simple 8 bit CPU maybe running at 10 MHz.
This could communicate with the faster 32 bit CPU via a block of dual ported RAM or an SPI interface.

Then stripping down the 32 bit code to the bare minimum neccessary to do inverse kinematic calculations
and performing some linear interpolated EE movements. If that fits into maybe 16k, I can just use
the Plasma CPU as a realtime co processor and do higher level stuff on my slow 8 bit CPU.

SOFTWARE

Nothing new on movement algorithms here, as previously mentioned, I have to optimize stuff for size so
I can let it run.

What I'm currently trying to figure out is the HCI protocol to talk to the bluetooth module. The test code for this fits on FPGA internal RAM.

[Matt Denton]

Looking good!

That's allot of work your putting in there! I look forward to seeing the results.

I was looking at the Eddy Lemonix boards last night, did you ever get round to testing one? I'm looking for an embedded linux systems to transfer my full version of the HexEngine over to. I have it running on Debian on an x86 system, but would like a cut down version that boots fast!

[wuselfuzz]

I was looking at the Eddy Lemonix boards last night, did you ever get round to testing one? I'm looking for an embedded linux systems to transfer my full version of the HexEngine over to. I have it running on Debian on an x86 system, but would like a cut down version that boots fast!

Eddy is another chapter.

This just in:

The Spartan 3 Starter Kit Board has three expansion connectors, dual row 40 pin female.

Pins 1,3,5,7 of one expansion connector are GND, 3.3V, fpga i/o, fpga i/o.

For convenience, I flashed an FPGA design to the board that just connects the onboard level shifters to pins 5 and 7, so I
can plug in one of my modules (the level shifter module, the bluetooth module and the eddy module ) into that board and connect to the module via the FPGA board's RS232.

Today I fiddled around a bit with an eddy 2.1.

Since I don't have a carrier board, I used stiff wire that plugs into the 1.27mm grid connectors of the eddy. I took a piece of prototyping board, soldered a 4 pin header on end and attached the eddy module with the bottom connectors up on the other end. Then I used about 10mm long pieces of wire as pins, soldered more flexible wires to those that run to the pin header.

I also got the atmel data sheet for the CPU and found out which pins at the board connectors of the eddy are some kind of console.

I can draw 3.3v from either the Spartan 3 starter kit board or from the zefant board, both fpga boards have regulators anyways.

Result: If I cut short two other pins to enable booting from the on-chip rom, I get a SAM-BA monitor prompt.

More research for the debug port revealed, that it should be possible to get linux console output on the debug port. But for some reason, that didn't work with my module. I wonder if it's unprogrammed.

I tried registering an account on embeddedmodule.com, but for some reason, that didn't work. Upon approval, I'm allowed to d/l the kernel sources and bootloader sources, that will be interesting (that requires entry of a serial number from the module).

Evening lecture: http://www.atmel.com/dyn/resources/prod ... oc6221.pdf

Hot shit!