{"id":47662,"date":"2021-03-18T13:10:59","date_gmt":"2021-03-18T17:10:59","guid":{"rendered":"https:\/\/seniordesign.digitalscholar.rochester.edu\/ece2021\/?p=69"},"modified":"2022-04-13T10:48:43","modified_gmt":"2022-04-13T14:48:43","slug":"architecture-for-a-cooperative-slam-for-multi-uav-systems","status":"publish","type":"post","link":"https:\/\/www.hajim.rochester.edu\/senior-design-day\/architecture-for-a-cooperative-slam-for-multi-uav-systems\/","title":{"rendered":"UAV Autonomous Navigation"},"content":{"rendered":"\n

Project Description<\/strong><\/p>\n\n\n\n

Drone projects seemed to have gained a poor reputation for senior projects within the ECE department. Plagued with the challenges introduced by a 3rd<\/sup> degree of motion, gravity, and a higher price tag, groups that attempt these projects seem to encounter less success than others.  Ignoring both the advice from other students and professors, we decided to move forward with the idea of a drone project anyway. Our goal was simple: create a fleet of fully autonomous drones which could work together to map out an area while simultaneously localizing their position in the world. A project like this could see use in search-and-rescue, industrial surveying, and exploratory applications.<\/p>\n\n\n\n

The theory behind our project was not groundbreaking or new. The SLAM (Simultaneous Localization and Mapping) algorithms that we intended to use have been around since the early 1990s. Most of our group had taken the ECE department\u2019s 232 course, Autonomous Mobile Robotics, which provided both the theoretical and practical knowledge required for us to get started. Our challenges lay in implementing what we had learned into a drone specifically. The margins of error had to be reduced, the uncertainty increased, and the computational challenges had the potential to skyrocket exponentially. Any one problem, whether it being a poorly optimized algorithm or a broken drone that had crashed to the ground, had the potential to delay or break our project. Though we were ultimately not able to achieve a fleet of mighty smart drones, our progress does bode well for future groups who wish to give the challenge of drone programming a try.  <\/p>\n\n\n\n

Design Process<\/strong><\/p>\n\n\n\n

Our group had already picked a platform to use for our project during the previous semester\u2019s reverse engineering assignment. Ryze Tello made a small, relatively inexpensive, drone which had gained a reputation of being exceptional for student projects. Drivers had already been developed to control the drone from a computer and we had found similar projects suggesting the drone camera could support SLAM algorithms. We quickly moved past the hardware phase and dove straight into a software research phase. <\/p>\n\n\n\n

\"\"
Tello Drone<\/figcaption><\/figure>\n\n\n\n

The first several weeks of research went into setting up Linux virtual machines, interfacing with the drone, and experimenting with different driver packages and existing libraries for us to utilize in our project. We decided early on to use ROS (Robotics Operating System), a robotics-oriented middleware, as we had already developed a good understanding of it from the Autonomous Robotics course. The majority of Tello drivers we had found also utilized ROS which allowed us to quickly start sending commands to and receive data from our drone. The decision to use ROS also pushed our group towards all working within Linux, which required us all to setup virtual machines on our personal laptops. This research phase was critical in getting our group on the same page and preventing any poor early design decisions. We moved on once every one of our team members could send commands to the drone from their personal laptops. <\/p>\n\n\n\n

After this initial research phase, we started to focus on the design of the ROS software architecture. This consisted of isolating the various problems (planning, motion-modelling, localization and mapping, etc.)  into separate processes which we could dole out and work on separately. Although the overall architecture faced several revisions over the duration of the semester, it remained relatively the same, consisting of two major components, a motion stack and a perception stack – fusing the Sense-Plan-Act control methodology commonly encountered in robotics. The motion stack consisted of everything required for the drone to create a path to chosen destinations and follow that path to its destinations. The perception stack consisted of everything required for the drone to use its camera to localize itself in the world and map out the world around it. The design phase was the shortest, only lasting about a week and a half, before we simply began coding.  <\/p>\n\n\n\n

\"\"
Project Architecture<\/figcaption><\/figure>\n\n\n\n

We focused on implementing the motion stack first. Each group member was assigned a node to work on and everyone attended meetings twice a week to test and debug our progress. This was the longest phase of the project, as it simply took time to work through and debug every aspect of the drone\u2019s motion. Up until the very end during testing, different parameters – namely gains in motion controllers, tolerances in path planners, etc. – were being tweaked for the drone to move smoothly, and correctly. <\/p>\n\n\n\n

After several group members had finished their tasks working within the motion stack, they moved on to begin working with the drone\u2019s perception. We had no interest, and especially not the time, to implement our own version of SLAM. Therefore, a lot of research was put into what SLAM libraries were available to us and which would work best utilizing the drone\u2019s monocular camera. Ultimately, a library which utilizes ORBSLAM, a feature-based SLAM algorithm, was found and chosen for our project.  We then began the process of tweaking it for our use and running calibrations to determine various drone camera characteristics required by the ORBSLAM library. <\/p>\n\n\n\n

As the motion stack and perception stack were both being finalized, we ended up transitioning into a final testing phase. This consisted of the last couple weeks before the end of the semester when most of our code had been written but needed testing with the physical drone instead of our virtual simulator. As expected, this was a period of rampant bugs and unexpected behavior. Every poor coding and design decision returned at this point to haunt us. In the end, we were able to achieve basic autonomy and with a successful SLAM implementation, although the reliability does suffer and more time would be required to achieve a fully polished product.<\/p>\n\n\n\n

Architecture<\/strong><\/p>\n\n\n\n

Tello Interface-<\/strong> We ended up choosing the ROS endorsed Tello driver after comparing several of the options available to us. It works by sending UDP messages back and forth with the drone which exchanges commands and various status properties. Choosing a driver early in our design process allowed us to get started much faster than if we were to create our own messaging protocol. We faced early problems regarding the computer\/drone connections when we were working inside VMs. We were able to overcome this by using a USB wireless antenna. Eventually, we switched to a native machine Linux machine during the final testing phase. <\/p>\n\n\n\n

Planner<\/strong>– The planner is responsible for calculating the shortest path between any two points comprised of an x, y, and z coordinate. The planner can read in a set of obstacles described as a point cloud in the perception node and dynamically. In order to accomplish this task, the well-known graph traversal and path search algorithm A* was implemented. Using the output of the planner, the path following controller is able navigate to desired waypoints. <\/p>\n\n\n\n