ADC oversampling which increases the effective resolution of the gyros and accelerometers
Drift correction gain de-weighting and speed filtering
Support for binary output messages as well as human readable
Support for both hardware types
Ground and Air start modes
Other improvements and bug fixes
I would like to give praise to Jose Julio for his excellent work on the first two items. I would also like to give Andrew Matthews an award! - "The Big Juicy Bug Squashing Award" for finding a very difficult to find bug in the gps parser. That crazy bug would cause ArduIMU to crash, but only after several hours. Not easy to find a bug when you have to watch all night to see it once.
The binary output messages and air start modes have been added to support use of Ardu_IMU with ArduPilot. Complementary ArduPilot firmware will be coming soon. Interested alpha testers can PM me.
The Labview viewer software is still messed up. If someone with Labview would like to fix it please let me know and I'll tell you what needs to be done. Read more…Developer
Posted by Doug Weibel on January 21, 2010 at 7:19am
The Hobbico SuperStar EP Select is one of the two recommended airframes for ArduPilot and it has been a good choice providing a nice "high wing aileron trainer" at an affordable price. Unfortunately, it has been discontinued for some time and a recent check finds them near impossible to source any more.I have looked around for an equivalent replacement. One I found suitable is the Hobbico NexSTAR Mini EP, which is more or less Hobbico's replacement for the SuperStar EP Select.
It is sold either as a ready to fly package with a 2.4 Ghz radio or as a receiver ready package. Tower Hobbies has these two for $270 and $180, respectively, and Tower usually has a coupon out which will give you $15 to $20 off. Just google "tower hobbies coupon discount". Replacement fuselages, wings, and tail surfaces are also available. While the receiver ready price is 50% higher than what we were paying for the ARF Superstar, the inclusion of a brushless power system and servos makes the price a reasonable value.I received a receiver ready kit today and have inspected it. Apart from the covering being a bit wrinkled, which I think is a Hobbico trademark, I am pretty happy with the quality. See pics below comparing the SuperStar and NexSTAR.While it is nearly as long as the SuperStar and has just a bit less wingspan, the chord is substantially less and the weight is substantially less. Since it is designed for a brushless/LiPo power system the reduced wing area is appropriate. The fuselage width is adequate for UAV purposes. You can see the Mega board inside the fuselage in one pic below.Things I like:* It is a "receiver ready" kit, so it is very complete. About all you need to fly it is a TX, RX, and battery.* Fuselage is plenty deep so no issues with interference between AP gear and the aileron servo arm and pushrods* The wing ribs all have lightening cutouts so fishing a pitot line to the outboard leading edge will be much easier.* Steerable nose wheel, servos, brushless motor and esc all come pre-installed.* A good wing attachment system using a nylon bolt and a fitting that allows flex in a crash.* Reported flight times of 15 minutes on a 3 cell 2100 mAh LiPoThings I didn't like:* A balsa shelf will need to be added for the AP as the shelf for the RX is small. An additional shelf will provide a nice large area for the AP, but it will be under the rudder and elevator control rods so hooking up wires will be a bit fiddly.* A little smaller than I expected.I am short on receivers today, so I probably won't fly this for a week or so, but will post comments when I do.
Posted by Doug Weibel on January 13, 2010 at 11:39am
1 of my 2 Ublox modules has developed a problem. It refuses to get a fix. I am monitoring it with Ucenter and see that it is operating, it is tracking 7 or 8 satellited from inside my house, but it won't get a fix. I notice that it is getting the correct UTC time, but it cannot tell the date! I assume this is why it can't solve for a fix. I have reset the configuration and performed several cold starts. Not sure what else to try??? Any suggestions?
Read more…Developer
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....
Read more…Developer
Posted by Doug Weibel on December 15, 2009 at 3:30pm
Today the weather finally cooperated and I dashed off to my local flying field for a long lunch.
My Ardu-IMU-Pilot had two successful flights! Performance was quite poor, but considering that I changed all the control laws and picked gains out of the air I am satisfied that the UAV was able to complete the prescribed circuit (multiple times in fact).It is funny to see this track on google earth because in fact most of the ground today was covered in snow. I'll have to remember to see how snow cover affects the thermopiles some time.What I did:I converted my current UAV (Superstar EP airframe, Brushless/lipo power system, Thermopile based ArduPilot autopilot) to a IMU based system. To do this I used ArduIMU. I connect the GPS to ArduIMU and connect the serial output of ArduIMU to ArduPilot. I have modified V2.4 of the ArduPilot code significantly to use data from ArduIMU rather than the thermopiles. I have also modified the ArduIMU code to provide a binary data message to ArduPilot.Results:My test flights today proved out the architecture. The new autopilot system successfully provided stabilization and navigation. However, performance was quite poor and I need to do some tuning of both the code and the gains.I chose to completely change the control laws. I did this for two reasons. First, because this is open source and I can! Second, because I wanted to try out some ideas for the turn-rate limiter workgroup. Briefly, I added a cross track error component to the roll control loop (zero gain today), I changed the elevator control loop so that elevator is used to maintain constant airspeed, and the throttle control loop is used to maintain desired altitude.Trying out the new elevator and throttle control laws simultaneously with poor gain choices was a disaster. So, I quickly rewrote the elevator control to just hold zero pitch. With this change things went better.What went poorly:Well, my roll gains need adjusting. Rolling into a turn would produce bank angles in excess of the desired maximum, and there was a lot of wing wagging going on at times.Also, my quick patch to hold zero pitch I believe in fact was holding some amount of up pitch relative to the wing. When the UAV was below target altitude and the throttle setting was relatively high things went well. However when the UAV got above target altitude the throttle was reduced to a low level things did not go so well. The elevator continued to hold zero pitch, which was actually some amount of positive pitch, and the airframe slowed until it stalled. I found that it (my SuperStar) does not stall nicely, with a very pronounced tip stall. This produced a couple of unwanted circles during the mission.Going forward:I think my next step will be to do some manual flying with data logging to get some data on throttle settings versus pitch & airspeed. With that data I should be able to rework the elevator and throttle controls. I would also like to log some data during some manually flown aerobatics and see how my ArduIMU results compare with those being gathered by Jose Julio.
Read more…Developer
Posted by Doug Weibel on December 6, 2009 at 1:30pm
I have completed ground testing on the new firmware I have written for ArduPilot to use ArduIMU in place of the thermopiles. It has been snowing here and I probably won't get to fly the code for a bit, but figured others might be interested in giving it a try at this point. This firmware will probably exist on a temporary basis, with the code getting incorporated into the regular ArduPilot firmware in the future. If there is sufficient interest in this approach I will consider working on a ArduPilot shield board that would add the pressure sensors to ArduIMU and package it all as a shield.
If you try it out give me your feedback. It is similar to ArduPilot 2.4 but uses a different header file.
To interface ArduIMU to ArduPilot you connect the gps (ublox only) to ArduIMU, provide common power and ground to ArduPilot and ArduIMU, and connect the serial output pin of ArduIMU to the serial input pin of ArduPilot.
Read more…Developer
Posted by Doug Weibel on October 8, 2009 at 5:00pm
Hello All,I am going through the ArduIMU v1.1 software and getting ready to start modifying it for my own purposes. I am pretty excited about this IMU and think there are some really cool, creative things that can be done with it.I keep generating questions that people are helping me find the answers. I've decided to update this top post as questions get answered so that it will be a bit of a FAQ,I know there are others than me digging in to the code, so post your questions and answers as comments and I'll keep the FAQ at the top updated :)DougCURRENT QUESTIONS:Q The V1.1 download code has#define Kp_YAW 0 //.5Yaw Porportional Gain#define Ki_YAW 0 //0.0005Yaw Integrator Gainso the values in use as downloaded are zero and there is no yaw drift correction. Has anyone tried out the values in the comments? What testing did you do and what were the results?Q I have been looking at the accelerometer data to see if I could use it to integrate velocity, but it looks much too coarse, and despite claims that accelerometers don't drift mine have some poor behavior that I would either call drift or hysteresis. For example, using groundtest.vi and looking at the accelerometer data - With the IMU sitting on my desk the raw accelerometer data should be (and initially is) 0, 101, 0. However, after moving the IMU around and then bringing it back to rest I might see data of 1, 101, 2, or 0, 101, -3, and those readings might persist for quite some time (>20 seconds). If you work the math on 0, 101, 3 it works out to indicating a velocity of 13 miles per hour in the z direction after 20 seconds. So, the question is: Is this hardware any good for inertial navigation applications???ANSWERED QUESTIONS:Q Where is the yaw drift correction??? Am I correct in thinking that it is not included in this release of the software?A - No - the yaw drift correction is handled in the roll_pitch_drift() routine. However, note that the P and I coefficients are set to zero in the v1.1 download. You will need to change them. I haven't tested values out yet.Q Why is Gyro_Scaled(x) defined as x*((Gyro_Gain*PI)/360) instead of x*((Gyro_Gain*2*PI)/360) or x*((Gyro_Gain*PI)/180)?A Well, because the factor of 2 is incorporated in the Gyro_Gain (we think)Q Why the procedure in setup() of reading the adc's 75 times? From the filtering it looks like 3 or 4 times should be sufficient as the value after any read is 90% the most recent measurement and only 10% previous averaged measurements.A I looked at the raw data and for some reason the data is pretty goofy the first 5+ times through the loop, almost like you need to warm up the AD converters. Can't explain it, but that is probably why 75 samples are taken even though 5 would be sufficient with the filtering used.Q Why is AN_OFFSET[4]=AN[4]+GRAVITY instead of AN_OFFSET[4]=AN[4]-GRAVITY?A Because gravity works to lessen the value of the raw data in the y axis, so GRAVITY is added back to get the "zero gravity" offset. It is just a matter of the direction and sign.
Read more…Developer
Hello All,I have started into an ArduPilot project to satisfy my curiosity and to draw my 12 year old daughter out of her novels and into some practical math and science. My intent is to start with a straightforward ArduPilot set-up with the current hardware and software.The airframe I chose is the SuperStar EP. We finished assembling it last night. It is stock (for the present) except I am running a 3 cell 2200 mAh LiPo instead of the stock NiCad. With 200 grams less weight and considerably more voltage the SuperStar performs quite nicely. We are just back from 2 quick flights at the local schoolyard. My daughter learned what happens when you land in grass that is 4 times as tall as your tires :)Tonight we will begin assembling the autopilot hardware. Again I am going with the "stock" setup - DIYDrones IR sensors and shield with airspeed, and EM406 gps.I have not ordered parts yet for downlink and groundstation. I was not planning to implement that right away, but judging from some posts I have seen it may be highly desirable for debugging purposes. I'd appreciate any opinions on that as well as on using the hardware ground station versus a laptop setup.Best Regards,Doug
Read more…
