All teams were very generous and eager to share their designs. So we took advantage of their generosity and documented a few things to consider for future events.

• More powerful motors. Our design used brushed DC motors while just about every other team utilized brushless DC motors (similar to ones found on racing quadcopters such as one shown here.

• Brushless motors also require an esc. . Many can be reprogrammed to be reversible.

• We updated our design similar to this, but using a dedicated motor(s) to control yaw like on this fin.

• We also made this adjustment, but active capture mechanisms seemed to work better. Such as this.

Which controls a servo that closes a door once the ball is captured.

• Or this that actually uses a servo to pull a string that pulls the grabber jaws closed. This design also tried to use a fan to provide some suction to pull the ball in. It worked great until the ball got sucked into the fan (Sorry didn't get any video of that).

• Many teams started with passive grabbers like a frame that would allow the balloon to be captured such as this. . But almost every time the balloon would drift out again before it reached the goal.

• Most designs used multiple cameras for various functions. Many either used the ESP-Eye or OpenMV cameras.

• Several used ultra sonics to detect proximity to either the ball, target, ceiling, or ground, although it was not clear how effective they were as their range and accuracy are limited.

• Penn St/ARL seemed to have the most complex design. They used an Intel RealSense 3D camera for visual odometry. . An ESP-32 for motor control and a raspberry pi 4 running tensor flow lite that they trained to detect the game ball. They performed training early in the week in the highbay. They used a complex path following algorithm for searching. Although they were the first team to qualify it didn't appear their setup gave them a distinct advantage.

• GMU was the only team that fielded multiple blimps at one time. During one event they had 9 blimps in the air, however it seemed more chaotic and they didn't score with any of them.

• Most teams relied on WiFi (GMU used Zigbee) to communicate with their blimps either to send manual commands or receive telemetry/debug data back. Might be future opportunities for Wifi disruption??

• All of the more senior teams made their own balloons for their blimps using sheets of mylar. They supplemented lift with smaller off-the-shelf balloons as needed. I am not sure there is a distinct advantage to this, other than having greater control over the shape and therefore the design of the structure.

• All teams used 3-D printed mounts and styrofoam to add the structure for their electronics. The use of styrofoam was mostly to add rigidity when affixing parts directly to the balloon such as shown in the camera detail picture above.

• GMU seemed to have a good design for their frame using black boba-straws shown here.

• Some teams used passive fins to add stability (see the first picture in the previous bullet). Although I did not observe differences between ones with fins and ones without, the teams that used them swore they helped.

• The biggest design difference between the IU team and the other more senior teams seemed to be motor power. Using brushless DC motors they were able to yaw, climb, and descend much faster than us. GMU, under full power could go from the ground to the ceiling in less than 5 seconds where it would take us well over a minute.

• We switched from a Raspberry Pi Zero to the new Raspberry Pi Zero 2. This seemed to greatly improve our overall control loop time. It went from ~250ms to ~100ms which gave us greater control during tracking since the control loop time controls how quickly changes can be made.

• Going into the competition we had 4 motors: 2 to control fwd, rev, left, right and 2 to control altitude. We quickly realized trying to move forward and turn simultaneously became a difficult control problem so we added 2 more motors dedicated to yaw (left, right). . This gave us much greater control as seen in the this clip where we first tested the new yaw motors. Because of the greater control the search pattern needed to be adjusted because it turned too fast now.

• PID Tuning. During initial tests PID control used during tracking a target were not tuned very well as seen here with poorly tuned gains where you can see it attempt to align to the target, but then spin to where it loses sight of the target. After spending some time tuning we got it tracking a little better with better tuning, but even more tuning, particularly increasing the D-gain, gave us even better results. Note, in this clip the thrust motors were actually set in the wrong direction so it was reversing instead of moving forward. The takeaway, however, is that with more tuning (which just takes time and patience) the current design can be improved and tracking even better. More complex control schemes could be utilized such as LQR, machine learning (reinforcement learning), etc., but there is a lot of opportunity to make large improvements in the current design with just tuning.

• Determining range to target is a challenge. We tried several experiments utilizing the LIDAR to detect the ball, but unless it was dead-centered in the camera we would miss it and get a false reading. We tested a few more ideas, but ultimately within being able to perceive depth, getting an accurate range which would tell us if we are close to capturing (or close to going through the goal) is difficult. If we can determine range we can change the control scheme the closer we are to the target (e.g. make more fine changes the closer in we are). This could be important for autonomous capture. This target tracking is a good example of need for range detection. As Bruce gets closer to the target it is still making large control adjustments to the point that it turns completely away from the target and loses tracking. A future design might dampen the control as it gets closer to the target.

• Because we had such a hard time increasing our altitude we changed the control scheme several times. First we removed PID control for altitude. If we were below the target we ascended at full throttle. If we were above the target we would coast (not using the motors to descend). More power to our altitude control will help alleviate this.

• Altitude hold was also a problem. When searching for a target we initially planned to ascend for a specific amount of time and then descend for that same period so we would be back at the same starting point once an entire run of the search algorithm was complete. But because we ascended so slowly and descended slightly faster this approach was too random. Were were able to change the design so when in search, if we detected an April tag we would attempt to align in the same plane. We also pointed the LIDAR up (towards the ceiling) so if we didn't detect an April tag we would ascend until we did or until we were approximately 2 meters from the ceiling. Then we would coast back down. We also tried being completely neutrally buoyant and found that once we started going up, there was not enough thrust to bring us back down so we settled on being a couple of grams negatively buoyant, relying on gravity and air flow to bring us down and motor thrust to push us up. Controlling altitude was definitely the biggest challenge. This is a quick clip of full throttle downward thrust even being negatively buoyant.

• We added an active door to capture the balloon. Based on what other teams were doing we added in a servo that is manually controlled to close a "door" once we capture the ball. . Operation of the door

• We tried during different schemes for search pattern and target tracking to utilize the information coming from the IMU, in particular the yaw information, but always because of other factors we ended up cutting it out. However, whenever we utilized the IMU for yaw it gave us very accurate readings. Utilizing the IMU should be considered for future designs. It could be used to give control feedback for object tracking or determining turning radius when performing a search pattern. With more powerful motors we could adjust pitch to climb faster, the IMU would be useful for determining pitch angle. We were accurate data from the IMU without calibrating.

• All of our development throughout the week focused on Bruce (4-shark design) because we seemed to have greater control with that design, but most of our changes (with some modification) should translate to Clifford (4-round balloons).

This is here to document where we left off, it is by no means a done design! As noted above our efforts focused on Bruce throughout the week but changes could be easily adapted to Clifford as needed. Both blimp structures seem to be viable moving forward.

Shows rough idea of where components were installed. No wiring shown.

Note in the "alternate function" we performed some tests with two brushless DC motors and wired in the ESCs in those pins. Much more redesign will be required to fully integrate motors with ESCs.

We made many quick changes throughout the week so blimpy.py has become a little messy, but the final state is on the Code page: blimpy.py. This state uses the dual-H-bridges for control of all six motors, it has manual control of the capture door, and keeps the tuning gains we settled on later in the week. Usage is python3 blimpy.py <goal_color> where goal_color is either "yellow" or "orange" depending on which goal you are assigned in the match. The program will wait until a PS3 controller is connected before initializing.