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.

Waypoint Testing

When we perform the MWA tile beam measurement, I will not be manually controlling the 'copter; instead it will execute a series of pre-planned waypoints. Therefore we need to begin testing the waypointing mechanism. Another trip to Edinburgh Oval is a good start, since we've already surveyed the area and I know that it is large and clear of other people, so if the automated control systems misbehave in any way, I can take immediate steps to regain control with no danger to others.

I started by looking at the Google Maps image of the site, and picked a simple square pattern for the 'copter to execute. I attempted to set a point-of-interest just 10m north of the starting point, so that the 'copter would always be facing us. I borrowed a video camera from Curtin IT services to mount on the 'copter, so that we would be able to see what it saw after the flight. We brought a large bright orange cordon of flags which we could leave in a heap at the POI, so that we could see how much its position varied during the video. We also brought a car GPS which could give us the latitude and longitude of a position, so that we could mark it and see whether it and the 'copter agreed. I was assisted by Brian Crosse and several summer school students: Teresa, Zeus, Kimberley and Luke.

Weather was mostly sunny, 32 C with a very light NE breeze.

First we surveyed all of the waypoints, to make sure that I had selected them correctly from Google Maps, and the 'copter wasn't going to disappear over the horizon or into the trees! Brian and the four students went around each waypoint in turn, and a student stayed at each surveyed position. I put the 'copter in the take-off position, 10m north of my own position.

Flight start 16.04
I switched on the transmitter power, then the 'copter, and then connected it to MK Tool and uploaded the waypoints. I then calibrated the 'copter, then brought it up to about 10m altitude, put it in PH/AH for a few seconds to check everything was working, and then put it into 'come home' mode, which causes it to execute its programmed waypoints.

It moved off smoothly along each waypoint, but I could see that it was not yawing to point the camera mount at the POI, instead continuing to point North throughout. As it went to each waypoint, the relevant student left a shoe in the surveyed position, and moved to stand directly underneath the 'copter as it hovered at the waypoint.

Once it reached WP4, it simply stayed in position - I wasn't sure whether it would come 'home' to its take-off position. I also realised that I did not know its orientation exactly, because it wasn't clear whether it had yawed at all during the way point execution. So I put it in PH/AH, and carefully tilted it side-to-side until I worked out its orientation. The gentle NE wind was pushing the 'copter away from me and toward the trees, so I decided not to attempt to bring it all the way back to its take off point, and instead reduce throttle and land it where it was.
Flight end 16.07

We picked up the 'copter and moved it back to its take-off point. I added a fifth waypoint, the original take-off position, so that it would move back. I checked the video and saw that indeed it was not pointing at the POI, but in the field I didn't know what could be wrong, and decided not to change any of the settings in case that created more problems than it solved!

Flying past Curtin Stadium.

Flight start 16.22
I uploaded all of the waypoints again, throttled up and took it to 10m, put it in PH/AH and then told it to execute the waypoints. Again it flew very smoothly through the waypoints. Each time it arrived at a student, they left a shoe where they were, and moved underneath the new position. After WP4, it came back to the take-off position, and I landed it carefully.
Flight end 16.26

When we looked at the distribution of positions, it was clear that the initial surveying was off by about 10m to the east - so each waypoint executed by the 'copter was 10m to the west of the original marked position. This implies that a car GPS it is only accurate to ~10m and we should keep that in mind for future surveying of waypoints.

On the plus side, the difference between the first pass of waypoints and the second was only about 1m, so the 'copter GPS seems to be much more reliable than the car GPS.

Lessons

• Car GPS is only accurate to ~10m, may not be adequate for waypoint-surveying
• 'Copter GPS is accurate to ~1m and it can reach this in low-wind conditions
• The 'copter does not come 'home' after executing its waypoints - you must also program in a final 'home' position
• Something is not working with the POI functionality, despite apparently enabling the correct options in MK Tool - needs investigation.

Fat Shark Headset

The headset has now arrived, and it should allow us to receive a live view from the 'copter as it flies. Eventually this will help us determine whether the RF comb generator is correctly pointing at the MWA tile beam while we make our measurements. Very experienced pilots use these headsets while actually piloting, but I am very wary of becoming disoriented, particularly in that I would not be sure of my peripheral vision.

Irritatingly, we do not have the correct attachment to charge the battery for the headset; apparently we need to go to Jaycar to buy the right adapter.

Also, the goggles do not receive directly from the 5.8GHz transmitter onboard the 'copter. I suspect this is because they are not in the same format; they appear to be American and are likely using NTSC, while the transmitter appears to be European, and is likely using PAL. This makes using the whole set-up extra-bulky, as we have to carry around the receiver and the enormous lead-acid battery we're currently using to power it, instead of just the goggles, screw-on antenna, and LiPo battery, not to mention connect the goggles to the receiver using a cable instead of just wearing them. This is an extra point of failure and I'm not very happy about it. I've contacted Aerobot, but I'm still waiting for a reply about the receiver battery.

The set-up may be due to broadcasting regulations on amateur transmissions at 5.8GHz. So the signal is too weak to receive from the Fat Shark headset. But since the picture is so bad, I can't tell whether it's the transmitter, receiver, or the headset.