Here’s a screen shot from some testing with our new automated imagery processing code running on Raspberry Pi with PiCam for finding Outback Joe.
Stephen has been working really hard on this while the rest of the team focussed on the OctoPorter and Kraken; now it’s time to give these algorithms a work out!
We conducted a 25 minute imagery collection mission against our target set and collected
5GB of data. The processing takes place in the RaspberryPi on board the aircraft to reduce latency and the requirement for high bandwidth data links. We get smaller thumbnails from the camera down to the ground station to see what the aircraft is collecting and what the Pi is ‘thinking’. The revised code reliably spotted our targets from this mission, but it ‘found’ too many false ones too. We can work on that with more training data sets.
Our geolocation of the targets is down to about 50 metres; that’s not accurate enough for the Porter to land on yet, so we have some more refinement to do. We think the key to that lies in improving our understanding of the time stamps.
What an amazing weekend! The Kraken flew two long missions; the second of which was 1 hour and 28 minutes. This is pretty amazing for a purely electric aircraft.
The OctoPorter flew twice on Sunday, with both missions being 1 hour missions. It was a great sight to see them both tracking autonomously around their orbits around CMAC at the same time; with sensible height deconfliction of course.
With the D3 flying done, we now need to get on with testing the new Raspberry PiCam based imaging capability that Stephen has been working on very hard this year. There is also some integration and testing of the data feed for the ‘Dynamic No Fly Zone’ portion of the 2018 competition to be done. Onward and upward!
Just for fun, here is a video of the flying this weekend.
Life at the cutting edge can be bumpy! We were testing a new method of using small flight controllers in each wing to improve data management, give us the ability to monitor the ESCs in flight and reduce wiring. We have also fitted new BLHeli ESCs to the vertical lift motors, which give us the ability to output the monitoring data that we need.
The OctoPorter flew well in the first two flights of the day in very low altitude hovers while we checked loiter and basic hovering. We pushed it up to 5 meters for our third test hover of the day.
This picture speaks for itself!
Our follow up investigation shows that the ESCs clearly ceased functioning properly at almost the same exact time, but we’re still trying to figure out why. Neither of them is working now, and they both show the same symptom of not booting and just getting really hot, focussed on the Microprocessor.
A new starboard wing is required and another look at those ESCs. The 5hrs for the next UAV Challenge deliverable will have to wait for now…
We’re very excited that our second deliverable for the 2018 UAV Challenge has been submitted. Just a few stressful weeks until we receive our Go/No-Go from the organisers.
In the mean time, we have got lots of work to do. In particular we need to make some technological improvements to our OctoPorter to improve it’s reliability and refine the build of the Kraken.
We’ve also got work to do on our autonomous target location based on our new Raspberry Pi based automated image recognition software and development of the ArduPilot code to deal with Dynamic No Fly Zones. Watch this space for updates!
We’ll keep you updated as we go. Thank you very much to our family, friends and supporters! Don’t forget that we really appreciate donations to our Patreon account to help us fund our project. We put all of our work straight back into the ArduPilot community and make our autonomous image recognition software available to all; please consider contributing if you get use or pleasure out of this like we do!
Our Patreon account is here: https://www.patreon.com/canberrauav
Yesterday we enjoyed a beautiful Canberra morning flying the OctoPorter. We did thorough ground checks and some manual take-off / landing cycles before a full auto mission. The landing from the auto-mission is in this video; what an amazing sight and sound! We are excited to have the opportunity to make a number of software and hardware upgrades to the aircraft to make it more reliable and capable for the UAV Challenge this year.
CanberraUAV prides itself in being a responsible civilian not-for-profit organisation; a key part of this is conducting our flying activities in a safe manner. We understand the responsibility that we have as members of the aviation community; in the spirit of that community it is important that we talk about the safety aspects of our hobby. We aborted a mission on Sunday before it had even started; here’s why
A number of flight safety ‘human factors’ began to line-up during our usual Sunday flying period at our home field. Time became compressed due to availability of key members. Due to some technical development activity, the mission was delayed until around 1130 and a significant ‘rush’ to get airborne was felt within a final 20 minute availability window. By this time heat was fairly extreme on the field (37℃+).
Stephen working on the Raspberry PiCam
A number of failures were experienced whilst setting up the bungee cord which was then modified ‘on the fly’ and was to be connected to a bungee launch mechanism that had not been tested on a live launch. Our ‘spider senses’ told us that we were about to push our luck. Only a minute or two until the launch, the group ‘called it’ and cancelled the mission before any launches were attempted.
It is good practice to maintain perspective on the situation when you fly. In this case it really wasn’t crucial to conduct that mission at that time and too many things hadn’t gone quite as planned in the preparation. Flight Safety experts talk about the holes lining up in the ‘swiss cheese’; those ‘holes’ are all individual events. When those ‘holes’ line up, or happen together, that can amount to enough issues to cause an accident. At the bleeding edge of open source UAV development accidents do sometimes happen, but we don’t just accept that crashing is ‘normal’ when we don’t need to. In this case a rushed launch could have caused a heavily damaged airframe. That would have cost money and put back imagery data collection efforts causing longer term issues for our UAV Challenge project. This way, the Opterra lives to collect another day!