Stabilization of an experiment pod using a reaction wheel and improved tether connector

Research Group: Jacob Blomdahl, Caleb Flegel, and Luke Roberts

Launch: Whitworth Spring 2022

''The following report contains results from the 2022 Whitworth high altitude ballon launch. The goal of this launch was to create a pod with minimal movement over the course of a near space balloon launch. While there have been attempts at Whitworth to characterize the motion of a pod over the course of a launch, there has never been an attempt to control it. With our launch we hoped to set a baseline for future experiments in this field and improve on experiments other groups have attempted. We decided to use a basic reaction wheel and an improved swivel mount that we designed ourselves in an attempt to nullify the pods motion. This project does not implement a heading system but future groups might benefit from adding one. Our pod was only designed to stop the heading from changing with no regard of where the heading was pointing. ''

Background
Near space is typically defined as the region stretching from 75,000 ft to 330,000 ft. It extends through multiple layers of the atmosphere to the edge of space. To get there one needs to travel through two layers of the atmosphere, both with very different climates. The lowest layer of the atmosphere is the troposphere, going from 0 ft to 30,000 ft. The troposphere is the densest layer of Earth's atmosphere. As the altitude increases the temperature steadily drops and the weather gets more intense. At 30,000 ft the troposphere ends at the tropopause, a temperature inversion where the cold of the troposphere is met with the heat of the stratosphere. The stratosphere is the next layer and it extends from 39,000 ft to 164,000 ft. As the altitude goes up, the temperature rises and the weather dies due to the lack of air and the absorption of UV rays by the ozone layer. Weather balloons have the ability to reach these heights and there have been many launches in the past.

An experiment conducted by the Chicago Adler Planetarium titled "Active Camera Stabilization from High Altitude Balloons" attempted to keep a camera steady by directly controlling its heading using two motors. The camera was not mounted to the pod; their motions were completely separate. They found that "The average rotation speed over the flight was approximately 46.22 degrees per second" (Active 5). This pod's rotational speed was far too fast to record meaningful video without completely isolating the camera's rotation from the pod's (as they sought to do). Our group has constructed a pod that will utilize a reaction wheel and an improved swivel connection in an attempt to reduce the motion of the entire pod caused by the intense weather inflicted on the way to near space. Using a 9-degrees of freedom sensor, a reaction wheel can be used to keep the pod from rotating. As the entire pod is stabilized, scientific instruments larger than a small camera can be stabilized.

Videos from previous flights, where the chain of pods is connected with two cables (fishing line), show that if any pod in the chain starts to spin, the rest of the pods start to spin and oscillate back and forth. A new swivel connection was implemented to reduce rotational forces from pods above this one. This new connection physically isolates our pod's rotation from the rest and negates or reduces the impact of their rotation.

Mechanical Design
''Our Mechanical design has two main parts: the improved swivel connection and the reaction wheel. It also has a few minor components that don't affect the motion of the pod, such as the camera system.''

Improved Swivel Connection
We used an AMYSPORTS Ball Bearing swivel and a mount of our own design to create an improved isolated connection. This allows the motion of our pod to be independent of the motion of the other pods. The ball-bearing swivels were put through rigorous testing. They failed at an average force of 142.5 pounds; more than enough to support our 2.6-pound pod. The swivel was mounted on a #8-32 steel bolt between two L-brackets mounted to an aluminum metal plate. The metal plate was bolted with #10-32 connected to another metal plate on the other side of the pod foam to connect the swivel to the pod. Our motor was attached to this bottom plate.

