icewwn / ardu-imu Goto Github PK

What steps will reproduce the problem?
1. Connect 3.3v ftdi to either win 7 or os x, with up to date ftdi drivers
2. Compile and upload 1.9.8 code under Arduino duemilanove 382
3. Code will compile but never upload with no errors after letting run for 20+ 
minutes

What is the expected output? What do you see instead?
Expected to upload and run code, but only RX light comes on, when I would be 
expecting to TX the new code to the IMU

What version of the product are you using? On what operating system?
V3, tried on OS X and Win 7 with RTS close option checked.

Please provide any additional information below.
If any further questions please do not hesitate to contact me.

What steps will reproduce the problem?
1. Compare 1.9.8 release to repository (I couldn't find any revision that had 
this magic number in it).

What is the expected output? What do you see instead?
1.9.8 contains:
void Euler_angles(void)
{
  #if (OUTPUTMODE==2)         // Only accelerometer info (debugging purposes)
    roll = 1.9*atan2(Accel_Vector[1],Accel_Vector[2]);    // atan2(acc_y,acc_z)
    pitch = -1.9*asin((Accel_Vector[0])/(double)GRAVITY); // asin(acc_x)
    yaw = 0;
  #else
    pitch = -1.9*asin(DCM_Matrix[2][0]);
    roll = 1.9*atan2(DCM_Matrix[2][1],DCM_Matrix[2][2]);
    yaw = atan2(DCM_Matrix[1][0],DCM_Matrix[0][0]);
  #endif
}

This constant of 1.9 does not appear in the repository and it is undocumented 
in this release.  There is a comment on the downloads page talking about 
calibration for pitch and roll, but it is unclear if it refers to this.  It's 
also not clear why the calibration is performed after extracting the angles and 
not on the sensor measurements themselves.

What version of the product are you using? On what operating system?
1.9.8 from the downloads section.

Please provide any additional information below.

What steps will reproduce the problem?
IMu works fine on the table. But then i put it in my car. AHI is just the 
centrifugal vector. Drifts a lot. 
I've measured the output of MPU-6000 and the values are different form v2 
version hardware sensors..
Maybe there someone could do tune up for firmware to adopt v3 hardware to do 
better stability of IMU?
THanks.

Virgis

Hi
I've added some enhancement

1. to start "ground mode" you simply press one button while starting the
device and release after the leds blinking. No more actions are necessary.

2. Compensating the Hard-Iron effects, when start in "ground mode" you must
make one complete turn ( turned off red led when ok). The value are stored
in the eeprom for the "air mode" use.

3. Added declination compensation calculated when the first time of the gps
speed are over 10m/s. Stored in the eeprom for future restart.

4. The YAW value are linked only to Magneto value and never to GPS.

What steps will reproduce the problem?
1. Turn on IMU with GPS attached
2. Wait for GPS lock light (solid blue)
3. Disconnect GPS. Lock light remains lit

What steps will reproduce the problem?
1. Activate the itow for class NAV-VELNED
2. Compare the two itows for class NAV-POSLLH and for class NAV-VELNED, they 
are different
3. When I print the ground speed/course, sometimes they update while sometimes 
they just stop updates, very inconsistent

What is the expected output? What do you see instead?
The ground speed/course should updates at the same time as the GPS longitude, 
latitude, altitude,etc. What I observe is they can not do that

What version of the product are you using? On what operating system?
1.7.1 and 1.8.1 versions, windows vista, Arduino 0021.

Please provide any additional information below.
when I disable the SOL message on Ublox, the ground course and speed update 
together with the latitude, longitude, etc.

if you want to reduce the "GPS Checksum Bad" you can change one row inside
the file HardwareSerial.cpp

from

#define RX_BUFFER_SIZE 128

to

#define RX_BUFFER_SIZE 256

What steps will reproduce the problem?
1. Just buy the ArduIMU V3.
2. Follow the instructions to load the wow "software"
3. Dump your money in the garbage.

