Replies to This Discussion

Permalink Reply by AndyK on January 27, 2012 at 4:17pm

Hey,

Maybe this is a stupid question, but the code references mpu6000.h which I don't see in the repository. Should we just pull that from the ArduPilot code?

- Andy

• ▶ Reply

Permalink Reply by AndyK on January 27, 2012 at 4:22pm

Nevermind. I see it's in the .zip. I just don't see it in the file list in the trunk.

- Andy

• ▶ Reply

Permalink Reply by dzlonline on January 23, 2012 at 9:49am

Ok i have now looked into it a little bit.

I have changed the code (example code ftom the APM2 reposetory) to comply with HappyKillmores ArduIMU2 test program (http://diydrones.com/profiles/blogs/arduimu-v2-test-application) by adding the lines below. This basically encodes the euler angles to binary for the test program.

First thing i noticed was that pitch and roll was switched and these had to be switched.

I don't know exactly how the test program works but the two 3D models: Yellow plane and cube behaves differently.

With the ArduIMU2 demo you had to choose the Yellow plane to get a correct display of the board orientation but with this example you need to use the cube.

Does anyone know how this program interpret the angles to get the correct display?

Euler to binary:

float roll=MPU6000.MPU_pitch;
float pitch=MPU6000.MPU_roll;
float yaw=MPU6000.MPU_yaw;

byte IMU_buffer[22];
int tempint;
int ck;
long templong;
byte IMU_ck_a=0;
byte IMU_ck_b=0;

Serial.print("DIYd"); // This is the message preamble
IMU_buffer[0]=0x06;
ck=6;
IMU_buffer[1] = 0x02;

tempint=ToDeg(roll)*100; //Roll (degrees) * 100 in 2 bytes
IMU_buffer[2]=tempint&0xff;
IMU_buffer[3]=(tempint>>8)&0xff;

tempint=ToDeg(pitch)*100; //Pitch (degrees) * 100 in 2 bytes
IMU_buffer[4]=tempint&0xff;
IMU_buffer[5]=(tempint>>8)&0xff;

templong=ToDeg(yaw)*100; //Yaw (degrees) * 100 in 2 bytes
if(templong>18000) templong -=36000;
if(templong<-18000) templong +=36000;
tempint = templong;
IMU_buffer[6]=tempint&0xff;
IMU_buffer[7]=(tempint>>8)&0xff;

for (int i=0;i<ck+2;i++) Serial.print (IMU_buffer[i]);

for (int i=0;i<ck+2;i++)
{
IMU_ck_a+=IMU_buffer[i]; //Calculates checksums
IMU_ck_b+=IMU_ck_a;
}
Serial.print(IMU_ck_a);
Serial.print(IMU_ck_b);

• ▶ Reply

DeveloperPermalink Reply by Jose Julio on January 23, 2012 at 3:56pm

The problem is that this code (DMP code taken from repository) was designed for APM2 and in adition to the hardware differences (CS and INT pins) both sensors MPU6000 and HMC5883 are mounted in diferent positions so the output from this library is not valid for ArduIMU v3. We have this library updated to work with ArduIMU v3 but as Chris said, until we get a proper licence from Invensense we are not going to release it (sorry for that, I hope it will be soon...)

Meanwhile you can test the code from ardu-imu repository . This test is based on old ArduIMU v2 code with DCM algorithm updated to use the new sensores (MPU6000 and HMC5883).

Jose.

• ▶ Reply

Permalink Reply by AndyK on February 13, 2012 at 4:01pm

Any updates on the licensing issues?

• ▶ Reply

Permalink Reply by Skyler Greenman on February 13, 2012 at 10:28pm

Yes, what is the status on obtaining the license from Invensense? I purchased one of these with the hope that I could use the fusion code to create a 2D mouse pointer for a glove. Could that be still possible without obtaining the "fusion code" from Invensense? What sensors does the current code support?

Thank you for your help.

• ▶ Reply

Permalink Reply by JesseJay on February 14, 2012 at 12:56am

All sensors work now  Just your arduino must do more of the processing right now, rather then using the DMP sensor fusion.

• ▶ Reply

Permalink Reply by AndyK on February 14, 2012 at 5:37am

Yes, well I bought this based on the advertising material on the DIYDrones store site. Specifically the below statement...

"Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronization and gesture detection with supported software (not yet currently supported in DIY Drones code)"

...although when I bought the board, the site did not have the comment about not being supported in the code. I don't mean to sound ungrateful, it's a great little board, but I do find it a little disappointing not to be able to use a feature that was advertised to me. Do you have any updates on the licensing?

• ▶ Reply

Permalink Reply by Skyler Greenman on February 24, 2012 at 10:36am

Meaning we have to come up with our own algorithms to correct the drift and reset the sensors?

• ▶ Reply

Permalink Reply by Erik Norgren on March 11, 2012 at 6:56pm

Do you know what update rate I can expect with the arduino doing the processing?  I believe Invensense claims 200hz update rate using their sensor fusion algorithm and processor.  

• ▶ Reply

Permalink Reply by Frank Zhao on March 11, 2012 at 6:58pm

I pushed some code to 200 Hz and my code stopped outputting stuff (it was supposed to output stuff once per second but only if the FIFO was processed), but it works at 100 Hz. This might take more investigation.

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on March 11, 2012 at 6:58pm

We run the APM at 250hz, and it's running at the same clock speed as ArduIMU so that should be easily possible. 

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• 4
• 5
• …
• 7
• Next ›
• Page