I love figuratively getting my hands dirty when working on stuff, but unfortunately sometimes I use a keyboard.
Programming is an awesome tool.
My experiences with it take a slightly obtuse route. The earliest attempts were using my graphing calculator, a TI-Nspire, to make functions for math class. This simplified such things as the law of cosines to shorten my homework load significantly. Later on I learned more of the coding language than needed just to punch out numbers, and on a TI-89 I eventually developed a clever quadratic function into an artillery game. Unfortunately, the scripts for these have long since been lost to time and software updates.
Once enrolled in UC Davis I took a formal programming course, where I learned MATLAB. It was a good course, and I was excited to bite into some useful coding. After the course I began to use it as a graphing calculator, as it is highly capable in matrix operations, such as Eigenanalysis. It proved to be a valuable ally in homework, as well as a powerful tool in personal projects.
The first such project I embarked on was in early 2012. Due to the wonders of the internet, there had been announced a mysterious gigantic NERF blaster, what is now released as the Centurion. At the time, we knew it had a new type of dart, a larger caliber than before, and a large advertised range of 100 feet. It was new and very exciting, as a club I attended at the time regularly ran NERF wars.
The NERF Centurion. In reality it was a bit underwhelming, because the internet is incredible at hyping things up.
Curious to determine the dart’s size, I went to work on a ballistics calculator. I figured that the size they chose would optimized for the expected spring energy of the blaster. I was looking for that sweet spot of maximum range as size varied. There were, admittedly, several layers deep worth of speculative numbers used. Many specifications were simply madeup. By observing the output graphs, the optimum dart size was determined to be 2.0cm in diameter and 3.4g in mass. By some stroke of luck, the many assumptions used in the calculations yielded a shockingly accurate figure. The actual MEGA darts that were eventually produced were in fact 20mm in diameter. Mass readings on them are hard to find, however, so I have yet to determine the accuracy of that figure. You can see the report I wrote on the matter here. It was written in freshman year and I had not yet learned how to write a proper report, so forgive it if it tries to sound smarter than it is.
Regardless, the ballistics calculator proved to be a very interesting script. It worked through an iterative function- calculating the various forces acting upon the projectile and adjusting the acceleration, velocity, and position appropriately as each time unit ticked by. It was in fact an Euler approximation method, as coarse or as fine as you determine your computer has to deal with.
This gives you a trajectory!
Now, the fun part is that in the loop function, you can put as many forces, functions, calculations, etc. as you want. I ended up keeping track of velocity components as well as projectile energy (kinetic, gravitational, and total mechanical) all as functions of horizontal position, tracking along with the projectile!
Using this calculator as is, I was able to determine necessary design specifications in my water balloon launchers, in particular the elastic bands’ dimensions, given an intended effective range.
A modified script was later made for the water balloon launchers. I wanted to determine firing solutions at various ranges. The script was modified in a few ways. First a target was included, modeling a reasonably average person, shy of 2 meters in height. To model the splash damage (hahaaa), I simply included an area in front of the person to count as a hit as well. The simulation ran a series of ranges of the target, from point blank to beyond maximum range. At each range point, the script would simulate a series of trajectories, determining which ones hit and which ones did not. It was in fact quite inefficient and took a number of minutes to finish calculations, but it worked well enough that I liked it, and developed firing solution charts with them.
Firing solutions of the Mk2 Wasserfaust launcher
Lately, I have used MATLAB for the Davis Robotics Team. I had used it to write an algorithm for motor control software. We were at the moment pursuing an underwater ROV design which required a set of eight motors to drive it in the 3D environment. Luckily as it was not a spacecraft we could safely eliminate a number of axes of freedom.
The design used a slight offset angle for the horizontal motors, which increases maneuverability while keeping the number of motors low. The structural designers knew more of it than I, to be honest. Anyways, we needed to be able to derive individual motor input signals from directional and rotational inputs. The algorithm would calculate thrust for a unit of directional input, before normalizing the signals against the total thrust, resulting in thrust inputs as functions of relative power distribution. With these outputs, they can easily be adjusted to whatever available power we have on hand while maintaining your intended heading and directional inputs!
A simple underwater ROV. Our design was to be far more ambitious.
A smaller project was for a bell crank transmission in a control input. As a side project I was looking into making a control yoke for the robotics team, and possibly for video games as well. Looking at the various sensors possible, I decided that control linkage to a linear potentiometer would be the most direct, sturdy, and precise system. However, it would require a bell-crank, which is approximately linear for some of its travel, but as the angle increases it becomes nonlinear. I wrote the script to determine the linear translation of the potentiometer as a function of control input angle. Using this, I was able to determine a range of relatively linear, precise control given the dimensions of the control linkages.
An example of a control yoke. This type is under consideration due to its simple and rugged design.
Blue is the actual translation- green is linear, used for comparison. The red is the difference between the two, and the teal is the restoring moment from a spring on the crankarm.
MATLAB has continued to prove itself as a powerful tool in engineering, and I will likely encounter much more use as my education and potential career continues.
Various Projects of Tim Cuatt 
