Posted by Jordi Muñoz on October 12, 2009 at 2:30pm
Hi there! I'm happy to announce the new ArduIMU firmware and ground station, you can download it from here:http://code.google.com/p/ardu-imu/downloads/listWhat new in the firmware:-You can now select DCM, Euler Angles our both.-Enable GPS output data.-Some minor bug fixed.-The orientation of the gyros and accels are now corrected.Whats new in the Ground Station:-Now the Baud speed is set to 38400 bps to be compatible with ArduPilot uBlox GPS.-You can see now the Euler Angles generated on the uController.-Better debug tools.-GPS information.-Raw Data.What i'm doing now:-Designing new PCB's.-Improving ArduPilot code.-FPV testing with ArduPilot.-Taking care of the business and shipments.-Improving the Store.-Going to School.-Trying to answer some emails.-Always trying to get a beer and some Sushi..Please be patient, I'm always working for you! ;-) Thanks for you support!
I'm trying to port v1.2 code to an ARM based board but I'm stuck with some issues. The main question is: can v1.2 code actually represent each and every aircraft attitude, including +/- 90 deg roll and pitch and upside down ? I'm not thinking of the DCM in general: for what I undestand DCM can represent all attitudes. The question arose when I zeroed gyroscope signals to adjust the pitch/roll gains. I expected that turning the board 90 degrees around x axis would result in the roll angle being 90 degrees. What I see is that roll angle "saturates" at about 30 - 40 degrees. The same holds for pitch. I checked the accelerometer's conversion factors over and over again, without results. I'm "looking" at the board's attitude with this python script from Brian Wolfe. Suggestions are welcome.
@Ken - I had the same initial thought on the 75 degree thing. I have not had time to run it down yet, but Bill P. gave me another idea that may be what is actually going on. He said to play with the raw gyro gain as I may have gyros that are at the edge of the tolerance, or even outside. This potentially makes more sense than the PI loop "dragging" the yaw back temporarily as if I drive along and come to a stop and let the gyros drift, then go again I see that it takes several seconds for the yaw correction to occur. So, the yaw correction should not have a quick enough effect to "drag back" the yaw from a quick turn.
@Ken - also, I am working with Jordi to get out v1.3 which will correct the coordinate system and will take care of the yaw calculation error as well. Look for v1.3 out maybe Monday.
@Khalid - No blue means no GPS lock. Have you tried outside? Are you using V1.1? V1.1 had a baud rate issue where ArduIMU and the GPS were on two separate baud rates....
Green LED (furthest from the GPS connector) is on when power is applied. (At least thru the programming connector which is where mine is powered & communicated with).
Red LED comes on when a gyro goes over 300 degrees/sec. Hold the board so you can see the LEDS, and give your wrist a quick flip.
Blue LED is GPS lock.
Yellow LED does not seem to be used in this version. .
That blinky pattern at power up is the software starting up. It reads the ADCs 75 times and blinks the lights. I don't know if you successfully uploaded the new code or not, but one version or the other is running. (The blinky pattern is not the boot loader.) Have you looked at the serial output on a PC?
1. I was poking through some navigation documents and "the standard" is that 0 degrees is East (and measured CCW!) I think there are some artifacts of that in this code and that is why we see 90 degrees too high of a course.
2. Your comment about seeing 75 degree change happening quickly then closing up to 90 degrees is, I think, actually a jump *back* to 75 degrees from 90 degrees caused by GPS lag. When I have KP and KI to values that move the IMU to the GPS heading in just a few seconds (0.25 to 0.5 for KP), this is what I see: Going north with nice steady 0 degree outputs. Turn quickly to east, get a quick flash of about 90 degrees. But the GPS still is at 0 degrees (or maybe it comes as 12 degrees, 18 degrees or whatever) so the IMU sees a huge error and swings backward to 75 degrees. Then, after the IMU has gotten a 90 degree heading from the GPS for a second or two, the IMU comes back to 90 degrees. Problem: If I were to steer by the IMU heading, not the road, I would over steer for a second or so (because the IMU said I was only at 75 degrees when I wanted 90 degrees). On the other hand, if I back KP way off to 0.001 or so, such that the IMU does not swing back so fast, the IMU never really finds its way to the GPS heading. There are some band-aid fixes (with drawbacks) such as ignoring GPS course if gyro rate exceeds a threshold. But doing that, what if we are in turbulent air and getting lots of gyro swings...would we ever be able to apply GPS corrections? Maybe something along the lines of KPused = KPmax / (abs(gyro rate x) + abs(gyro rate y) + abs(gyro rate z) ) ?
3. Agree on the speed filter too. If abs(speed) < threshold ignore GPS heading.
Sorry Chris. I had posted the issue in another thread. Basically, I flashed the board without a problem. The board then resets and the three LED's flash during startup. After that, there is nothing - no LEDs, nothing happening in the software that would indicate any sign of life. Reading through the posts and looking at the origial demo video, it would seem to me that the blue LED should light indicating GPS lock, and the other LEDs light based on movement. Is this correct?
OK, so I got the ArduIMU out in my car for an half hour or so for some testing.
Hint - testing an IMU in your car without an assistant = reckless driving. I kept thinking about how I was going to explain the gizmo with the flashing lights and the laptop running Labview to the police officer (who thankfully did not pull me over).
@Ken - I found the IMU heading to be 90 degrees high in all directions. Probably a simple math error in the code, but I've had a long day and am putting off looking for it till tomorrow.
My observations:
The centripetal correction looks pretty good! I did not do a traffic circle at .8 g's, but the "cube" in the demo program stays nice and flat when going around corners in my car.
I think we need some more tuning on the yaw feedback gains. When making a rapid 90 degree direction change (without saturating the gyros) the yaw angle would immediately change about 75 degrees, and then take 3 or 4 seconds to complete the other 15 degrees of change. I think this means that one or both of the feedback gains is too high. I tried dropping them both by an order of magnitude, but that produced some very nasty behaviour with a high amplitude low frequency oscillation.
Last observation - If you are going to test in a car or by some other method where you stop moving occasionally I would recommend putting a speed filter in the feedback loops such that the yaw feedback value is not updated when the speed drops to near zero. When you quit moving the ground course value is just set by the noise in the position estimate and the yaw solution blows up pretty quickly.
Ken, I'm set to haul the ArduIMU around in my car a bit this evening and I'll see what I can come up with on the yaw questions. I don't think hard coding the ground speed to a value will give you a valid test at it implies a centrepital acceleration that is not present. Seems that should cause the yaw to drift quickly.
OK. I've got it mostly worked out. (1) I cut KP and KI for yaw way back so that things happened more slowly and I could see what was happening and (2) fixed one of my own bugs then (3) Discovered the IMU heading runs 90 higher than the GPS heading for all GPS headings between 1 and 90 degrees. (Will check the other quadrants later.) So far, replacing the COGX and COGY calculations in the DCM section with "ground_course - 90" has everything pointing the same way.
Comments
I'm trying to port v1.2 code to an ARM based board but I'm stuck with some issues. The main question is: can v1.2 code actually represent each and every aircraft attitude, including +/- 90 deg roll and pitch and upside down ? I'm not thinking of the DCM in general: for what I undestand DCM can represent all attitudes. The question arose when I zeroed gyroscope signals to adjust the pitch/roll gains. I expected that turning the board 90 degrees around x axis would result in the roll angle being 90 degrees. What I see is that roll angle "saturates" at about 30 - 40 degrees. The same holds for pitch. I checked the accelerometer's conversion factors over and over again, without results. I'm "looking" at the board's attitude with this python script from Brian Wolfe. Suggestions are welcome.
Thank you all.
@Ken - also, I am working with Jordi to get out v1.3 which will correct the coordinate system and will take care of the yaw calculation error as well. Look for v1.3 out maybe Monday.
@Khalid - No blue means no GPS lock. Have you tried outside? Are you using V1.1? V1.1 had a baud rate issue where ArduIMU and the GPS were on two separate baud rates....
Green LED is on. Red LED comes on with a flip of the wrist. Blue LED is off. No serial output is being displayed on the PC. Getting closer...
Green LED (furthest from the GPS connector) is on when power is applied. (At least thru the programming connector which is where mine is powered & communicated with).
Red LED comes on when a gyro goes over 300 degrees/sec. Hold the board so you can see the LEDS, and give your wrist a quick flip.
Blue LED is GPS lock.
Yellow LED does not seem to be used in this version. .
That blinky pattern at power up is the software starting up. It reads the ADCs 75 times and blinks the lights. I don't know if you successfully uploaded the new code or not, but one version or the other is running. (The blinky pattern is not the boot loader.) Have you looked at the serial output on a PC?
Yep. Just what I am seeing.
1. I was poking through some navigation documents and "the standard" is that 0 degrees is East (and measured CCW!) I think there are some artifacts of that in this code and that is why we see 90 degrees too high of a course.
2. Your comment about seeing 75 degree change happening quickly then closing up to 90 degrees is, I think, actually a jump *back* to 75 degrees from 90 degrees caused by GPS lag. When I have KP and KI to values that move the IMU to the GPS heading in just a few seconds (0.25 to 0.5 for KP), this is what I see: Going north with nice steady 0 degree outputs. Turn quickly to east, get a quick flash of about 90 degrees. But the GPS still is at 0 degrees (or maybe it comes as 12 degrees, 18 degrees or whatever) so the IMU sees a huge error and swings backward to 75 degrees. Then, after the IMU has gotten a 90 degree heading from the GPS for a second or two, the IMU comes back to 90 degrees. Problem: If I were to steer by the IMU heading, not the road, I would over steer for a second or so (because the IMU said I was only at 75 degrees when I wanted 90 degrees). On the other hand, if I back KP way off to 0.001 or so, such that the IMU does not swing back so fast, the IMU never really finds its way to the GPS heading. There are some band-aid fixes (with drawbacks) such as ignoring GPS course if gyro rate exceeds a threshold. But doing that, what if we are in turbulent air and getting lots of gyro swings...would we ever be able to apply GPS corrections? Maybe something along the lines of KPused = KPmax / (abs(gyro rate x) + abs(gyro rate y) + abs(gyro rate z) ) ?
3. Agree on the speed filter too. If abs(speed) < threshold ignore GPS heading.
Gonna have some fun this weekend!
Sorry Chris. I had posted the issue in another thread. Basically, I flashed the board without a problem. The board then resets and the three LED's flash during startup. After that, there is nothing - no LEDs, nothing happening in the software that would indicate any sign of life. Reading through the posts and looking at the origial demo video, it would seem to me that the blue LED should light indicating GPS lock, and the other LEDs light based on movement. Is this correct?
Hint - testing an IMU in your car without an assistant = reckless driving. I kept thinking about how I was going to explain the gizmo with the flashing lights and the laptop running Labview to the police officer (who thankfully did not pull me over).
@Ken - I found the IMU heading to be 90 degrees high in all directions. Probably a simple math error in the code, but I've had a long day and am putting off looking for it till tomorrow.
My observations:
The centripetal correction looks pretty good! I did not do a traffic circle at .8 g's, but the "cube" in the demo program stays nice and flat when going around corners in my car.
I think we need some more tuning on the yaw feedback gains. When making a rapid 90 degree direction change (without saturating the gyros) the yaw angle would immediately change about 75 degrees, and then take 3 or 4 seconds to complete the other 15 degrees of change. I think this means that one or both of the feedback gains is too high. I tried dropping them both by an order of magnitude, but that produced some very nasty behaviour with a high amplitude low frequency oscillation.
Last observation - If you are going to test in a car or by some other method where you stop moving occasionally I would recommend putting a speed filter in the feedback loops such that the yaw feedback value is not updated when the speed drops to near zero. When you quit moving the ground course value is just set by the noise in the position estimate and the yaw solution blows up pretty quickly.
and anyone else digging in to the ArduIMU code....
I've got a couple of unanswered questions hanging in my blog post:
http://diydrones.com/profiles/blogs/arduimu-v11-now-v12-questions
Ken, I'm set to haul the ArduIMU around in my car a bit this evening and I'll see what I can come up with on the yaw questions. I don't think hard coding the ground speed to a value will give you a valid test at it implies a centrepital acceleration that is not present. Seems that should cause the yaw to drift quickly.
-
1
-
2
-
3
of 3 Next