Reaction Wheel
A steel flywheel was attached to a GARTT ML3508 700KV Brushless Motor. The motor was driven by a BLHELI_S ESC and controlled with an MBED system. The MBED measured the pod's rotation with a 9 degrees of freedom gyroscope sensor. The motor was programmed to rotate in the direction opposite the motion of the pod in order to oppose the rotation of the pod. The motor was connected to the bottom plate of the improved swivel connection so it was fixed to the pod. The axis of rotation was in line with the pod's center of mass, which was designed to be at the center of the pod. The flywheel and motor have a rotational inertia of 0.00078 kg m^2 and the pod has a rotational inertia of 0.0041 kg m^2 (these inertial values were calculated based on our CAD models, and were not measured from the physical objects). These inertias have a ratio of about 1:5, meaning that for every 1 RPM the pod spins, the flywheel has to spin 5 RPM in the opposite direction in order to stop its motion. This was all powered using an 11.1V 1300mAh Tattu LiPo Battery Pack. The output of this battery varies from 12.6V to 9V. Since the motor is rated at 700KV, (meaning for every volt applied, the maximum throttle increases by 700 rpm) the motor's top speed has a theoretical range of 8820 rpm to 6300 rpm. With a flywheel at 1/5 the inertia of the pod, we anticipated that the motor would not become saturated, or reach its maximum speed. In the end, it did not even get close, with its maximum speed during the flight being around 30% throttle.

Other
On the side of our pod, we mounted a RunCam Split 3 Lite Series camera. The camera has two modules, connected by a collection of wires. The camera module consists of a camera sensor, lens, and a few electrical components all mounted on a small board (14mm square). The video recording module consists of a PCB with power ports, a micro SD card slot, and many more electrical components.

Electrical Design
''We have two different circuits in our pod, the reaction wheel circuit, and the camera circuit. Both are powered by the same battery, but they are controlled independently of each other.''

Reaction Wheel Circuit
The reaction wheel circuit is the more complicated of the two circuits. It is made up of an 11.1V 1350 mAh Tattu LiPo Battery Pack, a slider switch, an MBED control system, a 9-degrees-of-freedom gyroscope, a 20A EMAX ESC, and a GARTT ML3508 700KV Brushless Motor. The motor was selected for its relatively large stator volume (35mm diameter and 08mm height). This gives it high torque to accelerate our steel flywheel and a relatively low speed of 700KV (maximum RPM = supply voltage x 700) giving us more precise control at lower throttles. The motor was driven by an EMAX ESC using BLHELI_S firmware. An ESC is an electronic speed controller, it powers the motor and makes it spin. For more information on the selection of this device, see the Brushless Motor Driver section below. A 1300 mAh 3s (3 cell) battery pack was chosen to power the ESC (and camera) because it was easily accessible and roughly within the capacity range of how much power we expected to use for a 3-hour flight. A switch was used to easily turn the ESC off and on, allowing us to mount the battery in our pod long before the flight, instead of needing to remove the lid, connect the battery plug, and then reattach the lid at the launch site. The MBED was supplied for use in the project and provided a convenient interface for programming our microcontroller. The MBED reported data to the command pod and a local SD card, sent commands to the ESC, and read gyro data from our 9 DOF (degrees of freedom) sensor at a rate of 20 Hz. Additionally, we ran a proportional-control algorithm on the MBED to control the throttle of the motor, allowing the reaction wheel to spin in response to the pod's movement.



Brushless Motor Driver
We chose to use a brushless motor for its high torque at low speeds, and its smooth control, knowing that it would need to be commutated (driven) by a more complicated power source. We did not anticipate how difficult it would be to achieve this control using an MBED.

The first motor driver we tried to use was a mikroBUS Brushless 3 Click motor driver. We chose to communicate between the MBED and the driver using the I2C interface, a relatively standard protocol. To interface between the motor and the driver, this driver required several motor parameters to be declared. These motor parameters (eg. internal resistance of the wires) were not given to us in the datasheet of our motor and were often very difficult to calculate or determine. We were able to read the error codes that the driver displayed but was not able to effectively interpret and troubleshoot them, even after significant effort. Regardless of the commands sent to the motor, it would only occasionally vibrate. While different commands changed the strength and frequency of the vibrations, we never managed to get the motor to spin.

