Quadcopter Subsystem

Hardware/Software Overview


The quadcopter system includes the DJI Matrice 100 with the Guidance, shown in the below figures.  The Guidance provides the N1 flight controller more stable velocities using optical flow. The N1 Flight controller runs low level control algorithms, while the single board computer (Odroid XU4) runs higher level processes as explained in the cyberphysical architecture section.


We use a Matrice 100 quadcopter made by DJI.  The Matrice 100 is a developer quadcopter with a well defined SDK, and a very robust lift capacity.


Figure 1 – Matrice 100 (Source)


The sensor subsystem is working with the DJI Guidance system. The Guidance will be used for collision avoidance and landing tasks.


Figure 2 – Guidance System (Source)


The navigation subsystem will take the vector from the quadcopter to the platform and plan a smooth path and send waypoints to the flight controller. It will also need adapt the path to the motion of the platform and errors in the quadcopter’s performance. The subsystem will work with the Onboard SDK on the Odroid XU4 (Single board computer).


Figure 3 – Odroid XU4 (Source)


The entire locking mechanism can now be seen on our Docking Platform Subsystem Page.


The docking subsystem will design a method of learning the pseudo-random motion of the platform and determine if docking is possible and then plan an opportune moment for approaching the platform, prioritizing a collision free docking. This subsystem will work with the Onboard and Guidance SDKs


The communication subsystem is responsible for designing a method of communicating a protocol to transmit the information between the platform, the quadcopter, and the mobile application. This information will be used by the quadcopter to localize itself into the frame of reference of the docking platform. This subsystem will work with Onboard SDK. Most probably, a new protocol will need to be designed to enable the communication.


The quadcopter comes with a powerful SDK and simulator to allow for complex tasks to be automated.  In addition to the already robust hover and obstacle avoidance built into the Guidance system, we have added state estimation for indoor flight. Current status of the code on the quadcopter is depicted in the below figure. Although the Guidance is connected the N1 and is being used for flight stabilization via optical methods, the data isn’t being logged or implemented using the Guidance SDK on the Odroid XU4.


Figure 4 – Code Architecture (FIX)


Control System Power Distribution/Signal Routing

Our quadcopter requires extra power for the Odroid and Nicadrone, which is provided by a 7.4V 2-cell LiPo battery run through a power distribution board.

Dock-In-Piece Quad PDU_Page_1

Figure 5 – Quadcopter PDU diagram

Current Status

Table 1 shows the functional progress on the quadcopter. Although we had planned to the move the quadcopter from Point A to point B during the fall validation experiment, due to a crash we couldn’t do so. As such, we instead integrated AprilTag detection with the navigation node and moved the quadcopter in accordance to the distances provided by the AprilTag node. Basically, the AprilTag node would detect an AptrilTag 5 cm away in the x-direction, and the navigation node would decrease this error.

Complete To Do
Stable Hover Point A to Point B navigation in reality
Manual Safety Override Localization with respect to Dock
Logging Data Stabilization under Dock
April Tag Detection Rendezvous with Dock
Computer vision integrated Point A to Point B in simulation