IMACS Revamp Project Proposal

Owned by Mihir Gupta (Unlicensed)
Last updated: 2023-05-14
3 min read

Why is a revamp required?

Integration of the IMACS system proved to be very difficult. The IMACS system felt like a black box as the development team could only turn on the RFD 900’s and see the output of the system from the GUI. When the GUI wasn’t displaying telemetry information it was hard to pinpoint where the issue was coming from. Debugging these issues required a lot of digging through the code to identify the issue and resolve it.

 

In terms of the IMACS GUI the chosen framework (PyQt5) was not the best tool to use. The list below states the issues the GUI development team had with PyQt5.

  1. Poor documentation. It was very difficult to find information on different widgets for PyQt5 (Many developers had to resort to the Qt documentation to get more information).

  2. Issues with updating the map on the GUI. There was a lack of offline maps to choose from in Python and there was a lot of latency when updating the drone marker (around 2-5 seconds). Furthermore, running the GUI with an offline map was weird since it required two python files to run separately.

  3. It was difficult to set up the GUI and install the required dependencies on a different computer.

Revamped Plan

The suggested approach to the IMACS system is to make use of TCP/UDP sockets to take information from the RFD 900’s and have the GUI read the info from the TCP/UDP sockets. Below is a diagram of the proposed architecture. Moreover, the members assigned to the IMACS task will work together to build both the backend (process RFD 900 data and port that into sockets) and the frontend (IMACS GUI).

Benefits of Revamped Plan

  • Data telemetry code is modularized. Helps the development team incrementally develop and test the code so that integration with GUI is easier. It also makes debugging the system a lot easier. We can use tools (e.g. tcpdump) to see the information being sent from the socket.

  • Any language can be used for the data telemetry and GUI code since most languages are able to write and read to sockets. This allows for a lot of flexibility for the tools used in creating IMACS. This allows us to focus on using the right tools for data telemetry and GUI.

  • Having members work on both the backend and the frontend gives them more knowledge when debugging the system. Before it was hard to debug the system because we weren’t sure if it was a problem on the data telemetry side or GUI side and it required us to be constantly pinging both teams.

Note: Ground Control - UBC Uncrewed Aircraft Systems (ubcuas.com) UBC UAS has a product similar to IMACS but implements the socket approach I am proposing. If their product is successful, it could tell us if we are on the right track.

I think the goal for the 2023-2024 competition is to have IMACS run in parallel along with Ardupilot. I think having IMACS be a full replacement for Ardupilot with only 1 year of development time is an unfeasible goal.

 

Items to discuss

  1. Should we use TCP or UDP sockets. How does the GUI know when to read from the sockets? More investigation will need to be done on how we want to read from sockets.

  2. What languages and frameworks we want to use for data telemetry and GUI.

  3. Do we want to use parts of the existing architecture. If so which parts?

  4. Is there a way to package it easily so that it can be distributed and set up automagically/without any need for debugging/experience with the system?

  5. Would it be possible to support MAVlink as well as custom messages?

    1. MAVLink Developer Guide | MAVLink Guide

Â