The alternative motor driver was a 20A EMAX ESC (Electronic Speed Controller). These are commonly used for controlling hobby-style brushless motors (eg. on drones). These drivers automatically sense the motor parameters, meaning that the interface between driver and motor was practically seamless. Achieving communication between the MBED and the ESC was more challenging. We needed to use the DSHOT protocol as it allowed us to spin the motor both forwards and backward. DSHOT is a digital signal where the 1 and 0 are determined by the high and low time of a signal, similar to morse code where the time of "high" sound differentiates between a dot and a dash. This protocol was not native to the MBED, so we needed to build our own code for the MBED to use the new protocol. Our code is heavily based on a library created by Blake West, which can be found here. Through viewing our signal on an oscilloscope, and interpreting binary values to digital ones, we were able to translate our digital commands into the DSHOT protocol. See the Code section for more information.

Camera Circuit
The camera has a much simpler circuit. A RunCam Split 3 Series camera is powered by an 11.1V Tattu LiPo Battery Pack, through an R-78W5.0-0.5 5V regulator. There is a 2 position slider switch to turn the camera on after the motor switch is turned on. The camera records at 1080p, 30FPS, and starts recording a few seconds after power is applied from the switch.

The manufacturer recommended against plugging the camera directly into battery power to avoid voltage noise, so we used a 6.5V regulator (R-78B6.5-1.0) to filter the battery power. We first tried a 5V regulator (UA7805UC), but the camera recorder and voltage regulator got uncomfortably hot (65°C and 88°C respectively). At 5V, the camera also drew an unnecessarily high current (650mA). We were worried that these prolonged effects could burn up the camera board, and might drain the battery so fast that it would not last the entire flight, which would result in a loss of recordings and the inability to spin our reaction wheel. We made two changes to combat these issues. First, we switched the 5V regulator out for a 6.5V regulator. The higher voltage means the camera draws less current (V=IR), which would prolong the battery life. This new regulator was also advertised to be 96% efficient, whereas the 5V regulator was only around 60% efficient. At 6.5V, the camera warmed to a comfortable 55°C, and the regulator stayed between 23°C and 28°C while testing.

We also introduced a switch between the battery and the voltage regulator. This allowed us to conserve the battery power by cutting power to the camera while the system was stationary on the ground before launch. We wanted to turn the MBED on roughly 30 to 45 minutes before launch to verify that all systems were working (the MBED was on for 15 minutes before launch, but we wanted the ability to keep it on for longer). We needed the motor to be powered the entire time, because the motor is armed when the code starts running, but we did not want the camera to be drawing power during this time. We flipped the camera switch to power it shortly before launch.



Code
Here is a link to our code where you can find specific comments. You are able to find our main.cpp under the “src” folder.

Our code was written in C++. We used the mbed browser interface for sensor reading and data communication. We used the BNO055 library to communicate with our 9-axis sensor, originally built by Carla Calderon and Hever Jonathan Zelaya Solano and later added to by John Larkin. We also built a custom object class to communicate with our motor controller using the DSHOT platform. You can find the DSHOT library under the “lib” folder and the BNO0255 library here.

The main objective of the code is to read the current data from our sensor, use this data to set the speed of the motor, and report the current data to the command module and write it to our SD card. The data on the SD card is stored in a log.txt file that is easily able to be copied into Excel for analysis.

The included flowchart shows how the code completes its objective. First, after the code starts, it completes the setup steps necessary for data to be read and reported correctly as well as arming the motor. If an error occurs during these steps, we utilize the red LED as an error light to report the fault. The code then starts two additional threads.

Thread 0, or the thread that runs main, is responsible for reporting the data to the command module and the log file. First, it sends the data for pitch, roll, heading, motor speed, and angular velocity to the command module. It then writes these data values to the log file on the SD card. If a preset file timer reaches over 30 seconds, the program will close and reopen the log file. This flushes the data to the file, which ensures all of the data makes it onto the file. At this point, we turn on the blue LED to signal that data is being flushed, which means the SD card should not be taken out. This original thread will then sleep for 5s.

