All Posts (14056)
Sort by
Software...
There a several problems, when you do embedded software documentation. The most evident one is, that you don´t have so cute looking pictures as you have when documenting mechanics or hardware.
Despite that fact, i provide one:
This nice plate was photographed in the vicinity of a Buddhist temple on my last holiday in Thailand.
The wisdom of this sentence becomes evident, when you are a developer, especially if you are a software-flavoured developer.
A (now retired) customer of mine, who was specialized in mechanics and optics development once asked me:
"Do you know what´s the real hell on earth? "
I said "no".
"I will tell you: It is water and software combined in one device"
At that time we were involved in the software development for a laser-system that had water-cooling.
He was right!
Bringing the ArduPilot into the water was a bit like that project.
The baseline for the development of the ArduPilot software was the very first version of the ArduPilot, which was published as Version 1.0 and can be downloaded from Google-code. http://code.google.com/p/ardupilot/
The V1.0 zip file should be found here: http://ardupilot.googlecode.com/files/ArduPilot1.0.zip
For the installation of the Arduino platform, please have a closer look to this site:
here you will find a very good introduction, how to get all up and running. I also would suggest to read the whole Ardupilot Manual first, before starting any actions: The Manual can be found here
The following list contains the modifications and bug fixes that i have applied to the V1.0 code. The list may not be complete, because my book-keeping of the changes was not very accurate, when i was in the hot-phase of the development.
1) Some #defines for constants were added, because "magic numbers" inside the code may cause troubles, when used more than once. All constants are now shown in upper-case letters.
2) The data-structure for the waypoint-list was changed to a predefined array, so the initialization of the predefined array is done by the startup-code of arduino itself. The tab "Mission_setup" was no longer used and was therefore deleted.
The array that holds the waypoints is now located in the "ArduPilot" tab.
The structure for the waypoints looks like this:
typedef struct
{ float lon;
float lat;
}LONLAT;
The predefined waypoint array looks like this:
LONLAT wps[ ] =
{
10.02069619383977, 48.35006621372347,
10.02018762320307, 48.35061609619746,
10.021905, 48.350598 /* Home*/
};
3) The number of elements that are contained in the array is calculated upon startup. (one of my first recovery-swimming actions was caused by an erroneous waypoint, that the ship tried to reach, because the "#define waypoints" directive of the original version did not match with the real number of elements in the array) .
4) All code that had to do with "Return to launch" or "Manual Mode" was eliminated.
5) All code that had to do with altitude control was eliminated.
6) Some unused test variables have been deleted.
7) All calculations in the PID-control are done now on a one-second base. In the original code, the time betweeen the executions was calculated and the value was multiplied / divided by the Integrator and derivator part (the dt variable in the 1.0 code). When using a 1Hz update rate, the factor is one and so, i deleted the code, to avoid unnecessary floating point operations. In reality, the update rate, which is driven by the GPS jitters a little bit, because the NMEA-messages are different in length. But for the practical use, this is of no concern.
Attention, when using a GPS with a faster update-rate, this functionality has to be reactivated.
8) In the orginal PID-control, the "heading_output" variable, that keeps the result of the PID calculations was of type "int". The calculations are done in float. This led to a big inaccuracy, because i used k-values that were below 1.0. Maybe for the first implementations of the Ardupilot nobody noticed that, because for the EasyStar values of around 10 were used for the kp and the integrator/derivator were not used and so, the error caused by that was very small. I changed it to float and all was fine.
9) I changed some suspicious "int" to "float" assignments and did a casting, everywhere i found it necessary.
10) The integrator values are reset upon startup and on each waypoint switch and held to zero for 25 seconds after the switch. This cures two problems:
1. The NMEA-parser has still a bug, that sometimes produces erroneous readings upon startup.
2. after sharp turns, the integrator adds up and causes offset problems. The 25 seconds is the time needed for a full 180° turn of the actual ship (catamarane).
This time is set in the #define WP_TIMEOUT directive.
11) I often use #if 0 (1) directives to switch off or on code or data segments.
i find this more convenient than commenting the parts out.
12) I added #define "model" segments to switch between different parameter sets (catamarane and monokeel in the actual version). note, that only one can be active at at time
For the moment, thats all that can be told about the software. Please leave a comment if you have any further questions or suggestions.
Here is the .zip file that contains my actual code:
Not much pictures in this episode, but i add here a "guess-what" one.
More about that in the next episode...
Congratulations to Antonio Lyska, the UAV winner of the Sparkfun Autonomous Vehicle Competition! In his final run, he did a 26 second lap and then nailed an autonomous landing in the box for a 30 second deduction, for a final score of negative 4 seconds. Even more impressive, this was totally DIY--he's been working on his Rabbit-powered IMU-based board for five years, and coded everything from scratch, including a beautiful custom ground station. He's so confident in his setup that he doesn't even watch his plane in flight--he just watches the action on his ground station. That's him above, with his flying wing crossing the start line for the victorious run. So calm!
In second place, with a time of 3 seconds (18 second run, minus 15 seconds for attempting an autonomous landing) was Doug Weibel, with ArduPilot IMU (version 2.6 code) on his SkyFun. His plane did a gorgeous run, with sharp turns and rock-solid stabilization and the fastest time of any UAV, but it got a bit lost coming in for the autonomous landing and ended up crash-landing in a nearby parking lot. But autonomous landing was attempted, and the plane gave up some foam to get those 15 points!
In third place was the University of Arizona Paparazzi team, which impressed everyone with their autonomous landings. The last one just missed the box, but otherwise it was very solid all day. Their best score was 5 seconds, after deductions.
Jordi and DIY Drones came in fourth place with 37 seconds (no deductions attemped) with our ArduPilot (2.5.4 thermopile code) and EasyStar.
The UAVDevBoard teams impressed everyone with their awesome vertical starts, acrobatic maneuvers and stunning stability. Unfortunately all that sky candy came at the cost of clipping corners (in the case of Ben Levitt's Acromaster), so he didn't get a course completion score.
Adam Barrow managed to go to a local hobby shop and get replacement parts to reubuild his T28, which was flying perfectly with the UAVDevBoard. But in the final practice flight he lost control in manual mode and piled it in again, so he wasn't able to compete in the final rounds. But based on the glimpse of autonomous performance, that plane and autopilot are going to be a serious contender next year.
For next year, we're thinking acrobatic plane and quad copters are going to win the day, given the scoring system. Can't wait!
"Robota": Rabbit-powered custom autopilot. He did everything himself!
"UofA Robotics": Paparazzi-powered Twinstars
"Pine Tree": Doug Weibel and his ArduPilot IMU-powered Skyfun
"DIY Drones": The tried and true ArduPilot-powered EasyStar
"Donuts, Coffee and Muffins": Ben Levitt and his UAV DevBoard-powered AcroMaster (backup one!)
Adam Barrow and his UAVDevBoard-powered T28
Ryan Beall and his custom autopilot, Ateryx, in a Alpha Sport 450 (not competing)
The rain has picked up, but we all got a good round two in. Here are the current standings, in order:
- The custom Rabbit-powered wing ("Robota") had a great run, with an auto takeoff (hand launched, so it didn't count, but still impressive) and an autolanding that just nailed, stopping right on the box line. He got a 30 second deduction for that, so his 34 second run turned into a time of 4 seconds, for first place
- The U Arizona Paparazzi team ("UoA Robotics")had a 35 second run, but nailed a perfect autonomous landing, for a 5 second second place.
- Doug Weibel tried an autonomous takeoff with ArduPilot w/IMU Skyfun ("Death by Pine Tree"), but it didn't quite pull up in time. He was allowed a second start (manual this time) and blasted through a very tight 20 second run for fastest overall time, but no bonus points, and thus third place
- The rain let up enough to let Jordi ("DIYDrones") do a slightly faster and very smooth second run of 37 seconds with the stock ArduPilot and EasyStar, giving us 4th place
- Both of the UAVDevBoard planes were recovered (one from a fence, another from a roof) but both are unflyable. Fortunately, Ben Levitt ("Donuts, Coffee and Muffins", a play on the DCM algorithm that we all use) had a backup AcroMaster. He did an autonomous VERTICAL takeoff, then a couple autonomous barrel rolls, then some calibration loops upside down, then did the course upside down. Awesome tight control, and pretty fast at 30 seconds, too, but unfortunately he clipped a corner and didn't score that round.
The rain is getting pretty heavy, so we thermopile guys may not do a third round, which would leave it to the IMU teams to win. Nail-biting suspense!
- Jordi and me (ArduPilot with thermopiles on the old EasyStar we used last year)
- Doug Weibel (ArduPilot with the IMU on a SkyFun with elevons)
- A Paparazzi team from the University of Arizona flying Twinstars
- A flying wing with a custom Rabbit-CPU based autopilot.
TwoUAV Devboard teams:
- Ben Levitt with an Acromaster pattern plane
- Adam Barrow with a Parkzone T28),
We all just finished the first of three rounds. Results after round one:
- We did a conservative first pattern and completed it in a time of 41 seconds, putting us in second place
- The Paprazzi team completed in a time of 21 seconds and attempted an autonomous landing, putting them in first place
- Doug Weibel put in the fastest time at 14 seconds, but clipped a corner so it didn't count
- Ben's plane did a vertical autonomous take-off, which was awesome but went down when it was doing an autonomous wind-calculation loop. They haven't found it yet, but think might be on a nearby roof.
- Adam's T did a rolling autonomous takeoff, which was super exciting (just missed a tree), but then it too went down in the same place while doing an wind estimation pass. Fortunately they found it, but the plane was destroyed.
- The custom flying wing also did a conservative first run, and finished with a time of 59 seconds.
Here's Jordi tweaking code in front of the start/finish line:
The new EPO foam version of the Skywalker UAV platform are now for sale.
Price 144 USD + 40 USD in shipping.
New price!
- 8 AM - Team Admission
- 9 AM - General Public Admission
- 9:30 AM - 1st Heat Start Time, Raffle at End of 1st Heat
- 12 PM - 2nd Heat Start Time, Raffle at End of 2nd Heat
- 2:30 PM - 3rd Heat Start Time, Raffle at End of 2nd Heat, and Free-For-All Race (mass start)
- 4:30 PM-ish - Awards
- 6 PM-ish - After party @ Dark Horse
Time is for Boulder Colorado, USA.
Make sure you watch the ustream channel for live video of the event.
I stumbled upon this and thought others may think it's interesting as well...
Who knew the SP guys had competitions where they race around a triangle pattern of GPS coordinates? View results on Google Earth, get addional details from the plane to the ground station... Lots more.
Sounds fun but it's a little pricey.
The equipment seems like it would be very easy to adapt to UAVs...
For additional details check the link below.
DEATH OF A RADIO
Finally surrendered the ground station to tethering. It was a long battle with 72Mhz, 2.4Ghz XBees, & 900Mhz FSK but we never had enough money to make it reliable enough. Still using a custom transmitter with 8 channels. Went with a 2 conductor audio cable & 1/4" TRS connectors for the most reliable connection possible.
Nothing is more reliable than the 1/4" TRS connector, invented in 1878 in a strange country no-one remembers the name of & used in the 1st telephone switchboards. It's still going strong 132 years later. Modern connectors only get smaller & less reliable. You're flying history with this rig.
MARCY 1
Got some freshly captured HD video of Marcy 1 in flight. She had 1 broken propeller. She needs to spin a lot faster to go autonomous, but that means an actuated flap. Back to Marcy 2 while we think it over.
So basically, to get anywhere autonomous or even controllable, Marcy 1 needs to spin a lot faster. You can see the influence of RPM when ascending & descending. But the goal of the Marcy 1 program was to spin as slowly as possible to extend flight time. The balance beam also negates throttle modulation by adding momentum.
The Marcy 1 stability problem has us leaning towards a 3DOF IMU with very high saturation limits & a proportionally actuated flap. The idea is to use a flap to stabilize angle of attack at low RPM like a very large balance beam.
Fortunately single chip IMU's finally exist. Could put 1 on Marcy 1 to figure out how to get angle of attack. There's no way to directly measure angle of attack. You'll get a large yaw rate on 1 plane involving all 3 gyros. Separating that from the other 2 components would be real hard.
The increased cost & wind resistance probably make a full size monocopter much more valuable than a micro monocopter.
MARCY 2
Marcy 2 has a real electronics problem. Her radio initializes in the apartment but not on the golf course. Carry it to the golf course after initializing in the apartment & it stays initialized. Shut down on the golf course, wait a while & it won't reinitialize. It seems temperature & humidity related. Rarely, when it initializes, it dies shortly after. How can a Marcy vehicle not initialize on a golf course?
Got some indoor footage.
VIKA 1
The battle of the Aiptek continues. Got it running on the CC-BEC. It did malfunction during a flight & lose all our sunset footage. Suspect the battery contacts glitched.
TILT SHIFT TERRORISM
Look at this, kids. Autonomous, tilt shift, aerial, & timelapsed.
Finally wrote a lens blur effect.
TILT SHIFT MAGIC
Interesting story behind that flight. We flew over Sunnyvale instead of Mountain View to avoid falling in love with Major Marcy. Then She
moved to Sunnyvale.
AIR FORCE RESEARCH
Major Marcy discovered Marcy 1. She seems to be taking it well, so far.
> So, I see you named your aircraft after me!!!
> I sure hope you're a good pilot because I don't
> want to crash and burn.
Still doesn't want to have anything to do with us in real life, but at least She responded to the rejection requests.
We had a full house of university leaders yesterday at the FIRST Robotics Championship for our planning/brainstorming meeting on a potential indoors aerial robotics competition. We opened with Dean Kamen, the founder of FIRST (and famed inventor of things like the Segway) describing the opportunity for a next level competition for university students (shown above). Like a "NCAA" league to go with the "Little League to High School" model that FIRST now covers (apologies for the American analogies!).
Vince Wilczynski from the Coast Guard Academy, Steve Barker from HiTechnic and I presented some options, and Jordi and I demoed Blimduino and the Parrot AR.Drone.
The general takeaway from the meeting, based on the advice from the university leaders: they love the idea of a FIRST-sponsored aerial robotics competition, but that it has to be really cool to draw sufficient participation from the students. Many of them are engineers and the range of available projects to them in undergraduate and graduate school these days is pretty amazing, from cars to other bots, so the platform we choose has to have a high "wow" factor.
I suspect what that will mean is that we'll steer the college-level competition towards quadcopters (possibly in combination with ground rovers) and push the blimps more towards high school classes and competition. All the more reason to move ahead with our Parrot AR.Drone UAV conversion board...
And look what Jordi and I found in an alley outside the Georgia Dome on the way home:
April 22--
My futaba 7c faast tx/rx just arrived today in the mail and what a beauty of a power horse she is. All of my autonomous gear is here except for the 2 xbee pro 900's and the antenna. And as soon as my Hawksky airframe gets here I will be fully setup and ready to start mounting parts. Going to be interesting to see how everything fits together.
This is interesting...
I had a couple of very brief flights with my slightly modified ArduPilot 2.6 code this evening.
I only had the chance to do a couple of passes in fly by wire mode, but the initial results are promising.
Still some gain tuning to do, but this isn't bad for a first attempt.
In the plot below:
Blue line is bank angle
Red line is pitch
Green is heading.
Blue DOTS indicate times when the Ardupilot was in Fly By Wire mode.
As you can see I'm getting oscillations of ~5 degrees around zero. Time for some gain tuning.
More importantly, I do think I am having range issues with the Ardupilot. The antenna down range test before the flight was not quite as good as I'm used to, however I decided it was safe to try. During the flight I did have a few glitches while in Manual mode, so I'd like to improve my range test results to try to clear those up.
Time to clean up my wiring a little. As you can see it's a bit of a rats nest right now.
Tom
In case it is useful to anyone, here is my code for controlling the 4th channel through the Ardupilot board.
The main thing that stumped me for a while is you need to change timer2 from CTC mode to Normal mode. The default Ardupilot code has Timer 2 in CTC mode which resets the counter every time the throttle compare interrupt is captured. To drive two channels you need to be in Normal mode allowing the timer to go all the way to 255 before resetting.
Channels 3 and 4 to have noticable more granularity than the first two channels (as expected), but within this granularity, the movement is nice and reliable. In the linked video, you can see that when being controlled by the ardupilot the rudder motion is slightly more jerky.
I also added an extra flight mode to my code called SERVO_TEST. When in servo_test, the main loop skips any sort of navigation or stabilization, and simply passes the radio inputs through to the servos. I did this so I could get a feel for how well my servo code was working.
I hadn't seen any code on the site for channel 4 actually integrating into an Ardupilot software load, so I thought I would post mine..
My pin assignments are as follows:
pinMode(2,INPUT); //- Aileron in
pinMode(3,INPUT); //- Elevator in
pinMode(8,OUTPUT); //- Throttle out
pinMode(9,OUTPUT); //- Elevator out
pinMode(10,OUTPUT); //- Aileron out
pinMode(11,OUTPUT); //- Rudder out
pinMode(12,INPUT); //- Rudder in
pinMode(13,INPUT); //- throttle in
(Note that I'm using RADIO_TYPE 0, so I have no code in the RADIO_TYPE 1 sections).
Below is a video from my shop of the rudder motion, both in MANUAL mode (straight from the radio) and in SERVO_TEST mode (radio read by the ArduPilot and Passed through untouched).
From BotJunkie: "Last week, one of the Fire Scouts currently undergoing testing aboard the USS McInerney managed a real drug bust after noticing what turned out to be a “go fast” drug boat on radar. The Fire Scout shadowed the boat for 3 hours, and after it rendezvoused with a fishing boat, the Coast Guard moved in and nabbed the baddies.
...
No matter how cool and useful it might be, the Fire Scout program for the Army is still canceled. Sad face. But, it looks like it might at least have a future in the Navy."
(pic also from BotJunkie)
BBC video here. (Sorry, but they don't allow embedding. Ugh.)
Even got the transition to and from horizontal flight going nicely! The company is here (based in Texas). No info yet on pricing and availability.
Looks like a great UAV platform, with all the VTOL advantages of a quad with a lot better endurance for horizontal flight.
Jordi and I will be at the FIRST Robotics National Championships at the Georgia Dome in Atlanta this Thursday, running a planning session for a new FIRST Indoor Aerial Robotics competition (we'll be demoing blimps and quadcopters). If you're going to be there, give us a shout out in the comments and I'll give you the details of the meeting place.
And then on Friday afternoon and all day Saturday, we'll be in Boulder, Colorado for the Sparkfun Autonomous Vehicle Competition. We'll be joining a bunch of other DIY Drones regulars, including the UAV DevBoard team (including the great Bill Premerlani), Doug Weibel, Tim Trueman, Ryan Beall, Pete Hollands, Ben Levitt, Adam Barrow and others. So if you're in the Denver/Boulder area, come to Sparkfun on Saturday and hang out with us!
