Posted by Doug Weibel on December 24, 2009 at 2:36pm
It just came to my attention that people trying to use the latest revision firmware with the older ArduIMU hardware were having problems. The current revision firmware has lots of goodies in it that the pre-v2 hardware firmware did not have such as much better vibration resistance, euler angle output, binary message output for Ardu-IMU-Pilot, etc. We had included code in recent revisions to allow use of either hardware, but I guess neither Jordi, Jose, or myself had checked it on the v1 hardware.There was an error in the sensor_sign[ ] declaration. It has been corrected in revision R19.If you have had trouble downloading all the individual files of the latest revision source code I have added a zipped download file of R19. To select between v1 and v2 hardware you need to pick one of two pairs of of declaration lines to comment out at around line 53. They are commented so you can see which you need. Just place the // in front of the pair you do not need....
Good, I went through the sensor setup, and it is correct, I feel that the code is now at baseline and ready for flight testing, I can freeze both revisions and add more options later. I also fount that using this setup xBee never needs to be disconnected and remains operational, no more X-CTU hard resets !, so far... I look forward to rev 2.5.1 it should be very refined system. I want ArduMegaPilot to be as mature out the gate too.
Oh - sorry Mark!!! I'm pretty sure that is my fault. I am almost positive that I found the pitch reversed in ArduIMUPilot when I did flight testing. I fixed it in my working copy but never fixed it in the repository.
So you have found the problem (again). And you implemented the fix in an appropriate place (AIP_IMU_GPS). Just as a side not I am not going to pursue the ArduIMUPilot firmware any further. Ryan and I will be integrating the good stuff there into ArduPilot 2.5.1. I hope to start work on that tomorrow.
I will let this run for while to see if IMU goes to crap, but it seams very stable, with quick response and holds up to 90° variations without spinning other axis wildly. I will need to check sensor sign setup next..
With this euler sign change when I check IMU with with ArduIMU_v008 or ArduIMU Test v1.17 pitch output is reversed, So I believe I should revert euler sign change and explore down stream in data flow..In ArduIMUPilot
ArduIMU2_DCM_V10_r21 is sw version, I change the sign of euler angles as above and all looks good, but as Ryan states " You have to pick your axis from the beginning and make sure they follow ALL the way through." So I want to make the change in the appropriate point in the flow of IMU data. This change appears to be OK, but why should I need this at all, I may have a non standard setup, but I an striving for a good base line condition I can work from. My be I have something reversed some where thats not obvious.
My setup of sensors:
/*Select hardware version - comment out one pair below*/
uint8_t sensors[6] = {0,2,1,3,5,4}; // Use these two lines for Hardware v1 (w/ daughterboards)
int SENSOR_SIGN[]= {1,-1,-1,-1,1,1}; //Sensor: GYROX, GYROY, GYROZ, ACCELX, ACCELY, ACCELZ , mjc
// uint8_t sensors[6] = {6,7,3,0,1,2}; // For Hardware v2 flat
// int SENSOR_SIGN[] = {1,-1,-1,1,-1,1}; // v2
@Mark - you have the gps connector to the front and you are seeing pitch decrease when you lift that end? If that is the case please let me know what code version you are using
@Ryan - generally correct, but we can get away with a little more here since we have separate IMU and autopilot systems. In our case the euler angles are just output conveniences. They are derived from the DCM matrix elements and stand outside of all the IMU computations. So if a particular person wanted pitch to be defined "backward" they could throw a negative sign on the pitch euler computation and write their autopilot code with pitch having that backward convention. I'm not sure why Mark is seeing pitch as negative - could be he is not understanding our convention or he could be using some older code as we had an error in the pitch computation several revisions back, or could be something else....
Even if you just change the Eulers you are significantly changing the dynamics and it will surely depart. The math has to follow through from start to finish because of all of the simplifications that are assumed in the algorithm. They only work if keep with the convention. If it is just roll you might be ok (I'd have to think about it more) but yeah be very careful just changing things. I would track down everything and make sure its not something simple like accelerations being reversed or something or just a misunderstanding of the chosen conventions
You have to be very careful just removing negative signs here and there to make it work. It can really mess up the dynamic model of the DCM. Specifically the centripetal axis. You have to pick your axis from the beginning and make sure they follow ALL the way through. It will work on the bench but if you model one thing wrong ..... the whole thing will go to crap!
Comments
So you have found the problem (again). And you implemented the fix in an appropriate place (AIP_IMU_GPS). Just as a side not I am not going to pursue the ArduIMUPilot firmware any further. Ryan and I will be integrating the good stuff there into ArduPilot 2.5.1. I hope to start work on that tomorrow.
//Storing IMU pitch
intUnion.byte[0] = IMU_buffer[j++];
intUnion.byte[1] = IMU_buffer[j++];
imu_pitch=-(float)intUnion.word/(float)100; mjc remove "-"
with good results, in GCS 264a now why is this needed for my "standard setup" ?? ArduPilot is a 168 ??
are my sensor signs OK??
My setup of sensors:
/*Select hardware version - comment out one pair below*/
uint8_t sensors[6] = {0,2,1,3,5,4}; // Use these two lines for Hardware v1 (w/ daughterboards)
int SENSOR_SIGN[]= {1,-1,-1,-1,1,1}; //Sensor: GYROX, GYROY, GYROZ, ACCELX, ACCELY, ACCELZ , mjc
// uint8_t sensors[6] = {6,7,3,0,1,2}; // For Hardware v2 flat
// int SENSOR_SIGN[] = {1,-1,-1,1,-1,1}; // v2
Thanks for your help. I want to get this right...
@Ryan - generally correct, but we can get away with a little more here since we have separate IMU and autopilot systems. In our case the euler angles are just output conveniences. They are derived from the DCM matrix elements and stand outside of all the IMU computations. So if a particular person wanted pitch to be defined "backward" they could throw a negative sign on the pitch euler computation and write their autopilot code with pitch having that backward convention. I'm not sure why Mark is seeing pitch as negative - could be he is not understanding our convention or he could be using some older code as we had an error in the pitch computation several revisions back, or could be something else....
-Beall
change this code under DCM? like so.
void Euler_angles(void)
{
#if (OUTPUTMODE==2) // Only accelerometer info (debugging purposes)
roll = atan2(Accel_Vector[1],Accel_Vector[2]); // atan2(acc_y,acc_z)
pitch = asin((Accel_Vector[0])/(double)GRAVITY); // asin(acc_x), mjc remove "-"
yaw = 0;
#else
pitch = asin(DCM_Matrix[2][0]); // mjc remove "-"
roll = atan2(DCM_Matrix[2][1],DCM_Matrix[2][2]);
yaw = atan2(DCM_Matrix[1][0],DCM_Matrix[0][0]);
#endif
}
I thought changing sign here would do it ??
SENSOR_SIGN [ ]={1,-1,-1,-1,1,1}; //Sensor: GYROX, GYROY, GYROZ, ACCELX, ACCELY, ACCELZ
for X axis gyro and accel values.
-
1
-
2
-
3
-
4
of 4 Next