Making a drone flying a defined route is a standard use case and was not part of the planned implementation work.
The image recognition part could be kept simple or made higly elaborated. For the sketched use case (recognise specific signs) this was as secondary problem.
The primary problem was sending the images/image parts/custom data over the narrow band radio to the base station -> initiate helping actions based on up to date information.
The image/data sending could easily have been "solved" by buying COTS expensive radio hardware, also bigger drones, better cameras, ... . But then it would become inaccessible through the costs for many use cases.
This was the same cost/benefit calculation that the searchwing (uni augsburg) project had at the start -> have a cheap RC plane with cheap radios, let it collect data and deliver it to the ground station - as fast as possible for rescue purposes.
I worked with the searchwing project and wrote the software also for that use case.
Sending images over mavlink radio in general is a supported use case in the mavlink protocol. Looking at it more specifically (hardware) it often is not supported at all or in the needed way. At time of implementing the solution, the cheap and lightweight pixracer did not support the mavlink camera protocol but the pixhawk should have done. To keep it cheap and lightweight the pixracer had to be supported.
Searching the internet quite long no working solution was found. I found two projects that touched the problem (not working) and also got contact to one of the coworkers in one of the problem -> some inspiration was found.
My biggest problem when working on the implementation was quite unexpected. I had quite high error rates and this reflects in the image transmission tool becoming also a radio transmission quality testing tool. And in the beginning this was really munching time as I couldn't believe the error rates -> extra work for searching the error cause without finding :/
I finished the image transmission implementation in June 2021, way behind the deadline for the NXP https://www.hovergames.com/.
Find the implmentation at https://gitlab.com/rm/mavmit.
The time spent for implementing mavmit was a multiple of the estimated time but also included coordination with searchwing, manual image classification for training, ... .
Additional Note on hovergames
The parcels from nxp arrived finally - had some delay through customs handling - now have a EORI number.
The separate sending and handling by parcel service caused quite some amount of additional fees, besides the noticeable loss of time.
I wish NXP would have sent the stuff to a EU distributor and that could have sent the complete packages. The only one happy with this separate sending approach surely was the parcel service.
Buying these/comparable parts separately on the market might have been cheaper as the cost addon through the (inefficient) parcel service services was quite hefty.
Comments