Portfolio & CV

– Copy

Fri, 17 Oct 2025 04:44:58 +0000

Ocean Current Data Logger

Objective Summary

Build an ocean current data logger for a coastal profiling float, a floating robot that measures long term oceanic chemical changes.

Further Background

This requires a lot of context, so buckle your seatbelt.

I spent a summer working at the Monterey Bay Aquarium Research Institute (MBARI), a nonprofit oceanic science and engineering research facility affiliated with the Monterey Bay Aquarium. One of the flagship projects of the institute is managing a network of profiling floats across the world’s oceans. These floats, of which there are thousands of, repeatedly cycle within a depth column in the ocean.

Once every few days, the bladder of the float deflates, causing the float to increase density and sink to the ocean floor. Thereafter, upon inflating, they rise to the surface in a water column while taking rapid measurements of ocean data such as nitrate, oxygen, fluorescence/backscatter, and much more. They report this data to a satellite and continue in this life cycle for many years. This network of floats helps scientists to collect long term data on the health of the world’s oceans. See more info about these floats on MBARI’s official website here: https://www.mbari.org/news/new-coastal-profiling-floats-for-diagnosing-ocean-health/

A specific variation of these floats, called coastal profiling floats (CPFs), are designed to specifically operate along the coasts (as coasts are often the most biologically diverse areas of the oceans). However, since these CPFs are not tethered and do not have thrusters for lateral movement (they merely can change density), they experience large amounts of lateral drift in the oceans throughout their lifetimes. They are at the whim of surface currents. This is particularly problematic near the coasts, as these floats have a high likelihood of being washed ashore and rendered useless.

The first step towards this solution is developing a data logger to accurately and precisely measure ocean currents. That was my task.

Process

Electrical

A high-end industry-grade IMU with high precision/accuracy, the VectorNav-100, was chosen, as swings in ocean currents tend to have very small magnitudes. It was wired to an STM32 Nucleo Board with an SD card shield for data logging. Power was provided with a 2S Lithium Ion battery and voltage was stepped down with a linear regulator with smoothing capacitors; a fuse was added for safety. A USB breakout was added for data access and programming ease.

Mechanical

I designed the holder for these sensors in Solidworks and installed everything into a watertight cylindrical pressure housing. Afterwards, I performed helium leak testing to ensure proper sealing of the device.

Software

The main challenge with software implementation was that the logger must simultaneously be reading new values from the IMU and writing these values to the onboard SD card. However, doing both data reading and writing simultaneously without any fancy multithreading/parallel computing is difficult. Thus, I implemented a simple double-buffering scheme, in which new IMU data is read into buffer A while the data already in buffer B is written to the SD card. Once the write operation is finished, buffer B will start collecting new data while buffer A writes its old data to the SD card. This dance continues back and forth perpetually.

See this guide for more info on double buffering: https://wiki.osdev.org/Double_Buffering

Testing

To validate the efficacy of this data logger, I needed to test accelerations against a known truth. A clever way to do so is by attaching the logger to a pendulum (which naturally creates accelerates according to a sinusoid) and comparing the captured accelerations against those predicted by Newton’s laws. Results are seen here (after some low pass filter signal processing was done in MATLAB’s filtering toolbox), and the measured accelerations do indeed match predictions.

My internship time elapsed before real-world ocean testing could be done, but I suppose that is a fitting challenge for the next intern.

If you are interested on reading more about the specific technical details in this project, please read my final paper about this data logger here: https://www.mbari.org/wp-content/uploads/Siskind_Jay.pdf

Tue, 07 Nov 2023 07:39:27 +0000

Polar Rover

Objective Summary

Build a GPS-navigated, autonomous, solar-powered rover to navigate from the Antarctic coast to the South Pole and back.

Further Background

Stanford Space Initiative is the largest engineering club at Stanford with hundreds of members. The club is split into seven subteams. I am co-lead of the Mars team, which is focused on Mars-based technologies and projects. We anticipate that in the near future, NASA will aim to explore the surface of the Martian polar ice caps. Thus, I am leading a project to construct a rover that will use Antarctica’s terrain as an analog for this Martian environment. I run the team of 20 active engineering students, and I operate my team’s annual budget of $15,000.