What is the expected output? What do you see instead?
What I expect? Buy a product that really works, If don't, have some support 
from the manufacturer. As far I can see on all forums and Wiki's nobody have a 
ArduIMU working as advertised in your website as "Functional" IMU.

What version of the product are you using? On what operating system?
Tested all of them in the repository.

Please provide any additional information below.
My sadness?

What steps will reproduce the problem?
1. building under linux openSUSE 11.4
2.
3.

What is the expected output? What do you see instead?
the libraries don't build

What version of the product are you using? On what operating system?
v1.8.2

Please provide any additional information below.

BMP085 and HMC5843 can be used simultaneously on arduimu? how?

What steps will reproduce the problem?
1. Set #define GPS_PROTOCOL 2
2. Load the code to the ArduIMU
3. Open the serial monitor and set the baud rate to 38400


If you set the baud rate at 38400, you get garbled data, change it to 57600 and 
it is all clear. This should be clarified because in the ArduPilot 2.7.1 code, 
it is set to receive the data at 38400.

This problem is most likely caused by AP_GPS library. AP_GPS_406.h is set to 
#define GPS_406_BITRATE to 57600. I am assuming that the bitrate is set that 
way because of the EM406 device, therefore, it should be noted elsewhere in the 
code that the bitrate will change with this device.

What steps will reproduce the problem?
1. #define PERFORMANCE_REPORTING 0
2. Build

What is the expected output? What do you see instead?
Compilation fails:
In function 'void printPerfData(long int)':
error: 'mainLoop_count' was not declared in this scope

What version of the product are you using? On what operating system?
v1.7 from zip file download.  Win7.

Please provide any additional information below.

Comment suggests that PERFORMANCE_REPORTING is for uBlox only, and I'm using 
MTK GPS, so it seemed sensible to disable it.  Is comment incorrect?

What steps will reproduce the problem?
1. yaw values are wrong
2.
3.

What is the expected output? What do you see instead?
yaw values give aleatory or sometimes imu sends moves yaw values

What version of the product are you using? On what operating system?
arduimu v3

Please provide any additional information below.
sometimes imu don't send the correct values yaw is moved from the correct 
value, 

What steps will reproduce the problem?
1. download 1.9.8
2. compile it
3.

What is the expected output? What do you see instead?

compile error I had to rename Wire.write to Wire.send

and

Wire.read to Wire.receive in HMC5883

I also had to comment out AP_Common.h in various GPS files. Then it finally 
compilled. is 1.9.8 not ready and should I use not so bleeding edge version.

What version of the product are you using? On what operating system?
windows XP 023 version of arduino.

Please provide any additional information below.

I followed the guide which any beginner without coding skills would have failed.

What steps will reproduce the problem?

Serial.print(Accel_Scale(Accel_Vector[2]));

What is the expected output? What do you see instead?
Using the conversion from ADC-values to accelerations by the defined scaling:

#define Accel_Scale(x) x*(GRAVITY/9.81)//Scaling the raw data of the accel to 
actual acceleration in meters for seconds square

produces unexpected values. 

-> expected is an acceleration in m/s2 in z-direction of about 9.81

To be correct, the conversion should be defined as:

#define Accel_Scale(x) x*(9.81/GRAVITY)//Scaling the raw data of the accel to 
actual acceleration in meters for seconds square

to produce the expected output!

What version of the product are you using? On what operating system?
I'm using 1.5, but its still in 1.8 

What steps will reproduce the problem?
1. uploading V1.8 to ArduIMU+ by Arduino 0019
2.
3.

What is the expected output? What do you see instead?
failed to compile: "expected constructor, destructor, or type conversion before 
'(' token" 

What version of the product are you using? On what operating system?
ArduPilot 2_7_1, ArduIMU+, MTK GPS, FTDI cable