Thread 1 is responsible for sending speed commands to the motor controller. First, it initializes the current speed and equates it to the previous speed command plus the angular acceleration times an error conversion constant. This constant is necessary because the speed values range from -1, or -100% throttle, to 1, or 100% throttle. Thus this constant, which is set as 0.000005, converts the angular acceleration to a number manageable within the context of the -1 to 1 speed range. This way of calculating current speed will cause the motor to speed up or slow down in response to the current angular acceleration of the pod. The code will then send this speed command to the motor controller for 52ms. This time is necessary due to the DSHOT protocol used. Finally, the previous speed variable will be set to the current speed, preparing for the next run of the thread. It is worth noting there is no sleep timer for this thread to allow the motor to respond to the changing angular acceleration as quickly as possible.

Thread 2 is responsible for collecting data from the 9-axis sensor. This thread is relatively simple. It collects the orientation variables, or pitch, heading, and roll, in three separate variables and the angular acceleration data in a vector. This is due to how the BNO055 library was built. This thread sleeps for 60ms after each data collection to allow for thread 1 to run as much as possible while keeping the angular acceleration data up to date.

Back in thread 0, once 220 minutes have passed, the code will terminate threads 1 and 2. Since this experiment focuses on the time between launch and when the balloon pops, it isn’t needed for the motor to counteract the motion of the pod post-pop. This time is very likely longer than the balloon takes to pop, so there would be little risk of ending the program too early. The code will then close the log file for a final time to make sure all data has been written to it. Finally, the code will turn on the green LED to indicate the program has been completed. The program itself will then end.



DSHOT ESC Protocol






The motor driver we used in our launch configuration was an electronic speed controller (ESC). Specifically, it was an EMAX 20A ESC running BLHeli_S firmware, over the DSHOT 150 protocol, configured in the BlueJay online ESC Configurator. Using the DSHOT communication protocol to link our MBED microcontroller and the ESC proved to be rather difficult to set up, but we considered this protocol the best choice because it allowed us to drive the motor both forward and reverse, and we did not need to calibrate the interpretation of the MBED signal.

The DSHOT protocol is a digital signal where the high and low values (1 and 0) are translated to the high and low times of a pulsed signal. In general, for a given bit duration, if the signal is high for 1/3 the time and low for the remaining 2/3, it is interpreted as a 0, and conversely, if the signal is high for the first 2/3 the time and then low the remaining 1/3, it is a 1. This can be seen in Figure 6, where the first bit is a 1 and all following bits are 0's. Each bit lasts 6.4 µs. Dividing this by 3, the short duration is roughly 2.1 µs, and the long duration is roughly 3.2 µs. It is important to note that these durations do not need to be incredibly precise past one significant figure. The BLHeli_S includes room for error in the duration of these pulses.

16 of these bits are sent in a packet, as seen in Figure 7. The total packet length is close to 100 µs, or 0.1 ms. We then do not send another packet for 4.9 ms, as seen in Figure 8.

Throttle Commands and Special Commands
The first 11 bits of the DSHOT signal are interpreted as a number. Numbers 0 through 48 are reserved for special commands, and 49 through 2048 are throttle values. To enable an easy transition from forward to reverse drive, we used a setting in DSHOT called 3D mode. In 3D mode, values between 49 and 1047 make the motor spin in reverse, 1048 is 0 rpm, and values 1049 to 2048 make the motor spin in the forward direction.

It is important to note that these are throttle commands, not rpm commands. There is no way to directly control the rpm of the motor using DSHOT. Instead, you command the motor to spin at a certain throttle percent. The corresponding rpm can be estimated by multiplying the motor's Kv number (rpm per volt, not kilovolt), the input voltage, and the throttle percentage. For example, a 30% throttle signal at the beginning of our flight, with our maximum battery voltage of 12.6V, and our motor having a rating of 700 Kv, would spin at 0.3 * 12.6 * 700 =  2646 rpm.

We initially thought that commanded values from 49 to 2048 proportionally increased the throttle from -100% (full throttle in the reverse direction) to 0% to 100%. This was not the case. DSHOT interprets values from 49 to 1047 as reverse drive, but the throttle percent goes from 0% to -100% as the value goes from 49 to 1047.

Values 0 through 48 are used for sending special commands to the motor. These include actions such as: disarming the motor (also used to initially establish pulse timings for communication), vibrating the motor to produce a beep, turning 3D mode on and off, reversing the normal direction, and setting up telemetry communication, to name a few. We only used the disarm and 3D mode special commands.