See our Wiki: https://ssi-wiki.stanford.edu/Category:Mars

Design Considerations

Ground resupply vehicles have to consistently travel from McMurdo Station at the Antarctic coast to the Amundsen-Scott Station at the South Pole. They follow a well-charted path called the Antarctic Overland Traverse. Our rover will use GPS waypoint navigation to follow that exact path.
Solar power is the only consistent, long-term energy source available to us in Antarctica. However, the sun only consistently shines during the Antarctic summer, which lasts from October-February. Thus, that is our window to depart and return from our journey.
The sun stays relatively low to the horizon during the entirety of the summer. Thus, we need to mount the solar panels nearly perpendicular to the ground. This is not shown in the current prototype rover, which is only meant to operate in California.
We need internet to livestream video from the rover back to us at Stanford. Thus, we use a Starlink satellite internet atop the rover.
The rover will be primarily autonomous. We will use GPS for a long-range pre-planned route and LiDAR short-range path planning and object avoidance. However, we anticipate that things can and will still go wrong (i.e. the rover will divert from its path, might get stuck in the snow, etc). Thus, we will route Starlink internet into a Jetson Nano in order to SSH in and take manual remote control of the rover (from back at Stanford) whenever necessary.

Map of the Antarctic Overland Traverse

Visual of the Antarctic Overland Traverse

Process

We first built a small, prototype rover to test essential capabilities. This rover was built atop an off-the-shelf hobby-grade RC vehicle kit. We heavily modified it to include GPS waypoint navigation, thermal insulation, and rudimentary sensor data (temperature, velocity, and heading). Furthermore, we toyed with adding a 2D LiDAR module to add rudimentary path-planning, but we then decided to save this step for work on a later version of the rover. This prototype rover is several orders of magnitude smaller than the more recent iteration of the rover we built later on (see below), which is to include a more complete suite of capabilities.

Seen here: I designed and 3D printed a waterproof enclosure for the prototype rover’s essential electronics. This enclosure has easily removable latches and an A-frame roof to mount small solar panels and to prevent rainfall accumulation on the roof. We padded the interior of the enclosure with thermally insulating padding and a rubber gasket for a watertight seal. The LiPo battery, ESC, RC receiver, internet module, and more fit within this enclosure.

Seen here: we are testing the rover’s navigation with a figure 8 path that was programmed into the Ardupilot mission planner software at a retreat at a team member’s house in Portola Valley. We physically drew out a figure 8 pattern on the map within APM, and the rover followed that path using its GPS module. Pardon the sideways wheelie!

We continued on to the next phase of the project: construction of a 1:1 scale rover. The chassis was built atop a heavy-duty electric wheelchair frame with all unnecessary components removed. We received help from Cislune, a small aerospace startup, for help with this stage. The wheelchair base runs on two 12V lead-acid batteries. It is 2WD (the main tires in the center) with suspension and has four passive casters at the corners. We soon aim to replace the casters with a more snow-capable option. We even considered modifying the drivetrain into a tracked/treaded system, however I anticipate that will be quite the challenge.

Seen here: a Cislune custom PCB with an integrated Teensy microcontroller that enables external interfacing with the rover’s control systems. We wired this PCB to a Pixhawk module to allow for control via autopilot software. We had to troubleshoot a significant amount of software issues with the Teensy before we managed to get it working. We first had success with teleoperated control (directly driving the rover via an RC transmitter).

Seen here: we next enabled GPS waypoint navigation on the larger rover. We are driving the rover around Stanford’s engineering quad at night purely by clicking points on a map. Yellow marks the planned path, and red marks the actual path traveled.

