Software Architecture Overview
We plan to build our server on the cloud to make our software ready for production as well as scalability. All the delivery requests would be sent to our centralized server. The server processes all requests and schedules them accordingly. The AWS IoT will receive the request and establish a connection with the drones to command the drones to make the delivery and receive the delivery status from the drone.
Also, we utilize remote deployment to make our system production-ready. With AWS Greengrass, we can deploy our new software to the cloud, and all of our drones can automatically receive the update when it is connected to the internet.
We have completed setting up the AWS Greengrass for cloud deployment, and we are working on the software for the drone. We will start building the server when we have the software for the drone working locally for predefined location delivery.
Drone Software’s ROS Nodes structure
Behavior Tree for High Level Planning
Multiple machines network setup for ROS communication
We set up our computers to be able to run ROS on multiple machines so that our drone only needs to run the autonomy nodes and roscore, while our personal computer will run the visualization and rqt nodes for remote control purpose. We created an automatic script for the setup so that my teammates can run the setup easily with one command.
Software Development Environment
We set up a Github repo in a professional setting for our team. There are several procedures to ensure the code quality of our team during the development.
– Locally, on each team member’s computer, We set up a Git pre-commit hook for styling and static code check so that all of the new file changes will follow a standard C++ styling and coding convention
– Remotely, We set up a virtual machine on Github to build and test every pull request made to our repo. As a result, in addition to being approved by at least one of the members, all pull requests would need to pass build and unit test check before it can be merged to ensure no one would break our codebase.
Cross-compiling
Because we only have one TX2, it is not productive for five of us to share it to code. Therefore, it is better if we can code on our computers and only run the program on the TX2 when testing. However, the system architecture of the TX2 is arm64, while all of ours are not, so the code that compiles from either of our pc cannot be executed on the TX2. Therefore, we set up a cross-compiling that allows all of us to code and compile the code on our computer to arm64 executable, and only run it on the TX2.
Cloud deployment
We added cloud deployment that is widely used in IoT application into our software development stack using AWS Greengrass and RoboMaker. Using this technology, we can have the TX2 automatically pull down a newer version and run it on its own. This way is also scalable because our software can be deployed to as many drones as we want.
Optimizing Memory Footprint
When working with the simulation, we had been very generous with the memory usage in our software as we wanted to focus on the functionality of the system first. For instance, to make the path planning more accurate, we built a very dense Octomap so that the drone would be able to fly through difficult environments. The original Octomap that we use last semester consumes a very big chunk in memory, in a total of more than 8GB, making my current computer, with a total of 8GB ram, freeze right after launching the software. As a result, we reduced the resolution of the map to make the total usage of the ram about 5.5GB to be able to run on my current computer. As a result, we was able to reduce the ram to less than 4GB of ram on my computer with Gazebo running. It would be now feasible to run the software on the drone without Gazebo.