Validation and Calibration
We Validated and Calibrated various parts of our pod including the motor driver, the reaction wheel, the 9-degrees-of-freedom sensor, the improved swivel mount, the RunCam Split 3 lite camera, and the voltage regulator.

Motor driver
Validation:

To validate the motor driver we gave it a simple command to start the motor and run at a low speed for a few seconds, then at a higher speed for the same amount of time, and finally turn off. The motor performed exactly as it was programmed to. However, we found that the motor did not perform well below 3% throttle. We suspect that this is due to the motor controller we used.

Calibration:

To calibrate the motor driver we gave it a series of commands causing the motor to run at gradually increasing speeds until it reached its max speed then gradually spin down to a stop. The motor performed exactly as the motor driver told it to.

The video of this can be viewed at Motor Driver Calibration

Reaction Wheel
Validation:

The full reaction wheel circuit (explained in the electrical design section) was assembled, the code was uploaded, and the pod was suspended from a stable structure. The pod was then pushed around by controlled forces (our group) and we measured its reaction to different forces. The reaction wheel was able to stop the pod from spinning within seconds and maintained a constant heading angle until another force was applied.

Calibration:

The pod was suspended from a tree and left to be tested against uncontrolled forces (wind and weather). The flywheel was spun up to roughly 20% throttle before being suspended from the tree. This was to make sure the reaction wheel did not have to get out of the problematic 3% throttle range. After 17 minutes, the heading hadn't rotated by more than 45° from where it started. Overall the flywheel worked exceptionally well in this uncontrolled environment.

9-degrees-of-freedom sensor
Validation:

To validate the 9-degrees-of-freedom sensor, we mounted the sensor on the wall of the pod and started recording data while rotating it around. We were able to determine what direction changed the heading, roll, and pitch of the sensor.

Calibration:

To calibrate the 9-degrees-of-freedom sensor, it was mounted again to the inside of the pod and we started recording data. The pod was then rotated 90° and the sensor read that the pod was rotated 90° showing that it was properly calibrated.

Improved Swivel Mount and AMYSPORTS Ball Bearing swivel
''One of the main concerns for our new swivel mount was the strength of the swivel. The pod would be reliant on one point to hold up all of its mass as it spins. This component needs to remain reliable (freely spinning and connected) under high stress and tension. ''

Validation:

To validate the swivel we preformed a rotation test to see how it preformed at high pressures

Rotation Test Procedure: We conducted a rotation test to test the AMYSPORTS Ball Bearing swivel's rotation at high forces. We aimed to test how freely the rings of two swivels rotated under different force conditions. The setup was nearly identical to the break test we did before; the only difference is that we used two swivels connected to each other by wire instead of just one swivel. To accomplish this, we connected the top ring of one swivel to the Bridgeport milling machine and the bottom ring of the other swivel to the Modern Step crane scale. We slowly lowered the bench and locked it so the force on the swivel would be constant. We then incrementally increased the force from the milling machine to get measurements at different weights, increasing each time until we could no longer rotate the swivel.

Test 1: Rotation Test

Weight / Rotation Level

5 Ibs	Very Easy 10 Ibs	Easy 20 Ibs	Moderate 30 Ibs	Moderate 50 Ibs	Hard/Did not rotate Other: After the test concluded, we noticed a fracture on the body of the upper swivel, this most likely occurred at the highest weight when we forced it to rotate. It is possible that this hindered the rotation.

Rotation Test Results: The Ball Bearing swivel was able to freely rotate at low weights (0-7 Ibs; the operating force range). It did not struggle to rotate until around 35+ pounds. At 50 pounds it was very difficult to rotate and this is where we believe it broke. It is probable that forcing an object to move under intense forces can break the object, which is what most likely happened here. Overall this swivel should be sufficient for what we plan to use it for.

Calibration:

to calibrate our swivel we preformed a break test to see how much force a swivel could take before breaking