Please provide any additional information below.
It seems FastSerial.h, AP_GPS.h and AP_Compass are not included in the zip.  

Initial steps:

1. ArduIMU + MediaTek GPS connected to PC using the FTDI cable
2. Loaded the ArduIMU software version 1.9.8 using Arduino IDE 1.0.1
3. Tested the output using the test software

Results:

The ArduIMU is stationary over the desk and the test software shows a cube 
which keeps on rolling. I had to modify the ArduIMU code in order to get the 
GPS data correctly ( AP_GPS_MTK16 GPS(&Serial); ) and I have corrected the 
magnetic variation using the value provided by the web site in the code comment.

This is my configuration:

#define GPS_CONNECTION 0 // 0 for GPS pins, 1 for programming pins

// GPS Type Selection - Note Ublox or MediaTek is recommended.  Support for 
NMEA is limited.
#define GPS_PROTOCOL 4    // 1 - NMEA,  2 - EM406,  3 - Ublox, 4 -- MediaTek  

// Enable Air Start uses Remove Before Fly flag - connection to pin 6 on 
ArduPilot 
#define ENABLE_AIR_START 0  //  1 if using airstart/groundstart signaling, 0 if 
not
#define GROUNDSTART_PIN 8    //  Pin number used for ground start signal 
(recommend 10 on v1 and 8 on v2 hardware)

/*Min Speed Filter for Yaw drift Correction*/
#define SPEEDFILT 2 // >1 use min speed filter for yaw drift cancellation 
(m/s), 0=do not use speed filter

/*For debugging propurses*/
#define PRINT_DEBUG 0   //Will print Debug messages

//OUTPUTMODE=1 will print the corrected data, 0 will print uncorrected data of 
the gyros (with drift), 2 will print accelerometer only data
#define OUTPUTMODE 1

#define PRINT_DCM 1     //Will print the whole direction cosine matrix
#define PRINT_ANALOGS 0 //Will print the analog raw data
#define PRINT_EULER 1   //Will print the Euler angles Roll, Pitch and Yaw
#define PRINT_GPS 1     //Will print GPS data
#define PRINT_MAGNETOMETER 1     //Will print Magnetometer data (if 
magnetometer is enabled)

// *** NOTE!   To use ArduIMU with ArduPilot you must select binary output 
messages (change to 1 here)
#define PRINT_BINARY 0  //Will print binary message and suppress ASCII messages 
(above)

// *** NOTE!   Performance reporting is only supported for Ublox.  Set to 0 for 
others
#define PERFORMANCE_REPORTING 0  //Will include performance reports in the 
binary output ~ 1/2 min

/* Support for optional magnetometer (1 enabled, 0 dissabled) */
#define USE_MAGNETOMETER 1 // use 1 if you want to make yaw gyro drift 
corrections using the optional magnetometer   

// Local magnetic declination (in degrees)
// I use this web : http://www.ngdc.noaa.gov/geomagmodels/Declination.jsp
#define MAGNETIC_DECLINATION 2.382    // corrects magnetic bearing to true north
// Magnetometer OFFSETS (magnetometer calibration) (only for ArduIMU v3)
#define MAG_OFFSET_X 0
#define MAG_OFFSET_Y 0
#define MAG_OFFSET_Z 0

/* Support for optional barometer (1 enabled, 0 dissabled) */
#define USE_BAROMETER 0     // use 1 if you want to get altitude using the 
optional absolute pressure sensor                  
#define ALT_MIX 50


Did they tested this software??!?!?

Thank you,
Alessandro Munari

What steps will reproduce the problem?
1. Initialize IMU level
2. Slowly turn 90 in roll
3. Return to horizontal orientation.
4. Slowly turn -90 in roll
5. Return to horizontal orientation.
6. Repeat for pitch and yaw (yaw rotate 360 in 90 deg increments)

What is the expected output? What do you see instead?

