Waypoint Tests

The plan today was to test two things: altitude control and curved vs. straight flight paths. I planned four sets of waypoints:

• Vertical ascent at point A in steps of 5m, with 5s delays in between each waypoint, up to a height of 20m
• Vertical ascent at point A in steps of 5m, with no delays, up to a height of 20m
• Curved flight from B to C, pointing at POI
• Straight flyover from B to C, pointing at POI

The temperature was 30C and the wind was moderate and steady: 16 knots, SE. It was mostly sunny.

Flight 1 - Vertical ascent with delays @ A

Start 14:47:48
I started the 'copter a little south of location B, while I stood slightly further to the south. I performed the pre-flight checks, started the motors and sent it up a few meters, then engaged waypoint mode. As it moved to point A, I also moved to the 'me' location. It ascended in altitude steps but seemed to take a long time to do each step. Brought it down nicely.
End 14:49:53

I decided not to perform the vertical ascent without delays until I could ascertain whether the first programmed flight corresponded well to the measured flight, from the logs.

Flight 2 - Curved flight path B -> C

Start 14:59:34
I was at the 'me' location and the 'copter was at point A. I performed the pre-flight checks, started the motors and sent it up a few meters, then engaged waypoint mode. It moved smoothly to B, but the next waypoint steps were not smooth, and it took a long time to move over the flight path, even with no delays set. Not as bad as with 7 propellers but still need to come up with better Radius/PID settings. I aborted the flight about 20m East of point B and brought it down safely.
End 15:02:35

Flight 3 - Straight flyover B->C

Start 15:09:03
I was at the 'me' location and the 'copter was at point A. I performed the pre-flight checks, started the motors and sent it up a few meters, then engaged waypoint mode. It moved smoothly to B, but kept ascending once it was there, up to an estimated height of 50 meters. I realised I had the throttle at 55% instead of 50% so it just went up-and-up, until I realised, reduced the throttle, and brought it down. It was supposed to fly over at 15m altitude, but it did not begin its waypoint until about 5m. As it was so close to the ground, I set it to PH/AH and brought it down instead.  I need to check logs to find out how high it thought it was when it started to execute the waypoint.
End 15:10:55

Results
The first interesting result is that the 'copter does not appear to log until waypoint mode is engaged. Thus some flight logs, such as the first flight, do not have data points until 9m altitude, the point at which I engaged the waypoint mode.

Flight 1
It's hard to measure the time spent at each altitude as the 'copter doesn't seem to be able to stay exactly at the right altitude. It also didn't reach 30m. It's possible that because I have 'radius' set to 10m, the 'copter thinks that when I tell it to climb to 15m or 20m, and it is already at 10m, it thinks it is close enough, and doesn't bother to climb until the 25m waypoint kicks in. Then it ascends to 25m, reads the 30m waypoint, but thinks it's close enough, so just hovers for 15 seconds. For some reason it then descends to 20m and pauses there. So 5m increments may simply be too fine for the 'copter to manage.

One might also guess from the birds-eye projection of this flight that the x,y position r.m.s. is around 8m. But taking the standard deviation of the logged latitudes and longitudes shows that the r.m.s. is more like 2.3m, which is a good measurement to have made. This would be excellent to measure again on a cool, still day.

I also made a histogram of the position offsets in latitude and longitude. The average of the longitude position offsets was 0.3m (east) and the average of the latitude position offsets was 1.4m (north). This suggests that the wind was probably blowing more from the south at altitude, pushing the 'copter slightly to the north.

Flight 2
Looking at the flight log, the 'copter took about 25 seconds to 'find' a waypoint to sufficient accuracy, which was usually between 5-10m away from the right position. The strong breeze no doubt made it more difficult - it would be informative to run the same test on a very still day. It may also be useful to set the allowable 'Radius' to 20m, to see if the 'copter spends less time trying to get to the waypoint, even if it doesn't get the waypoint exactly right.

Flight 3
There is a "TargetDistance" column in the GPX file, which I think refers to the distance away from the next waypoint. From the previous flights I couldn't tell if it took into account altitude, but from this flightlog, one can see the TargetDistance staying low, even as the altitude significantly deviates from the expected waypoint. This is another argument in favour of performing straight flyovers, since if we keep the elevation steady, then we correctly log how far away the next target is.

The point at which the TargetDistance suddenly increases is when the 'copter reaches the radius of Waypoint B, and then decides it needs to move to Waypoint C. This is at just 8m altitude, and the 'copter was still descending, and when the 'copter does a course-correction it usually does drop slightly as it changes power in its motors. The elevation it was supposed to use was 15m, but 8m is only 7m less than this, and the allowed radius was 10m, so actually this scary-looking behaviour was fairly reasonable.