Break Test Procedure: We conducted a break test to test the AMYSPORTS Ball Bearing swivel breakpoint by suspending the swivel from a Bridgeport miller machine. One end of the swivel was connected by wire to a metal rod we drilled a hole in and placed in the miller machine. The other end was connected by wire to a Modern Step crane scale measuring the force applied in pounds (Ibs). We slowly lowered the bench, raising the force on the swivel by a constant amount over time.

Test 1: Break Test

Started deforming: 85 Ibs Failed:145 Ibs

Other: deformed along the weld on the top ring, when it broke the bottom connection broke between the ring and the swivel, the ring itself was not deformed post break, only the top ring was. Explosive break, parts went flying

Test 2: Break Test

Started deforming: Did not deform Failed: 140 Other: The wire broke multiple times so we tested this swivel multiple times at high forces before it got to 140 where it and the wire failed

Break Test Results:

Between the two tests, we had an average failure at 142.5 Ibs of force, and one of the two swivels deformed at 85 Ibs of force. The one break came from the lower pinhole breaking, the ring and the body of the swivel remained intact so we can assume that the hole is the weakest part. Overall the swivel will be dependable at the weights that we need it to operate at, it will not break as long as we stay under 140 pounds.

RunCam Split 3 lite camera
Validation/Calibration:

The camera was connected to the circuit described in the electrical design section and turned on. To validate and calibrate the camera, the pod was suspended from a structure and ran for 45 minutes. The temperature of the camera module got up to 65°C and the regulator got to 30°C. The camera split the recorded footage into 17-minute sections.

Voltage regulator
Validation:

The camera circuit was turned on and let run for roughly 5 minutes. Initially, the camera and the circuit board was secured to the pod using hot glue. After running the camera, it was discovered that the 5V regulator that was originally in the circuit and the circuit board generated an incredible amount of heat in a short amount of time, melting the glue. We changed our design and instead secured the circuit board with 4 - M2 threaded rods, M2 rubber nuts, and M2 metal nuts. We also switched to a 6.5V regulator. The combination of these two factors helped reduce the heat of the circuit and allowed it to be run as designed at lower temperatures.

Using a multimeter we determined there was 5V coming out of the 5V regulator on the Camera circuit. This is the exact voltage it was supposed to produce. This regulator, however, was not used, as it generated many thermal problems. We instead used a 6.5V regulator. We confirmed that the regulator produced 6.5 volts, and it did so over the entire working voltage range of our battery (12.6V to 9V). It was estimated, but not necessarily measured, that the regulator needed at most 2V more on the input than in output (or else it would shut off), which puts the lowest battery voltage at 8.5V.

Calibration:

We ran the camera circuit for 45 minutes with the lid on and the flywheel not running; this setup allows the most heat to build up. With the 5V regulator, the camera circuit board reached 65°C and the regulator reached 88°C. These temperatures were measured once every minute with a FLUKE 566 IR Thermometer. After being powered by the 6.5V regulator for 23 minutes, with a launch-like setup (lid on, flywheel on, hung in the wind) the 6.5V regulator reached 23°C and the camera circuit board reached 50°C. These temperatures show that the entire circuit was operating more efficiently, which is much more desirable.

SD Card
Validation

After running various tests with both of our circuits operational, our SD cards contained data on the motion of the pod and the video taken by the camera.

Calibration

After a "test flight" in the lab, we were able to read data off of the MBED's card in organized columns with clear labels and time stamps for all points.

Pitch, Roll, and Heading
With the 9-Degrees-of-freedom sensor used in the pod, assuming the camera points roughly in the +X axis direction, the Z-axis is out of the top of the box, and the Y-axis is out of the side; Pitch, Roll, and Heading corresponded to rotations in the YZ, XZ, and XY planes respectively.



The timeframe of the data is from when the balloon was launched to when it popped. We were focusing on controlling the motion of the balloon prior to the burst so our data only considers the movement until just before the balloon pops.

Our control algorithm aimed to reduce the angular rotation (heading velocity) to zero. It did not take the actual heading angle into consideration, so the heading angle is uncontrolled. Over the course of the flight, the heading angle was evenly and randomly distributed, as can be seen from the collection of gray dots between 0° and 360°.

