SparkFun Forums

[germanviscuso]

Hi!

I have this product: http://www.sparkfun.com/products/9623 , my version came with the atmega 168. I was using the pre installed test firmware to get raw values which seemed to output dynamic values (except after doing a self test via the menu where it never passes and breaks the raw values afterwards).
Yesterday I decided to install this firmware: http://code.google.com/p/sf9domahrs/dow ... RS_1_1.zip
which as they say it also works with the 168 (code is small enough).
I used the Arduino IDE, went with the board "arduino pro or pro mini 3.3v 8 mhz, w/ ATmega 168" and uploaded the firmware with no errors. Checking the serial line I see that I get values like this:

Sparkfun 9DOF Razor AHRS
375
383
380
193
-18
-112
-0.04,0.28,0.15
-0.43,-0.42,0.26
-1.01,-0.77,0.40
-1.42,-0.58,0.56
-2.24,-0.28,0.47
-3.47,-0.29,0.53
-3.95,-0.73,-0.13
-4.34,-1.14,-0.91
-4.70,-1.62,-1.67
-4.65,-1.55,-2.47
-4.87,-1.77,-3.26
-4.46,-2.69,-3.72
-3.72,-2.66,-4.02
-4.56,-2.73,-4.82
-5.38,-3.44,-5.68
-5.47,-4.08,-6.41
-6.17,-4.39,-7.03

I downloaded everything to run the Python GUI and it seems to run fine (I can read the port and get the values as I can see in the output text of VIDLE) but the problem is that the 9DOF does not reflect the movements as expected, not even close, just moves slightly and does not respond correctly. When I move the device I can see that the output numbers in the VIDLE console change.
And, another problem, the parsing breaks after several lines, looks like the stream could be corrupt. See a complete run here: https://docs.google.com/leaf?id=0B-Nz74 ... NzI1&hl=en

I'm using Python 2.7 and a Sparkfun FTDI usb 3.3v board to talk to the 9dof

Can anybody give a clue on what's going on? Do I need to do any calibration? Do I have a defective board?

Best regards and thanks in advance.

German

[germanviscuso]

The values that I see in the output are not stable when I leave the 9dof in a still position. How is this possible??!!

[germanviscuso]

Solved it myself, posting here in case anybody sees the same problem.
The issue is not with the device itself (or the flashing of the code) but it has to do with these factors: initial stabilization, speed of output and baud rate.

First of all when you power the 9dof put in in a still position (eg on top of a table) to let it stabilize for a few secs.
Second, every time you output the values to a terminal (or to the console in the Python script) you're introducing a huge delay in data processing. In order to allow the Python script to work properly I had to disable all "print" commands to the console and disable writing the output to an external file.
Last, I had to change the baud rate in the 9dof code from 38400 (which was my choice because I had a bluetooth module set to this rate) to 57600 which is the one originally provided in the code.

Now the Python script works properly for me (code attached, rename from .txt to .py)

Best!

[skimask]

Guess it wasn't so strange after all...

[germanviscuso]

Well, I saw some videos of the 9DOF working properly with the full console output included. Maybe my machine is too slow...