Seen here: we recently installed two 200W solar panels on the sides of the rover using aluminum extrusion and brackets for mounting. We also integrated a solar charge controller module to scrape crucial specs from the power system, including battery voltage, charging rate, etc. Now, the rover is fully rechargeable and power-independent. The panels seen to the right are mounted at approximately a 45 degree angle for use in California. However, when the rover is taken to Antarctica, we will adjust this angle to be nearly perpendicular to the ground to account for the sun’s position close to the horizon when near the poles.

In late 2024, our team decided to adopt a new approach to the rover’s drivetrain by using a treaded pattern instead of wheels for a multitude of reasons; primarily due to a treaded vehicle’s superior ability to drive on snow and rough terrain.

This was a drive test with lots of electronics equipment jerry-rigged to the top of the rover. This equipment includes multiple MCUs, a Pixhawk controller, a power inverter, motor drivers, and a GPS comms device. Later (not seen) we even attached a Starlink dish to the top of the rover to enable internet comms.

We are currently in the process of revising the rover drivetrain yet again. We swapped out the wheelchair motors entirely for the powertrain assembly that was salvaged from an electric snowmobile on eBay. However, the snowmobile used a hydraulic braking system, which is messy and very mechanically complex. Instead, I suggested that we develop our own innovative braking system, using an high-voltage electromagnet that magnetizes onto a waterjet-cut steel disc on the powertrain motor shaft to stop rotation on either side of the driveshaft (allowing for either turning or braking). Here is a demo of us testing this braking concept.

Next Steps (as of March 2025)

Progress has been steady, but there is still much work to be done on the rover. Immediate next steps include:

Finalizing the mechanical design for a new cohesive drivetrain.
Integrating the Starlink module for internet live streaming.
Interfacing the rover’s PCB and Pixhawk autopilot module with a Jetson Nano.
Integrating LiDAR onto the rover for basic object avoidance and path planning.

Mon, 06 Nov 2023 07:39:59 +0000

Ocean One Handheld Camera

Objective Summary

Construct a handheld camera to be used by a humanoid robotic avatar for a diver for use in deep-sea applications.

Further Background

I worked part time during the academic year and full time during the summer as the only undergraduate student in the Stanford Robotics Lab. I primarily worked on Ocean One K: the flagship project of the lab.

Ocean One K is an underwater robot meant for deep-sea exploration in difficult-to-access locations. Deep sea conditions have water pressures that are unsafe for human divers, so the ‘K’ in Ocean One K represents its capability to reach depths of up to one kilometer. The front half of the robot resembles the human form, with a pan-tilt actuated head with stereo vision and two arms with 7 DoF. The robot is teleoperated via a control station on a ship above the surface; commands are communicated to the robot via Ethernet tether. The robot’s grippers provide real time haptic feedback so that the operators can quite literally feel what the robot is touching.

The robot’s large frame prevents it from being able to explore certain tight spaces, such as the interior of the plane wreck in the image shown below. To accommodate this shortcoming, the graduate students of the Stanford Robotics Lab previously developed a camera on a long handle (seen below) to be held by Ocean One K to allow the operators view otherwise inaccessible areas underwater. However, this first iteration of the handheld camera was quite limited in its functionality, so over the course of 8 months, I implemented a series of upgrades to the camera.

Upgrade 1: Improving Camera Startup Reliability

One of the previous difficulties with the camera was that it was quite unreliable upon booting up. Even when powered on, the old camera would often fail to record videos when prompted to. To resolve this issue, I implemented a menu with an OLED screen and a push button selector inside the camera housing to give the user more control in initiating the camera to start and pause recording through adding significant amount of Python code to the Raspberry Pi’s camera scripts.

The image to the right shows the mini OLED screen showing the camera’s recording status along with the filename that the current recording is being saved to on the Pi’s microSD card. The buttons to the left and right of the screen allow the user to pause and resume recordings at their will. Note: this can only be done above the surface, as operating these buttons requires opening the camera’s waterproof seal.

Upgrade 2: Underwater Lens Distortion/Blur Correction

