Problems compiling FreeImu library

Development Boards Arduino
1

Hi guys.

I have downloaded this copy of the FreeIMU library

http://www.varesano.net/files/libraries … 5_2110.zip

And i’ve included all the libs that the compiler complains about. Now my sketch file looks like this

#include <ITG3200.h>

#include <MS561101BA.h>

#include <HMC58X3.h>

#include <bma180.h>

#include <Wire.h>

#include <CommunicationUtils.h>
#include <FreeIMU.h>

Get this compiler error

C:\Program Files (x86)\arduino-1.0\libraries\MS561101BA\MS561101BA.cpp: In member function ‘long unsigned int MS561101BA::getConversion(uint8_t)’:

C:\Program Files (x86)\arduino-1.0\libraries\MS561101BA\MS561101BA.cpp:144: error: call of overloaded ‘write(int)’ is ambiguous

C:\Program Files (x86)\arduino-1.0\libraries\Wire/Wire.h:55: note: candidates are: virtual size_t TwoWire::write(uint8_t)

C:\Program Files (x86)\arduino-1.0\hardware\arduino\cores\arduino/Print.h:49: note: size_t Print::write(const char*)

Looks like there are two write methods and it does not know which one to use… Whats wrong?

Thanks…

2

If i changed to

#define FREEIMU_VER 1 // For FreeIMU v0.1

It works, what version should I use for Sparkfun 9 DOF IMU?

http://www.sparkfun.com/products/10736

3

I’ve seen the ambiguous problem before. Generally it is caused by passing a constant to a function that does different things based on the argument’s type. wire.write(0), for example. It doesn’t know if it should send 1 or 2 bytes. So, the call should be written wire.write((byte)0) or wire.write((int) 0), depending if you meant to send 1 or 2 bytes. Frankly, it should just be a warning and default to byte (which is probably 90% of the usage) but that would be too friendly (or maybe too hard).

I saw this when I upgraded to 1.0 of the Arduino IDE. Also, in the 1.0 upgrade they changed some library function names (wire.send became wire.write, for example). Pretty annoying, frankly.

4

hey thanks for using my FreeIMU library. The solution to your problem is at http://www.varesano.net/blog/fabio/upda … provements …

Version 1 of the board should be fine for you… next version of the library will include support for Sparkfun boards, so stay tuned.

Good luck with your project.

5

I really don’t understand why the arduino folks made such significant changes for 1.0. It breaks many, many sketches out there. The wire library error at least tells you what you need to change but the ambiguous parameter thing is a head scratcher. For me, it’s not a problem because I have pretty deep knowledge of software and micros so I can track down just about any bug but for beginners, this has to be a big problem.

At least, they could have warned people. I got the message to upgrade so I did and, bam!, all sorts of stuff stopped working. Yeah, I know it’s free but that doesn’t absolve them.

6

Thanks for all your hard work fax!

I have some huge drift on the Yaw axis, is it because I compile for the 1.0 version of the board, are there differences in the number of sensors used between the versions?

If i lay down the board on a flat surface it drifts several degrees before settling down (It never stops completely to drift)

Thanks for the fix btw…

edit: I made a little video from my first attempt on using this :smiley: I have a low pass filter but for some reason I get lots of jitter, It could be software related on the PC side though…

http://www.youtube.com/watch?v=-IJkjwypLU8

edit2: Im going to use the Sparkfun IMU as a headtracker for the Sony Head mounted display

http://store.sony.com/webapp/wcs/stores … ew/theater

7

@Philba you may want to subscribe to the Arduino developers mailing list… all the changes to the APIs and core libraries are discussed there… maybe you can help.

@SparkfunSweden I would suggest to use the Processing sketches available in the FreeIMU library to check the correctness of your setup. Once that checks out you’ll have to sort out the problems in your 3d application. It looks to me that you have to much sensitivity, I mean in the video you only rotate the board about 15 deg and in the app you get a 90 deg rotation… I would have expected to see a 1:1 correspondence.

8

It was a softwareproblem on the PC side, I read the values from the com port and wrote the values to the shared memory that the game reads in the same thread, if i moved the reading from com to a seperate thread it worked!

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

I stil have todo some more testing on the drift issue…

9

fax8:
@SparkfunSweden I would suggest to use the Processing sketches available in the FreeIMU library to check the correctness of your setup. Once that checks out you’ll have to sort out the problems in your 3d application. It looks to me that you have to much sensitivity, I mean in the video you only rotate the board about 15 deg and in the app you get a 90 deg rotation… I would have expected to see a 1:1 correspondence.

Processing sketches ? Under File/Examples/FreeImu i found four examples

Quaternion

raw

speedtest

yaw_pitch_roll

But no Processing sketches?

I get strange readings on all 3 axis when running the yaw_pitch_roll example… thanks for all your help!

10

http://www.varesano.net/projects/hardwa … MU#library and scroll down a bit.

Check that the serial monitor is set to the same Serial port speed as the one used in the yaw_pitch_roll program.

11

Thanks for fast response! :smiley:

I’ve loaded the example to the arduino,The one that sends on this format

Yaw: -130.96 Pitch: 10.17 Roll: -36.87

I use FreeIMU v0.1version of the lib by the way (The other versions make it behave really strange btw)

I then change to

myPort = new Serial(this, “COM3”, 115200);

Which is my comport and speed

But nothing happens, get 3 empty sensor readings on screen… thanks again

12

Both the FreeIMU_cube and FreeIMU_yaw_pitcch_roll Processing sketches needs the FreeIMU_quaternion Arduino program loaded on the board.

13

sorry you menetioned the yaw_pitch_roll program in the post above so i loaded that one… sorry… will get right back…

14

Please check my little youtube clip, I move the device two times during the video, you can easily identify them, please watch the huge amount of drift each time i move it.

This is done compiling FreeImu using the FreeIMU v0.1 constant in the FreeImu.h

http://www.youtube.com/watch?v=RVIK2gm9jQ4&hd=1

15

  1. you still may have some problem on your sensors axis in the software. The FreeIMU library expect them to be all aligned for all the sensors as in my FreeIMU boards. Check with the sensors’ datasheets and phisical placement in the board the correct alignment. Future versions of the FreeIMU library will support Sparkfun’s boards (yes, I’m shooting in my foots, but you know…).

  2. your magnetometer may need to be calibrated. See http://www.varesano.net/blog/fabio/firs … ts-results to how verify.

  3. you may have a magnetical interference, eg laptop speakers, which corrupts your magnetometer readings.

  4. the firsts seconds after arduino reset or openin connection to serial port are used to calibrate sensors. the board needs to be as still as possible.

16

New version of the FreeIMU library adds support for Sparkfun boards http://www.varesano.net/blog/fabio/new- … fun-boards

17

fax8:
http://www.varesano.net/projects/hardwa … MU#library and scroll down a bit.

Check that the serial monitor is set to the same Serial port speed as the one used in the yaw_pitch_roll program.

HAH that totally fixed my problem. I just wanted to say thanks.