AttoPilot comes with two desktop programs, a full-featured ground station and a basic KML-to-TXT converter.
Before I get into the specifics, I'll give some quick impressions.
The Ground Station is intended to be used while the aircraft is in the air or to replay a saved flight file. It can display real-time telemetry data if you have a radio modem hooked up to AttoPilot, and can send commands back to AttoPilot if that radio modem is 2-way. It's a nicely done professional piece of software and seems to cover all the bases. Two thumbs up.
The KML-to-TXT converter is a bit of a kludge, compensating for the fact that AttoPilot doesn't have a native way to input waypoints. Instead, it recommends using Google Earth Plus to point-and-click waypoints, exporting them as a KML file that the supplied utility can covert into a form that AttoPilot can use. Unfortunately, this process, which is pretty cumbersome at the best of times, is now also impossible, since Google has stopped selling Google Earth Plus. I've asked Dean for advice on what people should do about that, but haven't heard back yet.
[UPDATE: Dean says that the free Google Earth 5 now includes the KML export feature. So ignore the Google Earth Plus reference in AttoPilot instructions, which I assume will soon be updated]
There is also, to my mind, a missing piece of software, which is a setup utility. In the absence of that, the main way you adjust AttoPilot for your plane is by editing a text file that is stored on the on-board SD card. That file is pretty scary looking (and we should know, since we currently make people do something similar with ArduPilot, although we'll be releasing a setup utility that avoids that soon), and consists of hundreds of lines that look like this:
I assume that in later versions of AttoPilot, there will be some program that helps you enter those values. In the meantime, however, it's a relatively daunting process of trial-and-error, reading the manual and tweaking a supplied generic file. I haven't flown a plane with it yet, so I don't know how well the generic file will work for my target platform, an EasyGliderPro, but I'll update this as I learn more.
For the rest of the review,. I'm going to focus mostly on the Ground Station software, which is the most polished part of the package. Here's the main screen, showing the playback of a flight:
The menu items give you the following dialog boxes.
Settings:
When you click "Read from AttoPilot", the following boxes are added to the interface:
If you have a 2-way radio modem, those boxes allow you to send in-flight commands to AttoPilot. These are the available commands:
If you click on "Show PID", you get a new window that creates graphs of key values over time:
The "KML Utilities" launch the aforementioned KML-to-TXT file converter. You can convert both ways:
All in all, an impressive piece of software. My hope is that in the next version of AttoPilot, the waypoint entry and setup process will display an equal level of polish.
Just a point of clarification on the SET. Dean is absolutely right that there are only 106 parameters. But I was referring to the lines in the document, of which there are indeed more than 300 (many of which are instructional comments, between and below parameters).
I wouldn't be surprised if Dean makes available custom SET files for common airframe in the future, which will help avoid people having to mess with this file too much.
FWIW, that's what we're doing with ArduPilot 2.2. We have a setup utility, and it will let you load airframe files. That's what Paparazzi does, too.
The "PID" window shows 5 key processes for stabilization and navigation. In the non-RC modes you can immediately (and intuitively) gauge if the PID gains are too high, too low, or just about right. I'll soon publish a set of narrated videos of example flights with poor tuning and good tuning.
Regarding there being "hundreds" of lines in SET, it is 106 to be exact. Of those, 3 relate to elevon mixing setup, 7 for servo reversing, about 40 for loiter duration and radius choices and payload management for triggers, and related items. Now we are down to 56 left to explain. For stabilization there are 7 P and 7 D gains (I gain is set automatically based on P, and the Ki reset times are hard coded into Atto). Of the remaining 42 (or so) SET values, they have to do with navigation tuning. Yes, navigation has its own PI and D type gains, max rates, max pitch and roll angles, and widths of proportional bands. To allow Atto to fly things from 8 ounce MAVs up to 30+ pound UAVs all of these parameters need to be accesible to the end user. Each item in SET was added based on extensive testing and a demonstrated requirement to make flight even more robust.
>> The generic SET file on Chris's SD card has very good navigation gains for normal RC craft<<
90% of the stabilization gain tuning is no more daunting than simple P gain for pitch and roll response, not much different than tuning for an FMA CoPilot. After P gains are decent, add a smidge of D gain to further reduce overshoot and dampen oscillation.
There are also about 6 parameters related to failsafes for mAh cutoff of battery, and a distance greater than which Atto 100% locks out the RC Tx until certain conditions are satisfied. You also have exponential gains on pitch and roll.
So, this is how you get to 106 parameters. About 12 of them relate to getting good flight performance, and 94 of them relate to everything else plus flight safety margin and payload management. It has been about 1 year since I relaized "Oh crap, stable autonomous flight is BORING... I need to start workking on payload management, better and unique navigation, and failsafes".
Correct - large areas can be cached... no need for internet connection in the field. Moving map works right now if you have modems, and the Atto GCS copies the telem stream out to another COM port, which can be read by an inexpensive app called GooPs. GooPs feeds a live icon in Google Earth. See my demo video of this here: http://www.vimeo.com/2477624
Soon to come out: elimination of GooPs and the GCS will directly communicate with Google Earth for moving map, as well as a host of utilities to help edit the SET parameters and mission planning. Mission planning is a LOT more than just coordinates. It is altitude at each waypoint, which Google Earth doesn't let you set different from one waypoint to the next, instead you have to do a simple hand-edit in the KML-->WP.txt converter. There are also airspeeds at each waypoint, and 6 active scripting data fields. the documentation to control all this is present on the files on micro-SD that comes with Atto, but the level of easy use is moderate to low.
Waypoint coordinate planning with Google Earth is pretty easy, and at least there are no manual entering of coordinates. You just open a new path, click where you want waypoints, then export the path to a .kml somewhere on your PC. Use the kml-->WP.txt converter, and you have a complete WP.txt ready to load to the micro-SD card. In fact, you could put hundreds of WP.txt on the SD card by tacking something to the name like WP_Square1.txt, so that AttoPilot doesn't consider it active.
There is also the powerful (and simple) feature of marking a WP.txt as a relative template so that it can be flown anywhere on Earth, not just the exact coordinates written in it. In fact, many of the flight plans I use for daily development flights are relative templates... because I don't know if I will flying at eactly which one of 4 sites I go to. Doesn't matter... I use a 600x400m rectangle centered on the start location.
So in the end, I'm working with the GCS Apps guys to do all sorts of new stuff, including phasing out the need for Google Earth.
Comments
Is an Attopilot for helicpoters in the works?
I wouldn't be surprised if Dean makes available custom SET files for common airframe in the future, which will help avoid people having to mess with this file too much.
FWIW, that's what we're doing with ArduPilot 2.2. We have a setup utility, and it will let you load airframe files. That's what Paparazzi does, too.
Bit weird if your into flying
I'm not Dead! I am fully alive.
Regarding there being "hundreds" of lines in SET, it is 106 to be exact. Of those, 3 relate to elevon mixing setup, 7 for servo reversing, about 40 for loiter duration and radius choices and payload management for triggers, and related items. Now we are down to 56 left to explain. For stabilization there are 7 P and 7 D gains (I gain is set automatically based on P, and the Ki reset times are hard coded into Atto). Of the remaining 42 (or so) SET values, they have to do with navigation tuning. Yes, navigation has its own PI and D type gains, max rates, max pitch and roll angles, and widths of proportional bands. To allow Atto to fly things from 8 ounce MAVs up to 30+ pound UAVs all of these parameters need to be accesible to the end user. Each item in SET was added based on extensive testing and a demonstrated requirement to make flight even more robust.
>> The generic SET file on Chris's SD card has very good navigation gains for normal RC craft<<
90% of the stabilization gain tuning is no more daunting than simple P gain for pitch and roll response, not much different than tuning for an FMA CoPilot. After P gains are decent, add a smidge of D gain to further reduce overshoot and dampen oscillation.
There are also about 6 parameters related to failsafes for mAh cutoff of battery, and a distance greater than which Atto 100% locks out the RC Tx until certain conditions are satisfied. You also have exponential gains on pitch and roll.
So, this is how you get to 106 parameters. About 12 of them relate to getting good flight performance, and 94 of them relate to everything else plus flight safety margin and payload management. It has been about 1 year since I relaized "Oh crap, stable autonomous flight is BORING... I need to start workking on payload management, better and unique navigation, and failsafes".
Soon to come out: elimination of GooPs and the GCS will directly communicate with Google Earth for moving map, as well as a host of utilities to help edit the SET parameters and mission planning. Mission planning is a LOT more than just coordinates. It is altitude at each waypoint, which Google Earth doesn't let you set different from one waypoint to the next, instead you have to do a simple hand-edit in the KML-->WP.txt converter. There are also airspeeds at each waypoint, and 6 active scripting data fields. the documentation to control all this is present on the files on micro-SD that comes with Atto, but the level of easy use is moderate to low.
Waypoint coordinate planning with Google Earth is pretty easy, and at least there are no manual entering of coordinates. You just open a new path, click where you want waypoints, then export the path to a .kml somewhere on your PC. Use the kml-->WP.txt converter, and you have a complete WP.txt ready to load to the micro-SD card. In fact, you could put hundreds of WP.txt on the SD card by tacking something to the name like WP_Square1.txt, so that AttoPilot doesn't consider it active.
There is also the powerful (and simple) feature of marking a WP.txt as a relative template so that it can be flown anywhere on Earth, not just the exact coordinates written in it. In fact, many of the flight plans I use for daily development flights are relative templates... because I don't know if I will flying at eactly which one of 4 sites I go to. Doesn't matter... I use a 600x400m rectangle centered on the start location.
So in the end, I'm working with the GCS Apps guys to do all sorts of new stuff, including phasing out the need for Google Earth.
Erwin
-
1
-
2
of 2 Next