The pitch and roll measurements are highly correlated to each other, with the pitch being offset by 90°. The pitch is offset by 90° due to the orientation of the 9-axis sensor when mounted inside the pod. The correlation arises because the pitch and roll are physically indistinguishable from one another in the system; neither is controlled, and the rotational inertia of these axis' are very similar, so the collection of random forces affects both axis' of rotation equally.

Previous to the 2016 Whitworth experiment Characterization of pod motion during balloon flight only reported the acceleration of the pod after the burst so there was no comparable data.

Motor Speed and Angular Velocity




The data from the motor speed of the flywheel and the angular velocity of the pod were collected. The motor was programmed to oppose the rotation of the pod, specifically the heading-based angular velocity. Thus, theoretically, the motor speed and the angular velocity should be nearly opposite of each other.

Similar to the orientation data, the data is taken from the time when the balloon launched to when the balloon popped. After the burst, the motor continued spinning with no real effect on the falling pod until the descent became more controlled.

There is a very strong relationship between motor speed and angular velocity. However, when the motor speed is in the bottom 2%, the angular velocity has a much higher error. This is due to our motor driver's inability to properly spin the motor within this throttle range. As a result, when the desired thrust is low, the pod will stop spinning for the most part and then rapidly but quickly spin up, causing instability in angular velocity. There is a noticeable increase in the variability of the angular acceleration during the times when the desired thrust is low. This variation is likely due to the motor controller issues. You can see a demonstration of the problem occurring in a video here. Motor Problems

From launch to the time the balloon popped, the average absolute value of the rotation velocity is 29.2 degrees per second, which is a noticeable improvement over the 46.22 degrees per second recorded by previous experiments. If the time after the balloon pops is included in this data, the average rotation speed increases to 52.7 degrees per second. The explosive balloon pop event introduced a substantial amount of chaotic motion into the chain of pods. Our reaction wheel system was not fast enough to counteract these forces.

Video
The only comparable data available came from the 2018 Whitworth balloon launch video. The 2022 launch video was recorded from within our pod. Thus, when the motor was operating properly, we were able to record a stabilized video. In comparison, the 2018 launch was attached to a regular pod and was subjected to a constant oscillating motion. Using the previous recording as a reference, we are able to compare a stabilized pod with a regular one. The video can be viewed at Whitworth Near Space You Tube. Based on the time between launch and the balloon popping and an average ascent rate of 1000 feet per minute, we estimate that the flight climbed to an altitude of 77650 ±10% feet. This is a rough estimate as we did not receive direct altitude data from the command module on this flight. In addition, we postulate that the real peak altitude is likely higher than our estimate as the balloon exerted a higher than average lift compared to previous flights. The 2018 video comes from over 20,000 feet above the 2022's videos peak. The estimated height was 100,000 feet at the time of the video. Their pod was not attempting to control the motion of the pod. The 2022 pod only just made it into the stratosphere, the second layer of the atmosphere, before the balloon popped. On the other hand, the 2018 balloon made it well into the stratosphere before popping. Seeing as most of the world's weather occurs in the troposphere, which is just below the stratosphere, the 2018 balloon had more flight time in ideal conditions. Even with this disadvantage, the 2022 recording remains more noticeably stabilized.

The video from our 2022 flight can be viewed at 2022 Balloon launch. The video was taken using a RunCam Split 3 lite camera. The fisheye lens on the camera exaggerates the Earth's curvature, which appears much more pronounced than what would be seen in person. The camera was attached to the side of the pod. We did not give the pod a common heading to maintain; instead, we just tried to slow its rotation down once it started to move. This can be seen as the stable heading changes quite frequently throughout the flight. Overall, there is far less side-to-side oscillation and abrupt movements thanks to a combination of the improved swivel mount and the reaction wheel.

