After the issues with the previous waypoints, I decided to go for a rectangular path:
This should hopefully be easier to see. I have added a “DO_JUMP” point to the flight plan. This should cause the UAV to return back to waypoint 1 after finishing the path, instead of hovering by the final point. I had closed the software between creating this flight plan+writing it to the UAV, and taking this screenshot. Therefore I had to reload the plan from the UAV. After verifying the flight plan with my supervisor, we tried to write it to the UAV again but encountered an error. As it turns out, a flight plan cannot be written unless a home point is specified. This seems odd, as I was of the impression that the home point is overwritten as being the launch point once the UAV is powered on. It would be interesting to test which home it actually is. According to my supervisor, flight plans can also have issues if a “dummy” waypoint is now added after the DO_JUMP. What is interesting is that if the home co-ordinates are blank, the above pictured flight plan displays as this:
If you then click on the map (thus adding another waypoint), the following happens:
This new waypoint (6) does not seem to have been added to the path, as displayed by the joining lines. Mission Planner still throws an error for this flight plan due to not having any home co-ordinates provided. If I then add home point co-ordinates at this point, the following happens:
I am unsure as to what causes this behavior. However, since the odd behaviors seem to occur when no home co-ordinates are set and the software disallows the writing of a flight plan without having home co-ordinates set, it isn’t a real issue.
While creating these flight plans, I noticed that some of the yellow lines between points are solid, while others are dotted. I tried to look up why this is, but cannot find a definite answer. It seems to only occur on the last few points in a flight plan. Some people believe it to be a bug (http://ardupilot.com/forum/viewtopic.php?t=9889&p=23990), while others think that it represents a line that doesn’t have a true waypoint at the end (http://diydrones.com/forum/topics/flight-plan-yellow-lines), i.e. just returning to home. Dotted lines were seen on my previously tested flight plan, and the UAV did not appear to fly them (as it was not set to return to home or the first point again after finishing the plan). I will attempt to note what the UAV does with them with the new rectangular flight plan (the first screenshot in this post).
We went outside to test the UAV today (verifying that we had the options to both run the flight plan and to return to home on the controller). We have re-arranged the top of the UAV to ensure that we can see the flashing lights on the ArduPilot. Previously, we could not see them and so could not tell if we had a GPS fix (indicated by a solid blue light, the light blinks while trying to get a fix).
We also had an attempt at persuading the UAV to communicate with my laptop via the 433MHz transceivers so that we could get live data, but for what ever reason my laptop could not detect the COM port.
Once we went outside and without verifying that the UAV had a GPs fix, we attempted to loiter (e.g. hold GPS position and height). However, the UAV seemed to just drift around in the wind with no attempts to hold position.
In the past we had changed a variable to make the UAV capable of arming without having a GPS fix to make indoor testing easier. We decided that we should reengage this variable for these outdoor flights, so that we don’t accidentally fly without a good GPS fix. We could not remember which variable we had changed, but found that the ARMING_CHECK variable sounded about right. It has the following options:
0:Disabled 1:Enabled -3:Skip Baro -5:Skip Compass -9:Skip GPS -17:Skip INS -33:Skip Parameters -65:Skip RC 127:Skip Voltage
This variable was at the time set to 127. We are not sure what exactly this was doing, as the description suggests that this would just be skipping voltage checks upon arming. Given the large range of the values, it seems that they could perhaps be added together when more than one option is desired. However, having this set to 127 seemed to be causing us 0 issues with arming without a GPS fix. It is possible that as “Enabled” is 1 and “Disabled” is 0, having just the value of 127 meant that the option was not infact enabled, even though we had selected a value for it. This would explain the lack of GPS fix checking. We set the variable to 1 before going for this flight.
So, in this case, the UAV flew and drifted. We landed the UAV and found that it did not infact have a GPS fix, which should explain the drifting. We waited until we had a solid blue light visible before flying again. Interested to see what the UAV thought it was doing when it did not have a GPS fix, I decided to check the flight logs. The route the UAV took can be seen here:
It seems that the UAV knew where it was going, as this path matches what was seen. It is quite interesting to look at the flight mode logs:
The barometric altitude can be seen here, to illustrate that the UAV was indeed flying. What is interesting is that the UAV has registered that we are trying to fly without having a GPS fix, yet flew anyway. It seems bizarre that it would just add a tag in the logs declaring this (even using the word failsafe), and then fly anyway. I suppose that it would be dangerous if the UAV was to cut out upon losing GPS in flight, and it’s possible that the UAV had actually managed to get a short-term fix while arming before losing it in flight. The UAV was receiving the stabilise command (instead of the intended loiter), which would explain the drifting. We will need to verify if this was down to user error, or if the modes had not written to the controller correctly.
We decided to do another flight after ensuring that we had a GPS fix. The UAV still drifted when being told to loiter (or as it turns out, stabilise) (albeit in a different direction this time):
It is interesting that the quality of the map to have returned to it’s previous levels. I was looking at the map options available on the flight planner map, and changed it without noting what it had previously been set as. I set it to GoogleSatelliteMap, as this one sounded about right. There was no noticeable difference in the quality seen on the flight planner map. It is possible however that the option selected here has some bearing on the map used for flight logs analysis, and that I had accidentally changed it in some detrimental way.
Looking at the commands that the UAV was receiving, again it was receiving stabilise instead of loiter:
There are also no GPS fix error, and so it really makes no sense to me that it would behave as it did. Some investigation will likely be needed in to this problem. Bringing the UAV down from this flight however, it landed a bit hard. One of the propeller arms twisted during landing:
No permanent damage appears to have been taken. The box holding the propeller will simply need to be rotated back to the correct position and re-glued. This propeller is one that has taken heavy damage previously from a collision with a power cable. It is possible that this mostly dislodged the propeller stand, and this rough landing finished the job. This put an end to our flight, and so we are still unable to verify if the UAV is following flight plans correctly. We will need to verify what is happening with commands before the next flight.
Be First to Comment