Each axis output should correspond to the number of degrees turned
Roll reading: actual roll: - 90 deg -> RLL output: - 120
                          +  90 deg -> RLL output: + 120
Pitch reading: actual pitch: -90 deg -> PCH output: -50
                             +90 deg -> PCH output: +50
Yaw reading: actual yaw:  0 deg -> YAW output: 180
                          90 deg -> YAW output: 108
                          180 deg -> YAW output: 45
                          270 deg -> YAW output: -40
                          360 deg -> YAW output: -180

What version of the product are you using? On what operating system?
ArduIMU V3
firmware version 1.9

Please provide any additional information below.

I am using arduimu for gesture recognition, I am a little confuse how to read 
meaning of the output (9 values)?I mean how is the interpretation of value 1-9.

I am trying to understand how can I obtain the same measurements for x,y,x in 
earth coordinates and not sensor coordinates, for example a simple up-down 
movement with the sensor place in a flat position and the same up-down movement 
with the sensor rotated 90 degrees. 

How can I make a relation between acceleration and gyro information to consider 
in either of the mentioned cases (flat or rotated) the same acceleration values 
in z (up-down)? for this I am trying to use DCM.

Any comment will be very useful, thanks   

The SIRF GPS (EM406A) still seems not to work with the arduimu with the current 
avn code.

ArduIMU_1.9.8 target device code

Having experimented with an ArduIMU running 1.9.8 code, we found that, unless 
we do a ground start with the sensor perfectly flat in the XY-plane, large 
offsets are applied during subsequent operation.  Looking at the code, it's 
clear that ground start does a simple offset process, assuming a perfectly flat 
sensor.  I have not found any mention of this ground start requirement in the 
Wiki.

During this ground start, an 'average' procedure is performed on 400 samples, 
using the code snippet in Arduimo.ino:

