Tracker Whoop

Why do we even need another camera? There's clearly already one on the schematic. However, that camera serves one purpose and does a good job of it: broadcasting a live image, with all the key information, and with as little latency as possible. In order to achieve this, some compromises must be made: The feed has a resolution of 480p, and the quality of the image breaks down rapidly in presence of radio interference or objects obstructing the path of the radio waves. This can result in the following breakup:


Definitely flyable, especially with some practice, but not the kind of finished product most clients would hope for.
Most FPV drones get around this by strapping a self-contained camera like a GoPro to the drone, but in our case a quick look at any of the GoPro's specs point to an obvious problem: they weigh more than half the drone. If we add a battery on top of that the drone will still be able to take off, but will weigh over 250g (a significant milestone in most countries' legislation) and more importantly, it will hover at such a high point in the throttle that the flight time is unlikely to be much more than a couple of minutes.
To get around this we can start tearing down the GoPro and removing anything that's not crucial to the recording function.


Before starting any surgical procedures, it's a good idea to flash another firmware called 'GoPro Labs' (made by GoPro) that gives us access to some functionalities most people wouldn't need. One example of this is being able to power on the camera from another power source than the provided batteries. If you've ever seen footage from a rocket launch near the boosters where the camera has had to be powered on for several hours and the recording triggered from a distance, that was probably a camera running GoPro Labs. Now for the risky part! I felt better about this given my Hero 7 Black had already seen some field (ab)use of which the rear screen is a testimony:

• Most of the weight comes from the case, very rugged but this shouldn't see many crashes. We can replace it with a much thinner shell.
• The next heaviest part is the battery, We can get rid of it if we power it via the drone's battery, although this does mean adding a bec to avoid frying the logic board.
• The front and rear screens can go too. The rear screen is needed for changing settings but I'll get back to that.

Once we've torn off the front cover, chiseled through a substantial amount of glue and removed all the screws, we're left with a main board and a sensor and lens module with a ribbon cable. All the ports (USB, HDMI, ...) can be discarded. Before adding the BEC and screwing everything into the new case, we need to solder on a new antenna for the Bluetooth/Wi-fi transmitter to prevent it from frying itself when we next power it on. Nothing fancy, just a piece of wire tuned to the right length will do. There we go! We've successfully shaved off almost 80% of the camera's weight!
Now if we want to change the settings we can clip on this new screen in a 3D printed case allowing us to both see the live feed (used for setting exposure for instance) and also use the touchscreen to interact with the menus.
Another advantage is how the case adapts the lens to the same diameter as the Mavic Pro's camera. That drone came out back in 2016 and was popular but now completely outdated. All the third party ND filters however are still readily available, and have dropped significantly in price. These allow us to get nice motion blur around objects close by as well as protecting the lens.

Let's quickly go over how drones move in order to understand the problem we're about to solve: The image above sums up most of the forces that come into play when a drone is traveling forwards. In the context of a hover, there are only really two forces: the force the drone exerts on the surrounding air, and the reaction that air has on the drone according to Newton's third law of motion. Pushing down on the air allows the drone to overcome gravity and stay airborne (as in the case of any heavier-than-air aircraft). If we want to move the drone on any other axis than the vertical one however, we need to strategically tilt the drone as seen in the magnificent illustration above. Now the vertical component of the reaction (in green) keeps the drone in the air, whilst the horizontal component (in purple) serves for direction.

Now that we've established that a multirotor must tilt to move around, it becomes obvious why FPV drones add a tilt to their camera (theta in white here): the up-tilt prevents them from looking down at the ground when moving forwards. The faster the drone plans on flying, the more aggressively it tilts forwards and the more up-tilt becomes necessary.

However, what if we want to film something whilst moving backwards? The drone tilts backwards, so does the camera, and now it's looking straight at the sky... In a similar way, if we want to pan down to track or reveal a subject, a static tilt will result in a sudden violent forwards acceleration whether desired or not.

Now we understand why having a variable tilt can be such a game changer, and I recommend you go back and watch that first video and try to make out when the camera tilt is changing. The CAD animation below shows how simple that can be. As long as both the pilot's feed camera and the main camera both tilt together, all it takes are a couple of 3D printed parts and a servo motor.

The linkage is made from a piece of paperclip, the thought being that this would be the first point of failure in a crash to prevent anything more precious from being damaged. Initially this didn't go to plan since I tried saving weight by choosing a plastic gear servo. The first small crash was enough to shear off some of the teeth inside, but since switching to metal gears that's no longer a problem.

Now all we need is both a way to send tilt controls to the drone, and a way to control the servo, both have pretty neat solutions:

• With both hands on the controller, adding the tilt to a potentiometer on the remote isn't a viable option. However most radios have a port on the top that allows for a second controller to be plugged in. The main use case is having both a student and instructor in control of the same plane, with the instructor having higher priority. What's actually happening is the information from the second controller gets added to more channels sent to the aircraft on top of those from the first radio. The goggles can therefore emulate the second radio by sending 3-axis Euler angles over PPM. This isn't perfect as it drifts over time and my goggles must be defective since all axis are mixed (i.e. looking left will also make the pitch axis respond) It stays usable for this application but I have some ideas on implementing my own headtracker in the future that could solve this.
• Moving the servo takes some creativity since the flight controller doesn't have any dedicated servo outputs as would a fixed-wing FC. However, it does have an RGB LED signal pad that outputs PWM in order to change the colour of LED strips during drone races to tell apart pilots. In order for the servo to move when the pilot tilts their head, we can simply remap the RGB signal pad to mirror the channel on which we're sending the head tracker data. This can be done via the CLI with the following commands:
  
  
  • "resource list" displays the pads currently assigned to the F405's timers for PWM usage, this includes the motor outputs
  • say we see the led pad on pin A9. We can remap A9 to an abstract object called 'servo': "resource servo (servo number) A9"
  • Finally we can finish off with
    
    "servo (servo number) (min_value) (max_value) (mid_point) (rate) (direction)"
    
    to set up the servo, and
    
    "smix (servo_number) (aux_channel) (scale_min) (scale_max) (offset)"
    
    to assign the servo to a channel of our choosing

There we go, put that all together and we have a functioning head tracking drone capable of some pretty impressive shots.
I would recommend this project or something similar for the multidisciplinary aspect of it. I think it's a good display of use of electronics, mechanical design, and overall problem solving with some embedded systems notions sprinkled in.