Conclusion
Overall, our pod beat all previous metrics it was compared against. Our average angular velocity was just over half of the normal average measured by previous groups which is a significant improvement. The video quality was also much improved from previous recordings. The data we considered includes all data points from the time of the launch to when the balloon popped. This includes the times when our motor entered its low throttle range (which temporarily handicaps it and causes it to spin back and forth). Our pod's improved swivel mount, the compensation from our reaction wheel, and the algorithms to dynamically control the motor aided in a successful flight. As a result, we saw a substantial improvement in moment-to-moment angular velocity compared to previous flights.

One restriction we faced was a lack of data to compare our results with. There have been few launches similar to ours and they did not provide much data about their flights. Specifically, there was not much heading, pitch, and roll data to compare to. Thus, we encourage any other group to do a similar experiment to get baseline orientation and velocity data from our group or another pod to get comparable results. This would allow groups to more confidently determine the efficacy of their experiment. In addition, if we were to participate in another launch, we would attempt to have the algorithm attempt to stay pointed at a single heading, rather than simply dampening the angular velocity. This would both provide the same stabilizing effect, but it would also allow the opportunity for finer control of the orientation of the pod.

Finally, we would use a different ESC (and possibly a different BLDC motor) for better motor control in our throttle range. Our ESC greatly reduced the quality of our low-throttle commutation. There are three changes that could improve our performance: the inclusion of Field-Oriented-Control (FOC), an ESC firmware that supports sinusoidal commutation, and an ESC that can work off of the I2C protocol. FOC is a technology that allows the ESC to have a more accurate idea of what angle the motor is pointing. This allows the ESC to send a more accurate signal to the motor. As an analogy, if the motor driver is a parent and the motor is a child on a swing, and the parent is "driving" the child, FOC allows the parent to see what the position of the swing is, so that the parent can time their pushes. Sinusoidal commutation allows the ESC to provide a smoother input signal to the motor. Normal signals are trapezoidal, which is an approximation of the "pure" sinusoidal waveform that is perfectly adequate at high RPMs (and is actually more efficient than sinusoidal, possibly because it takes fewer switched to produce this simpler wave) but lacks the precision needed for low rpm driving. In our playground analogy, this is the difference between the parent gently applying pressure throughout the swing motion, and the parent kicking the child half the time. The child can get going more smoothly with gently applied pushes than with jolted movements. It is also important to pair a sinusoidal ESC with a sinusoidal motor. Most hobby BLDC motors use a type of magnet configuration that is suited for trapezoidal drive. Using the I2C protocol might not necessarily make the flywheel spin smoother, but it would certainly make for a more predictable reaction system, and would greatly ease the connection of the ESC to the microcontroller. In terms of motor selection, a motor with higher torques should preform better, and

In hobby-grade ESCs, ESCs made for remote-controlled 4-wheel vehicles more commonly support FOC, since they are intended to drive motors with more torque and less speed than on a drone, but still in the same size class as the motor we used. As far as hobby-grade firmware goes, the firmware we used is by far the worst for low-rpm driving. This is because BLHeli_S (what our ESC supported) does not support any sinusoidal commutation. BLHeli32, a different firmware, supports sinusoidal drive up to a certain rpm, and then switches to trapezoidal. They call this mode "Sine Modulation mode" and it must be selected in the BLHeli32 configurator. FETTEC ESCs use sinusoidal commutation over its entire throttle range. One tester (mentioned later) saw that BLHeli32 accelerated a motor faster than FETTEC. For this reason, as well as price and availability, I would recommend BLHeli32 over FETTEC and certainly over BLHeli_S.

ESCs built for robotics instead of hobby motors could also be much more useful due to their focus on low speed and their use of more common protocols for microcontrollers. https://odriverobotics.com/ make such ESCs.

I learned much of this ESC information from the renowned Chriss Rosser in his video https://www.youtube.com/watch?v=gcMP40ERzg8.

References/Works Cited

 * Active Camera Stabilization from High Altitude Balloons (https://www.iastatedigitalpress.com/ahac/article/5558/galley/5424/view/ )
 * DSHOT150 from MBED (https://os.mbed.com/users/bwest32/code/DSHOT150/ )
 * Atmosphere of Earth (https://en.wikipedia.org/wiki/Atmosphere_of_Earth)