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!
@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....
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.
Sorry i forgot to add the 360 compensation... But yes the YAW is correct. Also i forgot to correct another bug report by Doug Weibel (thanks!). but only affects ground speed display... :/ never is perfect..
Comments
@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...
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.
I want to connect arduIMU to arduPilot.
ny suggestion about the best way to connect them ?
Sorry i forgot to add the 360 compensation... But yes the YAW is correct. Also i forgot to correct another bug report by Doug Weibel (thanks!). but only affects ground speed display... :/ never is perfect..
-
1
-
2
-
3
of 3 Next