A previous issue with the camera was that the recorded footage was distorted, blurry, and overall difficult to discern. While the above-water footage was crisp, the underwater footage quality was less than poor. After consulting with some experts in underwater vision, I realized that water around the domed lens distorts the video quality if the lens is not adjusted properly (the aperture of the lens must be at the centerpoint of the sphere made by the dome). I developed a test rig to test 3D-printed spacers to separate the dome from the camera frame in order to center the aperture. After realizing that these spacers did not solve the issue, I instead re-adjusted the lens to focus within a 3-meter range underwater (at the cost of the sharpness of above water footage).

Now, underwater footage of objects within a close to medium range is crisp and clear. This video to the right shows a test of the newly focused camera in a pool test underwater. We used a checkerboard pattern to test the focus of the camera; the footage shows that the edges and corners are distinct and crisp – much more so than before. Funnily enough, gaining focus underwater results in losing focus above water. However, since this is meant to be entirely an underwater camera, that was a tradeoff I was willing to make.

Upgrade 3: Roll Stabilization

When Ocean One K holds the handle of the camera, even the slightest induced moment would often cause the camera to roll within the robot’s grasp, causing the camera to no longer point towards where the operator intended. This could be due to any number of factors, such as the slightest undersea current or a minor adjustment in the robot’s grip or hand orientation. Nonetheless, I aimed to minimize this unintentional rolling by adding targeted weights to the camera so that the center of mass and center of buoyancy coincide. Thus, no matter where the camera is pointed, it would theoretically be able to hold its position naturally without rolling to a default state.

In order to find these two critical points, I used two different methods. I found the center of mass experimentally by hanging the camera from various different positions and finding the intersection point of the vertical cords, as shown above. To find the center of buoyancy, I used Onshape CAD to find the center of mass assuming constant material properties throughout the camera model. This can be done because the center of buoyancy can be assumed to be the same as the center of mass if the entire volume of the object is substituted with water.

The image above shows that the center of buoyancy (checkered point) is slightly in front of the center of mass (blue point). Thus, to make the two overlap, I had to add a handful targeted 1oz iron weights to the bottom front of the camera. The video to the left demonstrates this upgrade working in action. The intention is that when the camera is dropped underwater; the camera should not roll, spin, or sink – instead, it should just hover in the water neutrally. This pool test shows this being executed to a level of fine precision. It is not perfect – but it is quite close.

Upgrade 4: Live Camera Feed Implementation

One of the most pressing challenges with the old camera was that it was impossible to view its footage in real time — the recordings were stored to an SD card which could only be retrieved after the robot surfaced.

To solve this problem, I implemented the ability to view the camera feed live. Since high-bandwidth wireless camera signals cannot penetrate water, I instead wired a micro USB cable out of the Raspberry Pi through the back capsule of the camera. This cable is adapted to ethernet before being tethered to a network switch at the surface so the operators can view the camera’s livestream over Flask. This greatly improves the operator’s perspective when controlling the robot in confined spaces underwater.

This video shows a demonstration of the live camera feed at my poster session presentation. The feed on my laptop displays directly what the camera is seeing. The diagram below shows the surprisingly complex system that enables this functionality in actual use cases for Ocean One. The Raspberry Pi records video through the camera module, and it outputs this video stream through a micro USB to ethernet cable adapter. The ethernet cable must route out of a waterproof cable penetrator out into the open water. This cable then runs into the rear electronics cylinder of Ocean One, where it plugs into a network switch and merges its live camera stream with the rest of the data that Ocean One sends to the surface. Finally, it can be streamed onto a monitor at the surface.

Poster

Seen below: my poster for the final CURIS summer program poster session. Most of the text is the same as what you already read above.

– Copy

Sun, 05 Nov 2023 19:43:00 +0000

Arm-our

Objective Summary

Use various machining/manufacturing methods to build custom metal armor!

Further Background

Many years ago, I built a wrist-mounted flamethrower (which can also be found on this portfolio site). I wanted something awesome that I could mount it on – hence this Mandalorian-inspired metal armor!

My design criteria were three-fold:

Should not severely limit the user’s range of motion.
Should be relatively comfortable to wear.
Should be easy to put on and remove.

Process

