SparkFun Forums 

Where electronics enthusiasts find answers.

For the discussion of Arduino related topics.
By SparkfunSweden
#138073
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
Code: Select all
#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..
By Philba
#138084
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.
By Philba
#138099
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.
#138103
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 :D 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
By fax8
#138106
@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.
#138171
fax8 wrote: @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!
#138177
Thanks for fast response! :D

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
By fax8
#138184
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.