An overview about software design.
See the Setup guide.
Software that we write
UAS@UCLA develops a wide range of software, fitting many new and exciting developments in the computing industry, which can serve to complement the CS and EE curriculum at UCLA.
This is the code that interfaces with sensors on the drone, receives mission data and commands from the ground station, and navigates the drone while controlling actuators for accomplishing mission objectives. The exact specs are dependent on the competition rules, but typically involves the following:
- Real-time control of the drone, with safety and failsafe/fallback mechanisms in place in the event that something breaks
- Moving and static obstacle avoidance and path planning algorithms
- Mission optimization
- Messaging system and serialization (for communication between processes, between subsystems, and between drone/groundstation)
- PX4 flight controller API support
- Control theory, tuning, and simulation
- Low-level code development for I/O and operating system control
"Flight Deck", our team's groundstation platform, is the front-end interface and equipment that is used to establish a communication link with the drone, receive telemetry about the current state of the drone, and send missions for the drone to follow. In addition, the ground hardware interfaces with the ground code to maintain a communication link with the drone throughout flight (antenna tracker) and allow for easy-to-use controls.
- Develops an intuitive frontend web interface for displaying state data about the drone and system as a whole
- Interfaces with the ground hardware to provide physical buttons and displays for showing telemetry data, and hosts the networking backend
- Controls an antenna tracker for aiming a directional antenna at the drone and maintaining a reliable high-speed link
Testing and Simulation Code
Tests and simulation allow for bugs to be caught before they make it to hardware. Tests and simulation are designed to fully encompass our software platform, both at the micro and macro levels. This software also deals with automation of various tasks, such as simulation testing and vision training. This is all done with our CI tools (Travis CI / Jenkins). Additionally, the testing software forms the backend of the logging system and is responsible for archiving this data for justifying future iterations on our design.
- Unit tests check that our custom libraries perform as intended and stay within spec as additional features are implemented
- SITL (Software-In-The-Loop) tests allow for the full system to be tested with a simulated flight controller, providing an almost identical experience to actually running the full software framework at the test field
- HITL (Hardware-In-The-Loop) testing replaces the software flight controller simulator with an actual PX4 flight controller, which ensures that the real-world flight controller acts in the same way as our software simuation tests indicate
- Dry flight tests occur when the software is tested on the physical drone and all activators are active, but the propeller is taken off the drone to avoid it actually taking off
- Full flight tests are tests performed with the fully-assembled drone at a testing field, where all subsystems are active
Logs are collected from every step of the testing process to provide quantitative feedback on system performance. Additionally, tests are performed from most-to-least in the order above -- meaning that Unit tests (the easiest to run, debug, and review performance statistics on) are run the most, while HITL, Dry, and Full flight tests (the most time-consuming to perform and, in the case of full flight tests, the most dangerous) and run the least.
Vision code uses machine learning and training to identify targets and points-of-interest outlined by the competition specs.
- Develops a camera and gimbal platform for capturing the best image from the drone
- Manages communication interface for sending images to the identification system
- Develops a ground station front-end interface for manual image tagging and review of autonomous performance
- Builds an identification pipeline for performing all of the vision tasks necessary (using OpenGL, Tensorflow, Keras, etc.)
- Collaboration between UCLA ACM and UAS@UCLA to develop this vision identification platform
The UAS@UCLA Development Platform
Our team's new approach to software development has been refined to support and encourage a wide range of software skill levels and personal preferences on development tools (OSes, text editors, computer models, subsystem team requirements, etc.). The new docker-based system is designed to allow for development across these many platforms and provide CI tools reproduceable images of our system that can be tested upon. However, our system is far from perfect, and there will be times when manual support will be required to fix certain issues. If you find that a tool that you enjoy using is not supported by our system, feel free to propose it to the team through our Slack channel and file a PR on Github for the changes required to add support.
Some of the core command line tools used:
- Docker - containment of the build system, simulator, vision pipeline, and other components with a complex tree of dependencies
- Bazel - build system for quick and reliable compilation and cross-compilation of C/C++ code (open-sourced from Blaze, the system used internally within Google for developing almost all of their software projects)
- Python / Bash Scripting - scripting languages that form the "glue" behind our whole framework for development, deployment, testing, and simulating
Additonally, command line-based software and scripts that the team has developed draws extensively from UCLA's CS35L and CS111 classes. Understanding this whole system will be vital to extending the system even further and solving issues that inevitably come up with it, so new programmers should begin by looking at the scripts in "tools/scripts" under the drone_code repository and understanding the commands that are executed beneath the hood.
Contributing to software on the team means opening "Pull Requests" to provide new features or bug fixes to the code base. Since our team (like almost every other modern-day software development community) uses Git, you will need to develop a basic background in working with the Git version control tool for managing your code changes and submitting them for review. Additionally, since our team uses Github's servers for storing the code, you will need a basic understanding of their system for pushing code to branches, developing pull requests, addressing code reviews, and merging code.
After reviewing these links, you can always refer to the UAS git guide.
C/C++ Code running on the drone
UCLA's CS courses (CS31, CS32, CS33, CS35L, CS111, CS131, CS180, ...) address most of the underlying skills required to work with the C/C++ code on the team. None of these courses are a requirement to do software on the team, but the topics they cover are very relevant to the subset of code developed on the controls, communication, and build systems.
In addition to the underlying coding concepts that can are taught in the CS classes, there are certain 3rd party frameworks and tools that must be mastered to make bigger contributions to the software base. These frameworks depend entirely on the subsystem and may evolve in the future, but often already have a very active community and a wide collection of tutorials and projects to gain a general understanding of the features provided by the framework. Subsystem directors will typically point newer members towards these external resources/projects instead of developing internal resources to avoid reinventing the wheel.
Cleanliness, Debugging, Review, and Testing
In general, modern software-based teams all follow the same set of principles, whether they are some small startup, a large corporation like Google, or a research-based company like Boston Dynamics. The exact choice of tools for the job may differ from place-to-place, however.
For UAS@UCLA software, here are the things to focus on:
- Code formatting - Code for a given language must follow the same design rules as all the other code in the repository (applies to C/C++, Python, Bash, etc.)
- Commenting - Comments are encouraged as much as possible, but become confusing and outdated after a certain point. In addition to comments, programmers should make the code as intuitive/readable as possible (through things like proper selection of varible names, etc.)
- Unit tests - If possible, code should be designed to be pulled out of the whole platform and unit tested in a much smaller, contained environment. These tests allow for bugs to be found a lot more quickly due to the simpler nature of unit tests, and are generally faster to run and keep track of than a full system simulation
- Branch names - Our team has not yet established a strict set of rules on Git branch naming conventions (such as feature/* or bugfix/*), but please try to not go overboard on branch names. We instead have been using Github Pull Requests into a single master branch to track the addition of new features
- Code review - Along with Pull Requests, code review is required for getting stuff merged, which starts by assigning code reviewers to take a look at pull requests. After back-and-forth discussions about the pull request on GitHub, the PR will either be merged or closed
- Continuous Integration - Every branch and pull request will be built by Travis CI automatically to provide a sanity check for the code uploaded to GitHub. Additionally, our team's private Jenkins server performs more in-depth automated testing on PRs and the master branch, such as linting, building, testing, simulating, and static code analysis.
Training and Projects
Please refer to the projects listed under each of the software-oriented subteams (Controls, Ground, Testing, and Vision) for more specialized training. However, here are some additional training resources for a basic skillset of software tools:
Version Control + Code Review
Common Programming languages
Continuous Integration and Automation
- Writing a Jenkins pipeline
- Docker image for running Jenkins locally, for practice
- Automated testing using Travis CI - Used as a backup code building check in case our Jenkins server breaks
- Command Line
- Version Control
- How to use Git (Codecademy tutorial)
- Make a pull request to the drone_code repository, add 2-3 other UAS@UCLA members as reviewers, go through the review process, and have your PR approved/merged into the master branch
- Continuous Integration and Automation
Please make sure to Google your errors first to rule out common issues, but the Slack channels are your best source of contacts for help.
If you would like to see what a successful build looks like, check out our Travis CI builds for past automated build logs of our Github branches and PRs.