I started by prototyping the general feel for the armor out of cardboard in order to get rough dimensions and to figure out where to locate the elbow hinge.

I modeled the entire gauntlet in Autodesk Fusion. The main structure of the gauntlet was designed in Fusion’s sheet metal environment, while the pauldron and hinges were done with standard solid modeling. Below are examples of one structural element designed in the sheet metal bending environment.

Elbow hinge brackets were done on the Bridgeport mill using an endmill, edgefinder, hole-cutting bits, a reamer, and angle blocks.

I used a manual lathe to machine the hinge rods from aluminum stock.

I used the PRL’s waterjet to cut the gauntlet structure from the CAD DXF’s onto 0.09” 6061 T6 aluminum sheet.

Seen here: These parts were each bent precisely to 120 degrees on the finger brake. Due to initial imprecision, I had to redo these parts several times to ensure a perfect fit.

In order to sandcast the pauldron, I had to first make the pattern itself along with the gate/runner and follow block. They were each designed in Fusion and 3D printed.

Seen here: I next needed to ram up the pauldron for a molten aluminum cast (right). I only had time for one ram-up, so I had to make it count. Lots of time was spent in “post” to clean up the part. I primarily used a Dremel rotary tool with a carbide bit for this rework (seen below).

I press fit M4 pem-nut threaded inserts into the aluminum so butterfly latches and hinges could be mounted to the gauntlet. This way, the gauntlet can open and close for easy installation by the wearer.

The finish was sanded down to 320 grit and then bead-blasted. The inside was lined with ¼” neoprene foam padding for comfort. Outlines for the “trace pattern” were made using an automatic vinyl cutter.

Seen here: This is the armor in its fully expanded configuration. In this configuration, it is easy for the user to slide their arm into the gauntlet before latching the butterfly latches shut.

Sun, 05 Nov 2023 08:23:37 +0000

Milling Around: A Demonstration of the Geneva Mechanism

Objective Summary

For my Foundations of Product Realization class: design a machine that can move wooden blocks a distance of at least 18 inches horizontally and 8 inches vertically using a unique mechanism. At the end, all the machines were to be lined up to pass said wooden blocks from one end to the other, similar to a Rube Goldberg machine.

Further Background

As you might be able to tell, the project constraints were quite open-ended. Thus, I personally decided to “go big or go home” – I desired to make a machine that would stand out among the rest, almost like the London Eye amidst the River Thames. I decided to find a mechanism that could generate intermittent rotational motion, similar to the ticking second hand on a watch face, to move wooden blocks across a watermill-like path. To help my machine stand out from the rest of the class, I also knew that I wanted to motorize it.

Process

My first idea to generate intermittent rotational motion was to use offset gears. I got this idea from the Brick Experiment Channel on Youtube, as shown to the right. The driver gear has an off-center axis so that its center rotates around a circular path. Once that path meshes with the driven gear, the assembly attached to the driven gear completes a fraction of a rotation.

As per class instructions, I constructed a cardboard prototype of a simple machine using this mechanism. This prototype demonstrated that an offset gear mechanism would not be effective at generating the desired intermittent rotational motion, as there was slippage between the gears when they were not in contact. The assembly attached to the driven gear would be free to move when the gears were not meshed, which resulted in imprecise motion.

Instead, I pivoted to the geneva drive mechanism. This clever mechanism is used to generate intermittent rotational motion in plenty of real world applications, such as in the second hand of a mechanical watch or in the rotating tool changer of a CNC mill. Its unique geometry also prevents it from running into the same issue that the offset gears had.

I planned to use a spare bicycle wheel as the centerpiece of this machine; the wheel would mount to the driven gear of the Geneva mechanism. I would mount plastic carriages across the circumference of the wheel to carry the wooden blocks across the path. Everything would be mounted to a duron frame held together by a bunch of fasteners.

I subsequently modeled the entire machine in Fusion 360.

Next came the assembly of the machine. Duron parts were laser cut, 16 plastic carriages were printed out of PLA, and a bunch of metal fasteners were gathered. Assembly took far longer than I expected, – maybe 20-30 hours total, due to some of the challenges explained below.

