Bing 3

[DerekZahn]

Thanks, if I get stuck I might contact your brother. Your reasons are good ones, but we'll see!

I see that there are some SODIMM size cards just becoming available with the PXA320 chip at 800 MHz, which might just barely get a mips/cc advantage over the gumstix. When and if I want to add vision to Bing those might be a good option.

[DerekZahn]

I decided to play with this a bit and it turned out to be easier than I expected... I downloaded the WinXSCALE package for building xscale binaries on Windows. It turns out that u-boot has a nifty little thing called the "go" command which transfers control to an arbitrary memory address. So I wrote my little test app onto the flash, then the u-boot script loads that into memory and transfers control to it. It doesn't do much, just spit some things out the serial port to prove that it's working. On the bad side, I trashed the linux installation, but on the good side the board boots into my test app in 3 seconds, 2 of which are U-boot waiting for me to hit a key.

Linux would be great if I actually wanted to use the mmc card or some of the peripheral boards, but all I want is lots of mips in a small space along with two UARTs, so this environment will work out great for me.

Once I hack off the USB and power connectors from the breakout-gs board, the basix 400xm + breakout-gs will be 20x80x7.5mm which leaves me a little room to spare!

For those who have no clue what this is about, but are curious, check out www.gumstix.com for some fun little computers.

[JonHylands]

Derek,

How are you talking to the serial ports? Are you banging on the UART registers directly, or did you find a library somewhere that handles it?

- Jon

[DerekZahn]

I'm banging on it directly; the code looks very much like code for any other microcontroller. The serial ports are nice because they have 64-byte FIFO queues built in to RX and TX so you can neglect them for a while.

Here's the actual code I'm using if you're curious:

Code: Select all

#define __REG(x) (*((volatile unsigned long *) x))
#define FFLSR  __REG(0x40100014)
#define LSR_TEMT  (1<<6)
#define FFTHR  __REG(0x40100000)

void outchar(const char c)
{
   while((FFLSR & LSR_TEMT) == 0)
      ;
   FFTHR = c;
}


In this case, u-boot already set up the baud rate and whatnot, though setting those registers is no more difficult than for any mictocontroller.

Luckily u-boot doesn't set any timers or use any other interrupts (I don't think it even enables them) so it's completely out of the way.

[slashsplat]

I'm banging on it directly; the code looks very much like code for any other microcontroller. The serial ports are nice because they have 64-byte FIFO queues built in to RX and TX so you can neglect them for a while.

Are you considering software flow control (xon/xoff) from the host, or will you always be there to catch the buffers?

[DerekZahn]

I'll always be there to catch the buffers; the whole robot depends on a rather rigid timing cycle anyway so it shouldn't be an issue. Having a 64-byte RX FIFO means I can go 5 ms between looking at the port, so I can get by without using interrupts to move the characters to RAM. Getting the interrupts figured out is probably not TOO hard but it would require some study since the interrupt vector is around memory address 0 which is inside the u-boot flash.

[slashsplat]

...64-byte RX FIFO means I can go 5 ms between looking at the port

That is pretty short. At 9600, you would have 50+ms. What speed are you comm at? 110Kbaud (that would get 64 bytes in ~5ms)?

[DerekZahn]

Yes, 115k baud. I want a 10-20 ms control loop. Bing has 21 servos with feedback reporting and 28 other sensor channels, making a "packet" of about 100 bytes, so I need the high baud rate to get it all delivered in the necessary time frame.

[DerekZahn]

I have gone through the sensors and had a first pass at calibrating them into meaningful units, which is kind of exhausting. I will probably want to improve the accuracy at some point but it is looking pretty good to start with.

I also have corrected the drift in the tilt sensor. Here's a graph:



THe blue line represents the tilt angle as represented by the accelerometer only. THe green line is the gyro, and the red line is the computed tilt.

the first disturbance in the graph is me poking Bing in the chest (just like the last experiment). The tilt value looks right now instead of having drifted off. Notice that the lines for the tilt after the poke are not quite back to the level they were at before the poke. This is because small bits of compliance in the servos and maybe other parts caused bing to not quite come back to the same place it started from (by about one degree).

The second disturbance is me pushing bing backwards by about maybe 6 degrees and then holding it still before releasing it. The slope of the tilt graph is not as steep because it isn't moving as fast. This all looks pretty usable to me (for what exactly I'm not sure yet )

I'll keep playing with the sensors some more. In particular I want to see if I can get some estimates for momentum and location of center of mass. That's going to be kind of complicated.

[DerekZahn]

Oh, one more interesting graph:



This is a graph showing all 8 pressure sensors while Bing is standing in its standard pose. The variations in the lines are not noise in the sensor, they are caused by the slight tremor that the robot exhibits while standing still. The sensors are very sensitive and should prove useful.

The robot appears to be very sturdily and evenly balanced but you can see that some sensors have four times as much weight on them as others.

[DerekZahn]

As I looked over this thread I realized that some people thinking of building their own homebrew robo-one style robot might actually be discouraged by seeng what I'm doing, because it seems like a lot of complicated work. So I just wanted to note that most of what I'm doing is not at all necessary, and it's not even clear that it will help in any practical way (though of course I hope it will).

For example, a highly effective way to apply gyros is to use their output to alter the commands to various joints in a pretty straightforward way... if the robot is rocking backward, try to tilt the robot forward by increasing the ankle rotation, for example. Although nothing homebrew is ever as easy as it seems it should be, it's certainly NOT necessary to spend weeks calibrating things, writing reams of software, and making graphs.

I just do it this way because it amuses me and makes me learn new things. I don't care how long it takes as long as I have something that can more or less walk by RoboGames.

[eddymoore]

It's been a real pleasure following this thread, it really makes me want to have a go!

As someone who's had a few brief flings with IMUs in another project, I can proffer that, from my experience, using a Kalman filter to complement the gyro and accelerometer data really is worth it. They always say that everything in engineering has it's caveats, and is in some way a compromise, but this thing really does make all the difference in the world, to the point that other guys on my project team started calling it a voodoo filter. You don't really have to fully understand all the matrix calculus (I don't) but I understood it well enough to use it in software and so make a really solid IMU.

Looking forward to following your progress further!

[DerekZahn]

Thanks! By all means do have a go, it's fun!

I look at pages like this:

http://en.wikipedia.org/wiki/Kalman_filter

and become afraid

But you have encouraged me and at some point I will probably replace my current ad-hoc methods with a kalman filter. I'll save that for the day when tackling the math (or finding and adapting some code) seems like a fun project.

[slashsplat]

>>>As I looked over this thread I realized that some people thinking of building their own homebrew robo-one style robot might actually be discouraged by seeng what I'm doing...

Good point, Derek. For instance, KONDO has a two axis gyro (KRG-2) that connects INLINE with the foot and ankle servos (no programming) that will automatically tilt them forward, back, and side to side, based on the robot's movement. It will not provide the control that you can get, of course.

Your endeavors are ABSOLUTELY FASCINATING. It is rare to get an instructive, blow by blow of the development process, especially by someone so capable and on something so complex. Keep it up, you are an inspiration to us all.

[JonHylands]

Derek,

Very cool stuff.

If you're looking for a working implementation of a Kalman filter, check this out:

http://forum.sparkfun.com/viewtopic.php?t=4273&highlight=imu

It should work on your 2138's with no problems...

- Jon