In terms of getting more reliable altitude behaviour, I need to read up the documentation, and get a bit better at judging heights rather than relying entirely on autopilot. The 'copter tripled its height before I decided to bring it down again; it should have been clear after 20 seconds that something was wrong. It's also probably a good idea to test the straight flyover at a higher altitude than 15m if I continue to use a radius of 10m for the waypoints, since that gives us only a minimum of 5m clearance above the ground. 20-30m would be safer, and more similar to actual field conditions of 100m.

Overall
I thought from a previous comparison of the logs that the KML files contain a log every second, and that the GPX files contain a log every 2.5 seconds. However I found this time that there was some jitter around these numbers. I can't tell which one is 'off' because the GPX files only contain the time to the nearest second, and the KML files have no time logged at all. It's hard to get sub-second accuracy using any other equipment such as a stopwatch, due to human reaction time. What might be a good idea is to set the KML logging to say, 10 seconds, and the GPX logging to 1 second, and see if I get a good GPX log every second.

Overall, the camera tilt seemed too high - the servo adjustments I made appear to have gone too far. I need to set up a waypoint on the ground, and go to several different altitudes at the same point, and see if the camera still points in the correct direction. If not, I should adjust the servo settings again. It might be possible to do this in the lab just by picking it up and tilting it - something to hold it in place would be useful.

One thing that would make flight set-up easier would be to have some device to find out where the POI is. The car GPS was too low-accuracy. Maybe I should simply have a first-flight program which simply flies to the POI to be used for the rest of the flights.

Further Flights

• On a still day:
• Measure r.m.s. position accuracy by hovering or moving between vertical waypoints;
• Run the curved flight path with lower and higher radii;
• On any day:
• Mess with the altitude controls and see if I can get 5m precision;
• Get the servo mount settings correct by ascending to a series of known altitudes and check the pointing via a video camera;
• Run the straight flyover with waypoints at at least a height of (Radius + 10) m to allow for the 'copter's uncertainty in altitude;
• Change the logging settings:
• Reduce the KML to intermittent and see if GPX logging is more frequent;
• Reduce both to prime intervals (e.g. 3, 5) so that they don't overlap frequently and see if they are more consistent.

GPS Logging

Having enabled the POI functionality, I wanted to properly log the GPS co-ordinates of the 'copter. I had another demonstration to perform to another group of NYSF students, so I figured I would try to get logging working and see if I could record anything. I didn't have time to do much before the demo at 11, so I just quickly popped it up in the air for them and then back down again:

The flight was between 11.08 and 11.09 am WST in the courtyard, and it was just a tad windier than yesterday. Unfortunately the POI was still too far to the south, so I was again not directly pointing at the group of kids!

After this I researched a bit more about how to log the GPS. I found that the MX-20 transmitter can perform logging, but more of the telemetry, like temperatures, control stick settings etc. It also produces very large files which have to be opened using a proprietary program from Graupner. I tested it out and it wasn't very user-friendly, mostly in German and with many dialogues and help boxes empty or containing filler text. As it can only log what it is sent by the 'copter, I realised it probably wouldn't help us with the main effort, to accurately measure the 'copter's position, any more than just recording directly. In the interests of completeness though, here is how you set up some auto-logging that begins when your flight starts:

• Go to 'control switches'
• Move the throttle joystick
• Set the threshold to just past off, e.g. -88%
• Go to 'timers'
• Set that control switch as starting the 'Flt' (flight) time

If there's a micro-SD card in the transmitter, this will start logging when you bring the throttle up after starting the engines. Unfortunately it currently won't stop until you turn the transmitter off.

To log on the 'copter, it's a lot easier - just put a micro-SD card in the Navi-Ctrl board. 2GB is more than enough space as it generates very small files. It creates both a GPX file and a KML file: The KML file has  simple entries like

+115.8894829,-32.0038644, 1.789

showing the longitude, latitude and altitude, and it logs these every second.

The GPX files show a lot more data: 34 different data objects like roll angle and heading, and more information on the 'copter status, like available motor power and the motor temperatures. These points are logged every 2.5 seconds.

Now that I had a way of logging the position of the 'copter, I wanted to try a flight path that resembled the a possible flight plan for the MWA tile measurement: a curved flight with varying altitude, so as to eliminate the effect of taking a straight cut through a spherical beam. I came up with a simple series of waypoints using a sin curve, since I didn't need to be exact, just test the functionality.