for (int i=0;i<400;i++) // We take 400 readings...
{
    Read_adc_raw();     // returns AN[]
    for (int y=0; y<=5; y++) // Read initial ADC values for offset
        AN_OFFSET[y] = AN_OFFSET[y]*0.8 + AN[y]*0.2;
...

I'm not sure quite what was intended by this, but it will not perform a simple, 
linear average (which would be my choice for a simple startup offset 
compensation calbration).  The gain of this process tends to unity for large n, 
but never reaches it (for n=4, the gain is 0.8976).  Since each sample is 
effectively scaled by 0.8 each time a new sample is taken, each i'th sample 
ends up with a gain of 0.2*0.8^(n-i-1), where n is the sample limit, i.e. 
there's an exponential bias towards to most recent samples.  Apart from sample 
zero, which has a gain of 0.8^n

Whilst an interrupt is set up to allow the MPU-6000 to interrupt the Atmel 
processor when a data sample is ready, and this interrupt triggers the function 
void MPU6000_data_int() in MPU6000.pde, the main processing loop does not use 
it, instead using a 20 millisecond loop timer.  Thus, the sample generation and 
consumption are asynchronous (or plesiochronous), and there will be times when 
a sample read hits the point at which the new sample is being updated by the 
sensor (a sync slip), giving incoherent samples, and maybe even incoherent 
upper/lower bytes values.

The accelerometer scaling configuration is confusing.  The code in MPU6000.pde 
is as follows:

MPU6000_SPI_write(MPUREG_ACCEL_CONFIG,0x08); // Accel scale 4g (4096LSB/g)

The constant 0x08 corresponds to an FSD of +/-4g according to the sensor 
datasheet, but this also means a scaling of 8192LSB/g.  Experiment shows the 
sensor returning values around 4096 when static, suggesting that there is an 
inconsistency somewhere in the code, or in the data sheet.

Since we do not know the design intent or design requirements for this code, 
it's hard for us to say what is right or wrong; maybe someone more familiar 
with the ArduIMU design and implementation could comment on these issues.  
Thanks.

What steps will reproduce the problem?
1. Copy arduimu and libraries from ArduIMU 1.9
2. arduimu compiles in arduino 0.2.3
3. Copy libraries from ArduIMU 1.9.6
4. arduimu compiles in arduino 1.0.1
5. Copy libraries from ArduIMU 1.9.8
6. Many errors

What is the expected output? What do you see instead?
Project does not compile. Many errors

What version of the product are you using? On what operating system?
ArduIMU 1.9.8
Windows 7

Please provide any additional information below.

What steps will reproduce the problem?
1. Download and install latest version of Arduino IDE
2. Download latest ArduIMU software
3. Attempt to load ArduIMU software to ArduIMU board

What is the expected output? What do you see instead?
Code does not compile.  Compiler error message "Wire.send() has been renamed 
Wire.write()"

What version of the product are you using? On what operating system?
Windows 7

Please provide any additional information below.

Hi all 

I just got my arduimu v3 and its pretty easy to use thus far but I want to 
incorporate a BMP085 pressure sensor and when I put use barometer to 1 I get 
errors.

Output:87: error: 'temp_unfilt' was not declared in this scope
Output:88: error: 'alti' was not declared in this scope
Output:90: error: 'press' was not declared in this scope
Output:93: error: 'press_alt' was not declared in this scope

Have these declarations been forgoten in the updated code? where would I put 
the declarations?

Thanks

I used ArduIMU V3 and the unchanged current software release 1.9. When I look 
at the YAW values​​, then I realize that North and South will be highly 
asynchronous. YAW at hardware compass "north" is approximately 11 and hardware 
compass "south" is approximately 156. Between north and south there are 145° 
in clockwise and counter clockwise, there are 215°.
What is the problem and how can I fix it?

ArduIMU build on Linux x64 with Arduino 1.0.3 fails with the following errors: 
http://pastebin.com/yhzRQTe7

As you can see, some of the IO ports were not declared.

The root cause is wrong Core Includes directory: it must be 
"$(HARDWARE_DIR)/variants/standard" instead of "$(HARDWARE_DIR)/variants/mega". 
The offending line is located at "libraries/AP_Common/Arduino.mk", line 378.

It should be replaced with:
COREINCLUDES = -I$(CORESRC_DIR) -I$(HARDWARE_DIR)/variants/standard

However, to keep this script compatible with ArduPilot, I'd suggest to add 
optional variable:
ARDUINO_VARIANT ?= mega
COREINCLUDES = -I$(CORESRC_DIR) -I$(HARDWARE_DIR)/variants/$(ARDUINO_VARIANT)

And override it in config.mk:
ARDUINO_VARIANT=standard

Hope this helps.

What steps will reproduce the problem?
1. Try to connect any ESC or servo
2. If you had more than 4?
3. Only can connect 2?

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
ArduImu Flat v2

Please provide any additional information below.
I need some pin number, to work with the code, but I can't find anywhere...

What steps will reproduce the problem?
1. The firmware doesn't use the INT0 and INT1 pins
2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
V3 on Linux

Please provide any additional information below.
The firmware doesn't seem to be using the INT0 and INT1 attached to MPU6000 and 
HMC5883L, respectively. If external interrupts are abslutely necessary for the 
project can those pins be used after disconnecting them from MPU6000 and 
HMC5883L?

How much is the standard deviation related to the measurement noise on the 
accelerometers measurements?

What steps will reproduce the problem?
1. Setting USE_MAGNETOMETER == 1 

What version of the product are you using? On what operating system?
IMU v2+; Windows 7

Please provide any additional information below.


#if USE_MAGNETOMETER == 1
    APM_Compass.Init(); // I2C initialization
    debug_handler(3);
#endif

arduimu.cpp: In function 'void setup()':
arduimu:286: error: 'APM_Compass' was not declared in this scope
arduimu.cpp: In function 'void loop()':
arduimu:385: error: 'APM_Compass' was not declared in this scope
arduimu.cpp: In function 'void Drift_correction()':
DCM:170: error: 'AP_Compass' was not declared in this scope

also, how does one define which orientation matrix to use? is it here?

virtual void set_orientation(const Matrix3f &rotation_matrix);

I have been reading this code, as well as Bill's DCM paper, and I am wondering 
if there is an available implementation (of any kind) of dead-reckoning using 
the concepts from the DCM algorithm.

I noticed this file in what appear to be some of Bill's earlier implementations 
(from MatrixPilot): 
http://api.ning.com/files/OOZjvN9I7PtfdKmftHVruToOhl7IQQ4cfv*Pw8HbllP922hp7HimOb
7yIe*0hV0uVlqgmHKUHsDmwihbYvDFFg__/deadReckoning.c

It seems to provide dead-reckoning, but only when hooked up to GPS data.  It 
seems to me that the DCM concepts could be applied with a magnetometer to get 
precise relative coordinates in indoor situations.  Dead-reckoning could also 
be used to report precise positioning information in situations where GPS 
looses it's lock (ie a car's moment-by-moment turns going through a tunnel).