Some challenges I ran into:

The machine was very front heavy and cantilevered forwards. I screwed a large wooden 2×4 block into the back to offset this cantilevering.
Stanford’s Product Realization Lab did not have a proper shaft coupler adapter that could fix the motor shaft to the 0.25’ D-Shaft that drove the geneva mechanism. I first tried to 3D print a custom shaft coupler adapter. That worked for a little bit; but it eventually failed due to mechanical strain. I subsequently ordered a proper metal coupler adapter online that solved the issue.
A 3D printed peg on the geneva driver gear snapped off due to mechanical strain as well. I solved the issue by drilling a hole through the location of the peg and replacing it with a short aluminum rod. I then fixed the rod in place using a heat set insert and a set screw.
Because of the sheer amount of mass that the machine had to rotate, it generated a huge amount of angular momentum that would cause the Geneva driver gear to slam into the driven gear every “click”, and it would bounce back a bit (similar to gear backlash). I resolved this issue by slightly enlarging the driver gear so that it would fit snugly into the driven gear, leaving minimal room for any bounce back.

I am quite satisfied with the resulting machine. It ended up being the only motorized machine in the entire class! See the videos below:

Sat, 04 Nov 2023 07:04:29 +0000

Remote Controlled Submarine

Objective Summary

Build a remote controlled submarine that can explore neat underwater environments.

Further Background

At the end of high school, I needed a summer project that I could work on for fun. This is what I ended up choosing!

Note: this project ended up being ten times more challenging than I originally anticipated. I ran into a plethora of problems, some of which I am still working on resolving to this day (3 years later).

Throughout the process of working on this project, I’ve burned through probably at least $1,000, released toxic ABS fumes into my entire basement, accidentally set a fire to an electronic speed controller, called poison control at 3AM in the morning, and almost turned my submarine into a deadly weapon that collided into several children during a public pool test run. It has been quite the journey.

Process

The submarine operates on a differential steering system; using two hobby-grade brushless DC motors controlled by two electronic speed controllers wired up to an RC receiver. The system runs off of two 3S LiPo batteries. The image to the right shows my attempt to use a single brushless motor with a servo-controlled rudder, however that was unsuccessful. Images below show two separate motors on either side of the plastic rear.

I use a custom ballast system for depth control. Inside of the submarine lies a large syringe, and it is attached to a linear actuator that is connected to the RC receiver. The syringe pumps water in and out of the submarine to control its density; the submarine’s mass is calibrated so that when the syringe is full of water, its density is >1 so that it sinks, and when the syringe is expelled, its density is <1 so that the sub floats. Note: the video to the right shows an earlier version that uses two 100mL syringes. This was later replaced with a single 0.5L syringe.

All the internal systems fit within a long 3D printed internal assembly that easily slides into the submarine housing. I like to call this assembly the “guts” of the submarine.

From the top to the bottom of this internal assembly:

Ballasting weights.
An endoscope camera and some RC-controlled lights get a live feed of what the submarine is seeing underwater.
The linear actuator/syringe ballast system.
The two 3S LiPo batteries.
The two ESCs and some more ballasting weights.
The old version of the 3D printed end cap of the submarine. It was sealed with a large O-ring gasket, which I later discovered was insufficient.

This entire internal assembly slides into the “sheath” housing of the submarine, which is primarily made of a large diameter PVC pipe that is capped by some 3D printed parts. At one end, there is a clear half of a plastic Christmas ornament dome that serves as a viewing window for the endoscope camera. At the other end, there is the opening to slide in the internal assembly.

The image to the left is an older version of the submarine. However, in my newer version (not pictured), the rear opening is capped by a screwable watertight PVC pipe plug when ready for use. This pipe plug solution took me probably 6 months to arrive at; everything else would leak some amount of water into the hull. And you know what happens when water and electronics mix.

Progress (as of Dec 2023)

