Hardware/Software Overview
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.
Quadcopter
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)
Sensor
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)
Navigation
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)
Mechanism
The entire locking mechanism can now be seen on our Docking Platform Subsystem Page.
Docking
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
Communication
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.
Software
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.
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 |