Are there any known implementations of this?  In general, are there any good 
open-source dead-reckoning algorithms I am missing?  It seems like DCM is very 
close to nailing down the position of an item (relative or absolute) instead of 
just nailing down its orientation.

Any comments on the topic of dead-reckoning would be greatly appreciated.

if you set #define PRINT_BINARY to 0, the source does not compile.

svn revision 990

What steps will reproduce the problem?

Compiling with use_magntometer =1 

What is the expected output? What do you see instead?

arduimu.cpp: In function 'void loop()':
arduimu:376: error: expected unqualified-id before '.' token
arduimu:377: error: expected unqualified-id before '.' token
arduimu.cpp: In function 'void Drift_correction()':
DCM:170: error: expected primary-expression before '.' token
DCM:170: error: expected primary-expression before '.' token


What version of the product are you using? On what operating system?

Arduimu 1.8


Please provide any additional information below.

What steps will reproduce the problem?
1. Put on Binary output
2. See serial output


What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
I´m using 1.9.8


Please provide any additional information below.
Hi, have tried to Convert the binary Data to my structs. Then I see that there 
are no binary Data.. There was binary Data converted To ascii. In the Source 
Code of Arduimu is Serial.print() instead of Serial.write() in use, which 
converts the binary Data to Human Readable ascii. I have fixed this in the 
attached File.

What steps will reproduce the problem?
1. Copy the arduimu and libraries to Arduino Sketchbook in My Documents
2. Press compile or verify 
3. Get the error

What is the expected output? What do you see instead?
Compile, just compile

What version of the product are you using? On what operating system?
1.8.1

Please provide any additional information below.
That's the error output:
In file included from arduimu.cpp:14:
C:\Users\Debci\Documents\Arduino\libraries\FastSerial/FastSerial.h:105: error: 
conflicting return type specified for 'virtual void FastSerial::write(uint8_t)'
C:\Users\Debci\Desktop\arduino-1.0.1\hardware\arduino\cores\arduino/Print.h:48: 
error:   overriding 'virtual size_t Print::write(uint8_t)'

What steps will reproduce the problem?
1. Loading current code after re-configuring ardupilot to work at 57600 baud. 
GPS working in binary ok.
2.
3.

What is the expected output? What do you see instead?
GPS log and lat is detected ok (as shown in IMU test program) but no fix 
detected (blue LED never stops flashing).

What version of the product are you using? On what operating system?
I am using an old Arduimu v1 with v1.8.2 firmware

This is a school project and we do not have the budget to change the GPS. We 
have also manufactured all the mounts to fit the EM406.
Can anyone point to the code used to detect the fix status?
We have a demo to give on Monday morning.

Many thanks

My last version of arduimu (with auto-declination disabled)