The submarine does in fact look somewhat like a submarine. To my chagrin, my non-engineering friends also tell me that it looks like a ballistic missile.

The last time I tested my submarine in a body of water (the Stanford public swimming pool), the submarine turned into a torpedo and ran into several small children. I was subsequently kicked out of the pool by the lifeguard. I will post a video of the submarine working here once I figure out how to avoid this undesired outcome.

Continued Challenges

The submarine goes way too fast. I will either modify settings on the RC transmitter to slow down the motors, or I can add resistors in series with the motor. I may also attempt to do a fancier solution and mess with PWM.
The submarine’s turning radius is massive. It also does not go backwards. To reduce the turning radius, I might attempt to reintroduce a rudder.
The plastic dome on the front of the submarine is very brittle and will certainly shatter upon the submarine impacting something at high speed. Thus, I will replace the dome with something sturdier before this happens.
I know that RC signals do not penetrate water at all. My previous naive solution was to keep the RC transmitter inside the submarine hull and splice in some long wire before the antenna so that the antenna would float above the surface on a buoy. Unfortunately, this does not work, as the entire receiver, not just the antennas, have to be above the surface of the water to ensure a stable connection. However, a large amount of different wires (from the DC motors, linear actuator, lights, etc) all have to connect to the receiver. Thus, I will need to keep the entire receiver above water in the buoy and have a 12-cable tether running from the submarine, through the open water, and into the receiver. Unfortunately, 12-wire shielded cable is incredibly expensive.

Fri, 03 Nov 2023 07:26:42 +0000

Wrist-Mounted Flamethrower

Objective Summary

Build an Iron Man-like flamethrower that I can strap to my wrist. Why? Cause why not?

Further Background

I was bored during Covid lockdown. What better way to spend my time than to build a flamethrower?

Process

When I press a button trigger beneath my finger, the device fires compressed butane stored within a series of pipe fittings at a modified electric windproof arc lighter. When the aerosolized gas hits the arc, it combusts into flame. My design considerations included making everything one-handed, having enough fuel capacity to launch multiple bursts of flame, and ensuring all obvious safety precautions were in place.

Seen here: the electronics behind the flamethrower. I disassembled an off-the-shelf windproof arc lighter to replace its switch with one of my own. Furthermore, I use a 6V solenoid valve to open and close the flow of butane through the system. Everything is powered by a handful of AA batteries. In the electronics demonstration to the right, the first device shown is the modified arc lighter, and the second device shown is the solenoid valve (each click is the solenoid opening/closing). I use a random switch from an electronics hobby kit, but in the final product, a momentary double pole double throw (DPDT) switch activates both the arc lighter and temporarily opens the solenoid valve at the same time.

The mechanical hardware within the flamethrower is quite simple. I used a fireproof BBQ glove inside of a wrist brace cast for injured arms as the apparel to mount all the components. Heat-resistant JB-Weld steel-reinforced epoxy was used to fix a series of pipe fittings (nozzle, regulator valve, solenoid valve, etc) and aluminum brackets to hold everything in place. All the various electronic components were simply zip-tied to convenient locations away from the flames.

Safety Notes

I included a handful of precautionary procedures for safety reasons.

There is a backup redundant safety switch in the battery holder just in case the main trigger discharges when unintended.
The front half of the flamethrower is completely devoid of any flammable material.
I made the flamethrower extremely easy to remove, just in case any flames crawl back up the device and onto my clothes.
I always made sure to fire the flamethrower INTO the direction of the wind, and never against it.
I always kept a fire extinguisher on hand just a few feet away when operating the flamethrower.

Wed, 01 Nov 2023 07:39:04 +0000

Contactless Candy Dispenser

Objective Summary

For my Introduction to Mechanical Engineering Class: build a prototype for a Covid-safe dispenser for small candies. Candy amounts should be consistent for each dispense. See video below:

Further Background