When we were in the field, I uploaded the POI as the first waypoint, as I wanted to fly the 'copter over to its exact start position and land it there. I left the POI in the file, a mistake!

Flight start 16:33

I started the 'copter in CF mode and took it to 10m, then engaged 'come home' to send it to the POI. It reached it, but then behaviour I had not accounted for kicked in. Hovering directly over the POI, the 'copter was straining to tilt the camera mount at the point directly beneath it, and was slewing around in a clockwise arc trying to get to an impossible angle. The landing gear was also disrupting the servos on the camera mount. I immediately put it in PH/AH and began to land it, but it was difficult as the 'copter continued to slew around. I had seen warnings about this on the forums, but I didn't realise that it would be so difficult to control. After a few clockwise turns it lost a propeller! I brought it down and we managed to find both the prop and the washer, but lost the nut holding the propeller on. I realised afterward that I should have turned off CF mode, as then the 'copter would not have been trying to point at the POI, since that functionality is then disabled.

Flight end 16:34

Flight start 16:53

Having lost one propeller, I still hoped to see if the curved waypoints would work, so we brought the 'copter back to around 10m east of WP2, and deleted WP1 from the log. I brought it up and started the waypoints, but the 'copter rose poorly and slewed around, spending a lot of time trying to get to each waypoint even though I had told it to spend zero seconds at each one. After a minute I brought it down again, as it was clear it was not going to be a good test of the functionality.

Flight end 16:34

I looked at the logs and they were difficult to understand at-a-glance. I tried putting them into Google Earth but it runs very slowly on my computer and GE's handling of altitude is terrible. Then I found this excellent little online app: http://www.gpsvisualizer.com/ which can produce a nice png of each flight, or transform it into files for use in other programs.

Clockwise spirals while hovering directly over POI.

Poorly-executed curved flight path - missing a propeller.

Lessons:

• Never hover directly over a POI; the 'copter becomes extremely erratic as it tries to get the camera pointing directly at it. If you do accidentally end up doing this, turn off CF mode, turn on PH/AH and land immediately, then reprogram.
• Flying manually is ok with seven propellers, and it can execute simple waypoints, but it can't make fine adjustments well enough to perform a densely-waypointed flight path.
• The propellers have a tendency to come loose when you yaw clockwise - probably due to the unreversed threads on half of the motors.

Carefree and Point-of-Interest

After some research online, I found the issue that was preventing our 'copter from yawing to point and tilt the camera at a point-of-interest while executing waypoints. According to the mikrokopter website, Carefree mode must be enabled to use POI mode. This is a safety feature, because after you have finished executing a series of waypoints, it is tricky to see the orientation of the 'copter. In Carefree mode, the 'copter knows where you are when you started it up, and it works out the angle between you and it. It then assigns whichever direction lies away from you as its nose, so that if you tilt it right, it moves (apparently to you) right, left left, and so on. Thus if it is far away at the end of the execution, or something goes wrong in the meantime, you can simply tilt the control joystick toward you, and it will fly back toward you, without worrying about where its real 'nose' is pointing.

As it happened, I had a convenient moment to test this functionality, as a group of National Youth Science Forum students are visiting Curtin / ICRAR, and I've been asked to demonstrate the 'copter to them. They will be visiting the courtyard behind my building, so I had a quick look and saw a convenient grassy space they could sit in, while I used the larger area to fly.

I readied the transmitter and 'copter and programmed in the POI, -31.99447 lat, 115.88896 long. I pointed it toward the POI to start with, so that it was reversed controls compared to how one usually flies. I wasn't sure what would happen if I started with Carefree enabled, so I throttled up with it disabled. However I found the reversed controls so confusing that I immediately landed again, and decided to try with Carefree enabled from the start. I re-uploaded the POI, turned on the camera, and switched the CF switch on the transmitter to the 'on' position. This time the controls were not reversed, although it was very strange to be flying with all of the reflective lights and tape no longer relevant. I brought up the 'copter and took it a bit toward the crowd - who unfortunately were sitting in the shade, approximately where the green arrow is, rather than at the POI I expected! (show picture) After a minute or so of hovering, and gently moving it around, I took the 'copter back to its landing point, brought it down and took questions from the students. When we looked at the video, the POI tilt had worked well - although it would have been nice to have the people centred in the image.

Lessons

1. It's a good idea to start with CF enabled if you do not have the nose facing away - and it works absolutely fine.
2. Enabling CF does enable POI functionality.