Independent review of Jon Hylands' IMU

[StuartL]

Upon receipt of Jon's IMU board I purchased the Sparkfun 5-degrees of freedom IMU. I bought it in the US since I'm here for business. I didn't bother with the third degree of gyroscopic freedom just because it wasn't really relevant to what I'm doing.

The IMU (found here) is available either as the bare board (my choice) or the complete unit.

As supplied the bare board came with the fittings, hardware and mount to slip nicely into the chest cavity of the standard humanoid. It still leaves enough space to bundle up the 6-way adapter and the wires comfortably. After soldering the 5-deg IMU onto Jon's bare IMU host board it slotted in first time.

A little care is required to ensure that the nuts, washers and spacers are installed correctly as they have notches to avoid impeding on components on the board, but this is obvious when you assemble it. If it doesn't fit easily you've made a mistake

Integrating the IMU into my software was trivial. Jon's host software emulates an approximation of the AX12/AXS1 behaviour, allowing the read/write/ping software to work with little modification. Because of the library previously written (which I promise will come out soon!) putting the IMU code in was very very easy, requiring the addition of a function prototype, a C struct and a four-line function.

To my surprise everything worked first time. The accelerometers and gyros are sensitive enough that you get approx 1-2 bits of noise when your robot is stationary and a good degree of response when it's moved. The sensors are stable enough to accurately determine gravity orientation.

1G is approximately '64' on my accelerometers, with about 10% tolerance across the 3 axis. Some simple calibrations in a header file flatten the profiles and a 8-cycle (running at 40Hz, so about fifth of a second) smoothing loop makes everything nicely stable. The third gyroscope axis (rotation about the z-axis) unsurprisingly generates a LOT of noise as it's completely unconnected, but zeroing that in software costs only one cycle, approx 160 nano-seconds, an affordable cost

In short, while relatively expensive compared to home-brewing an IMU, the unit works perfectly out of the box, fits nicely into the chest and most valuably doesn't involve you arguing about PCB manufacture prices with your choice of manufacturer or debugging boot loaders or bus software for weeks on end. I'm now wondering about a second one for the quadruped...

[limor]

1G is approximately '64' on my accelerometers, with about 10% tolerance across the 3 axis. Some simple calibrations in a header file flatten the profiles and a 8-cycle (running at 40Hz, so about fifth of a second) smoothing loop makes everything nicely stable. The third gyroscope axis (rotation about the z-axis) unsurprisingly generates a LOT of noise as it's completely unconnected, but zeroing that in software costs only one cycle, approx 160 nano-seconds, an affordable cost

I didn't quite get this part.. please explain

[StuartL]

1G is approximately '64' on my accelerometers, with about 10% tolerance across the 3 axis. Some simple calibrations in a header file flatten the profiles and a 8-cycle (running at 40Hz, so about fifth of a second) smoothing loop makes everything nicely stable. The third gyroscope axis (rotation about the z-axis) unsurprisingly generates a LOT of noise as it's completely unconnected, but zeroing that in software costs only one cycle, approx 160 nano-seconds, an affordable cost

I didn't quite get this part.. please explain

Oops, to clarify...

In free-fall the accelerometers are "approximately" zero, in my case one was '4', one was '22' and one was '24'. I put these values into my calibration function to re-zero the accelerometers and then 1G of acceleration worked out to be approximately '64' deflection in each axis with about a 10% tolerance.

My core software runs at 40Hz, i.e. each read/process/write loop of the software takes 1/40th of a second. To smooth the output of the accelerometers and gyros I remember the last 8 values and average them (with minor optimisation to minimise the maths overhead). This means the reaction time is approx 1/5th of a second (8 cycles of 40Hz) which is plenty fast enough.

The third gyroscope axis is unconnected, meaning that there's a HUGE amount of noise on the analogue to digital converter and if I based any maths on this input the robot would get very confused. Therefore all my maths for this third gyroscopic sensor ignores its value because the library code that reads the value from Jon's firmware overrides the return value with zero (incidentally at the same time as the other values are calibrated).

Does that help at all?

[Droid Works]

Can you please share the code. I program in VB and have only a basic understanding of C. I have had the IMU for the bioloid for a day and 1/2 and cant get it to work.

[srobot]

Can you please share the code. I program in VB and have only a basic understanding of C. I have had the IMU for the bioloid for a day and 1/2 and cant get it to work.

Droid - You can program your Bioloid to use the IMU in BCP. While this won't let you have the most control, it is a good start.

I think I have some code around here some place... I'll look for it...

--Scotty

[Droid Works]

BCP?

[srobot]

BCP?

Behavior Control Program, it's part of the software that is on the CD-ROM that should have come with your Bioloid.

Have you programmed your Bioloid yet? If not, look at some code and write your own programs before starting on programming the IMU into your code.

Cheers,
--Scotty

[Will]

:

[Droid Works]

BCP?

Behavior Control Program, it's part of the software that is on the CD-ROM that should have come with your Bioloid.

Have you programmed your Bioloid yet? If not, look at some code and write your own programs before starting on programming the IMU into your code.

Cheers,
--Scotty

Yes he is programed. I have had him for over a month. I just wasn't familiar with the acronym.