This was the final quarter project for my introduction to mechanical engineering class; we had only 2-3 weeks for the project. I was in a group with 2 other members. We delegated the work so that I would CAD and assemble the machine and they would work on the presentation aspects. At this point in time, most of my classmates had very minimal technical experience with CAD or building things in general. However, I already had a significant amount of background with such skills, so I wanted to go above and beyond with this project. While most people in the class chose to construct their project out of cardboard, foam, and hot glue, I wanted to go one step further. My device was to be 3D printed with electromechanical actuation.

Process

I designed this machine to operate in a manner similar to a contactless hand sanitizer dispenser. Once a hand is detected within a certain distance from a sensor, a fixed amount of product is deposited.

Candies rest upon the top storage compartment “hopper” of the machine. Once a hand is placed underneath the hopper, it is detected by an ultrasonic sensor that opens a small “trap door” underneath the hopper for a fixed amount of time (a fraction of a second) to allow a consistent amount of candies to fall through.

Seen here: a test using some basic code to operate the Arduino portion of this device.

Seen here: I designed the device so that it could almost entirely be 3D printed in one piece. There are just two small separately printed components: a small plastic trap door attached to the servo and a plastic panel underneath that houses the Arduino Uno.

The servo is screwed into the top (right above the opening for the hand, right behind the text on the front) while the Arduino and ultrasonic sensor sit underneath (right below the opening for the hand, underneath the two holes for the sensor).

A clear plastic half of a Christmas tree ornament is used as the dome window to view the candies. It swivels to the side to allow candy to be refilled once the machine’s supply is depleted.

Seen here: I had to route an internal tunnel through the back of the machine so that the servo motor wire at the top could plug into the Arduino at the bottom. This sliced section view in CAD shows the internal tunnel that the servo wire takes; it is completely unnoticeable from the outside. The wire is fished through and connects the servo at the top gap to the Arduino in the bottom gap.

Poster

Seen below: my group’s poster for the end-of-class poster session.

Mon, 30 Oct 2023 07:08:00 +0000

Gesture-Controlled Robot Arm

Objective Summary

For the final project for an embedded systems class, a friend and I built a gesture-controlled robot arm.

Further Background

At Stanford University, CS 107e is an infamous course. It is a spinoff of the course CS 107, which is the intro systems course required for all CS majors. 107e is different from 107 because it is more selective, has a more-hands-on focus, and generally attracts a crazier breed of student.

Throught 107e, each student programs an entire computer from scratch in C, taking a Mango Pi Risc-V bare metal board and turning it into a fully functional computer with a custom graphics library, keyboard driver, shell, and more, even implementing functions such as printf() and malloc() from scratch with no libraries. This is all done in 8 weeks. For the final 2 weeks of the course, partners are matched to build a final project of their choosing that uses the skills learned in the course. My partner (Aditri Patil) and I decided to build a gesture-controlled robot arm. Two weeks is not enough time to build a fully-flushed out functional product, so we treated it more as a proof-of-concept challenge.

Process

The general idea for this arm is for the user to wear a sleeve of IMUs on their arm; there is an IMU on the back of the hand, forearm, and upper arm. The angle of IMUs with respect to each other corresponds to the bend angle of the servos of the robot arm. Thus, the robot arm matches the real time movements of the user’s arm; almost like an imitating twin.

There are ways to fancify this, such as using a Kalman filter, but that was beyond the scope of this project.

Since this was a software-focused class, we focused on the software. The STL files for the 3D printed arm were simply found from the internet: https://www.printables.com/model/818975-compact-robot-arm-arduino-3d-printed

The software challenges for this project were multifaceted and complex. Since this was a systems based class with no pre-given libraries, we had to implement each library/module entirely from scratch.

We wrote a custom PWM (pulse width modulation) library to control servo movement, a custom IMU (inertial measurement unit) library to read accelerometer and gyroscope data from the IMUs, and a custom I2C (inter-integrated circuit) library for communication. Finally, we went through a bit of integration hell to combine all this together. We spent several all-nighters in the lab debugging all of our issues, but the following video shows our results:

Obviously, it is not the smoothest robot arm ever, but that is not the intention. From a systems level, we implemented everything well, and we are even able to draw abstract art with a sharpie!