Michael Ho Portfolio

I am an engineer, a tinkerer, and a cyclist. I have a background in Computer Science, but I work on interdisciplinary projects that bridge mechanical design, software, and hardware. I am a team builder – I enjoy inspiring others and promoting idea generation and collaboration.

Technical Focus

Embedded Systems

Wireless Sensor Networks

Manufacturing

Github Profile: http://github.com/MichaelHobo

Wireless Sensor and Actuator Network
Duration: 8 months
3rd Year Undergrad
Human Powered Vehicle created a wireless network that would connect and coordinate actuators and data logging applications with sensors.

I worked on creating a modular and extendable Arduino and mBed codebase that would handle an arbitrary number of wirelessly attached devices, and could be easily scaled as we increased the number of nodes.
Wireless Data Transmissions
All sensors and actuators communicated using RF24 radios. We wanted to solve a few issues using wireless communications:

· Scalability - A comparable wired implementation is more difficult to scale because you eventually need more hardware, and we wanted to support 20+ devices.

· Simplified routing - We could place devices in difficult places that would otherwise pose wire routing issues.

· Minimize wiring failure – Prevents us from damaging our electronics from accidentally yanking on the wires.
Scalable and Flexible
I implemented a simple addressing scheme where each device was given a unique address, which was used to identify each sensor.

We noticed that increasing the message size greatly decreased the transmission success rate, so we packed the address into the first byte, and then we used the second byte to store the data. This allowed for compact data transmissions and protocol support for 256 devices.
Fault Tolerance
Since our radios had a high transmission failure rate, we could not rely on the packet acknowledgements. We made sure that all our data was idempotent, and thus could be retransmitted multiple times without worry of causing undesired behavior. When a node does not receive an acknowledgement, it simply needs to resend the message.
Extended Battery Life
Many devices were in hard-to-reach places, so we wanted to decrease the need for battery changes. We wanted to put our devices to sleep whenever not in use, as long as it did not affect performance. For sensors, we noticed that they only sent data, so the radio could safely be put to sleep between transmissions. All devices turned off unneeded hardware such as unused timers and ADCs.
Easy to Program for New Members
The electronics team had 2 experienced members and 4 new members. I was in charge of teaching the new members how to program in C++ and with the Arduino and mBed APIs. Given this, my codebase needed to be as simple to use as possible. My codebase abstracted away wireless communications and addressing so that my team only needed to copy a template directory to create a new node, and all updates would be done through Git.
Crush and Shake Resistant Packaging
Close to the competition date, we discussed packaging for our devices. Since the vehicle would probably shake a lot, we needed a shake resistant casing, as well as a crush resistant packaging in case of a crash. We considered different adhesives, clip mechanisms, and ribbing structures, but decided that the fastest solution was to use plastic boxes.
Remote Live Data Plotting
I worked on displaying our gathered data live on the online live data plotting tool Plotly. The plotter would send data from the vehicle’s master controller to a remote computer via XBEE. The computer would then read the data from the serial terminal in a python script and send the data to Plotly.
Custom PCB Manufacturing
Duration: 3 months
4th Year Undergrad
I started experimenting with DIY board manufacturing in hopes of figuring out a reliable quick-turnaround, low cost method for quickly making sensors. I aimed to have a sensor integrated into a single board, which we did not do because of cost constraints in the past.
Lithography
All sensors and actuators communicated using RF24 radios. We wanted to solve a few issues using wireless communications:

· Scalability - A comparable wired implementation is more difficult to scale because you eventually need more hardware, and we wanted to support 20+ devices.

· Simplified routing - We could place devices in difficult places that would otherwise pose wire routing issues.

· Minimize wiring failure – Prevents us from damaging our electronics from accidentally yanking on the wires.
Chemical Etching
I implemented a simple addressing scheme where each device was given a unique address, which was used to identify each sensor.

We noticed that increasing the message size greatly decreased the transmission success rate, so we packed the address into the first byte, and then we used the second byte to store the data. This allowed for compact data transmissions and support for 256 devices.
Two failed etching attempts. Both used vinegar, hydrogen peroxide, and salt solutions.
Eagle Board Design
I learned how to use Eagle, and created layouts for a few test boards. I would print these layouts onto transparencies for photolithography.
Reflow Soldering
I used reflow solder to attach a few test components to my board. The results can be seen below. One component was offset by 1 pin due to misalignment during placement.
A relatively successful test board with no real use! I did not want to waste too many chips on a manufacturing test.
Silicon Wafer Manufacturing [EE143 Microfabrication]
Duration: 3 months
4th Year Undergrad
I worked in a group of 3 to manufacture a silicon wafer in lab, for the purposes of learning about the manufacturing techniques involved in IC manufacturing and silicon processing.
As a class, we learned and applied many techniques used in microfabrication. We learned about lithography, etching techniques, thermal oxidation, ion implantation and diffusion profiles, and metallization. We then applied these concepts in lab by creating a silicon wafer with a pre-designed pattern (the class was not focused on device design, but rather on device fabrication). Our devices were on the micron scale, and we employed techniques that were often outdated but still applicable to modern IC manufacturing.

Lithography
All lithography was done using contact masks, which works well for creating features on the micron scale.

Etching
We did not use any anisotrophic dry etch techniques, because none were available in our lab. We used buffered HF for most of our etching.

Channel Doping
We created our MOSFET channels using spin-on-glass, and we later characterized the diffusion profiles to determine our theoretical device characteristics.

Metallization
We deposited aluminum through vacuum evaporation.
After our final wafer was finished, we measured the devices we created to characterize the yield and success of our wafer and devices. These devices included resistors, MOSFETs of different sizes, diodes, inverters, and a nifty Batman symbol!
OK, there were also a few MEMS structures (suspended beams), but apparently no class has ever gotten them working - some residual stresses cause the suspended beam to curl upward.
CS194-5 Internet of Everyday Things Final Project
Duration: 1 month
3rd Year Undergrad
Our group created a "smart storybook" that creates a highly interactive storytelling environment using nearby wireless connected devices. Our storybook framework would replicate a story's scenes by actuating devices so that the environment is affected.
Protocol Development
As a class, we collaborated on new protocols for managing and understanding a host of devices. Throughout the semester, these evolved from simple developer-enforced classification schemes to a more full fledged query based framework called SMAP (Simple Measurement and Actuation Profile).

I worked on extending these protocols to make sense of relevant sensors in the immediate vicinity.
iPad Storytelling App
Our group modified a borrowed iPad storytelling app as our UI, so that certain button presses would query nearby bluetooth devices and send them to our central processing server.
Perceptual Actuator Engine
My main work was on creating a server application that would take information about currently available devices, then create the correct mappings from current page to desired devices triggered.

When a new story was started, it would run a query for all nearby devices, and send them to the Ruby on Rails application. The application would then figure out the best combination of devices that would fit the setting on each page of the story.
Results
We demoed a customized version of The Three Little Pigs using wireless interactive devices. With each huff and puff of the big bad wolf, our modified wireless fan would turn on. When the wolf fell into the vat of water at the end, a small space heater would turn on.

The most interesting part was the infrastructure. Each page flip would send a query to the server application, which would send out requests to nearby devices through all communication channels (SMAP, Bluetooth, etc).
TessellationOS Research at Swarm Lab
Duration: 5 months
3rd Year Undergrad
Tessellation is an operating system designed to help high performance computing applications run consistently by factoring out sharing resources with other processes. Tessellation isolates compute-heavy processes into lightweight Xen domains so that processes can be allocated dedicated resources.
I worked on creating communication between Xen domains. I read through a large portion of the Xen code base, and I started to experiment with connecting two Xen domains using shared memory regions and memory channels.

However, due to time constraints, I dropped out of the project to focus on Human Powered Vehicle.
CS162 Operating Systems Projects
Duration: 2 weeks each
3rd Year Undergrad
CS162 featured 2 projects where we improved upon and implemented features in an operating system named Pintos. We implemented interrupts and our own scheduler.
HPV Website
Duration: 4 months
3rd Year Undergrad
I co-designed and programmed the HPV Website. I created a website that was easy to upload content to using a file sync service.
My website infrastructure would parse files in specified directories and put them up with the correct styles. I then linked the files with the file-sync directory so that members could simply write templated text and they could easily post to the website. Photos, blog posts, and sponsor messages were all uploaded via the file sync service.

Unfortunately, our server failed unexpectedly before I had a chance to create a redundant server system, and we did not have funding to purchase new hardware.
Unix Systems Administrator
Duration: 1.5 years
2nd to 3rd Year Undergrad
As a *nix systems administrator, I worked on a variety of server maintenance tasks, as well as larger scale projects related to *nix based servers.
My first project was to explore database replication and redundancy. I concluded that any low cost redundancy mechanism we implement with our current resources will not remove the point of failure, and would only move it to a different point of failure.
Chain Reaction Android Game
Duration: 3 months
High School Post-Graduation
My first major programming project was a puzzle game called Chain Reaction. I did half the programming, including exploration into which game parameters were possible or impossible. We also drew the art ourselves, which was probably why the game was never released!
Hackathon: SLAMBot
Duration: 12 hours
1st Year Undergrad
My friend and I created a LEGO Mindstorms robot that would simultaneously navigate and map the room using a SLAM algorithm. Our robot was able to traverse the room and plot points using an ultrasonic sensor and a front bumper. Our robot would continuously map points using the ultrasonic sensor, and when it hit a wall, it would turn 90 degrees and also map the bump.

At the end of the 12 hour hackathon, our robot could map the room and send the data for display on a computer. However, we did not get a chance to take the data and generate a visual map.
Hackathon: Android Fruit Ninja Remote
Duration: 24 hours
1st Year Undergrad
My group emulated a WiiMote to play Fruit Ninja using an Android phone. Since we did not have a Wii available, we opted for a browser version of Fruit Ninja, and the phone controlled the mouse within a bounding box on the game screen.

Since we did not have an IR sensor array available, our sensor data was entirely based on accelerometer data, and we could not find position based on pure acceleration. So, we used the accelerometer data to generate an angle, and then had the mouse replicate a slash across the entire playing screen.
Hackathon: Project Evolution
Duration: < 12 hours
1st Year Undergrad
My friend and I designed a human evolution simulator in Java. We created a mating algorithm that attempted to simulate how humans would react to their environment and choose mates based on their surroundings.
Hackathon: Distributed Speaker System
Duration: 24 hours
1st Year Undergrad
My team at AngelHack built a distributed surround sound speaker system by tying together devices over the internet using Firebase, a web "real time" syncing API.

I helped with early designs and testing the code, and I planned to quickly put together an Android app for the project if we had time. However, I did not know any Javascript at the time, so I did not do any programming for the main program.
Synchrony Lab Kinect Logger
Duration: Ongoing
4th Year Undergrad
I am working on a Kinect data logging application for use in the UC Berkeley Synchrony Lab. This application will complement a lab technician's work by allowing them to log their observations and then save reports alongside Kinect sensor data and video. Future plans include getting the application to compute movement synchony, to remove the biases of human coders.
Bike Turn Signal
Duration: 1 month
4th Year Undergrad
I made the first iterations of a bike turn signal that would be strapped to clothing, and would flash when users signaled with their arms.
Electric Scooter
Duration: 2 weeks, on hold
4th Year Undergrad
I designed a kick scooter attachment that would use an electric outrunner motor to push me up hills. Based on the hill gradients in my area, I found appropriate motor, battery, and controller designs and sizes that would give me the speed and battery life I wanted while fitting on a small kick scooter.
Electronic Bike Derailleur
Duration: 3 months, on hold
4th Year Undergrad
I am currently working on manufacturing an electronic bike derailleur for my bike.
UI Design Class Final Project
Duration: 1 month
3rd Year Undergrad
We designed and programmed the human-computer interface for our reconfigurable window interface. We performed user tests for our initial designs, then we implemented our application using a simulator.

Human Powered Vehicle Team Lead
Duration: 1 year
4th Year Undergrad
I run the team and I am striving to make the team more open, responsive, and conducive to innovation and learning. I am giving members more opportunities for face time with returning members, increasing channels of communication, and trying to incorporate everybody in the team into the entire design and manufacturing cycle. I am also pushing for more thorough testing so that our designs can be based on a more solid foundation of reasoning and data.
This is the team I'm in charge of! An awesome group all-around.
The new members perform their first carbon fiber wet layup on a sandwich core material. We taught them about composites theory and a basic layup process, then we split them into teams to do their own layup. Later, we used these panels to gather data from a 3-point bend test.
FireDrone Chassis - EE149 Project
Duration: 2 months
4th Year Undergrad
For my group's embedded systems final project, I designed and manufactured the chassis for our autonomous quadcopter. I designed 2 completely different frames - the first one was a super-light carbon fiber frame optimized for weight; the second one was a cheap, fast, and simple wooden frame optimized for low cost and quick production.
The first quadcopter's main structural material is carbon fiber applied as unidirectional tow, while the second one uses 1/8" wooden sheets.
Here is the main process:
1. 3D print 4 propeller protectors (pictured above)
2. Bond carbon fiber around it to make it more structurally sound
3. Attach them together with carbon shafts
4. Add a polycarbonate base for part mounting

To speed up manufacturing, I decided to do all of this work in my apartment room, because HPV's manufacturing facilities are 5 miles away, and not really mine to use for class projects.
Prior to starting the quadcopter project, I already made a carbon fiber part from a 3D printed plastic part using a food vacuum sealer instead of a standard vacuum, and it worked very well. For the test piece, I used carbon fabric.

However, I found out that carbon fabric, when wet with resin, becomes too stiff to wrap around the thin arms of the quadcopter, and the 3K twill fabric I was using would just destabilize, and cause a mess. As a result, I replaced fabric with carbon tow.

However, getting the carbon to tack was still difficult. As I applied carbon to one part of the propeller protector, the wet carbon would fall off from another part. I tried many different ways of getting the carbon to align that did not work:

- Resin dipped strands: misaligned very easily.
- Tape ends of strands before applying resin: the wet resin caused the tape to slip, misaligning the fibers.
- Wait for resin to partially cure: This only left me about 4 minutes to apply all the carbon, which was not enough.
- Tie the ends of the carbon to the frame: The carbon would still lose tension, and the carbon was misaligned.
- Place carbon strands on a piece of tape, dip plastic part in resin, and apply tape: the tape wouldn't stick to itself, and would slide.

Finally, I settled on a method that worked relatively well. I used double sided tape to stick the carbon strands to the plastic model, then I would apply resin and then vacuum bag it. This method had a few major benefits. It was relatively simple, and I did not have to race against the working time clock like I did with the resin dipped strands.
Jigging
I did not have a jig for assembling the carbon frame, so I placed the frame on 6 beer bottles as I bonded everything together.

I salvaged a broken carbon fiber arrow to make the frame. However, I did not have a big enough bag to apply pressure to the connection between the motor protectors and the carbon shafts. In an attempt to apply even pressure, I ziptied bags of PlayDoh to the joints.
The Finished Frame

The final weight of the frame came down to 92 grams, which is pretty light. The only lighter 250mm quadcopter I could find was the Turtle 250mm Quad at 82g, and the Turtle doesn't have the weight of propeller crash protectors. I should be able to save even more weight by printing the propeller protectors out of dissolvable filament and dissolving them away afterward.

Issues and Frame Failure

I originally designed the frame to take crashes into walls and for landing. However, there was one failure mode I did not anticipate: backward propellers. We mixed up the propellers one night, and the propellers applied downward force on the frame instead of upward force. I put in very little clearance under the propellers, so the propellers eventually hit the frame. Since the frame was made out of unidirectional carbon strands, it only had the strength of the PLA plastic in the direction of the load, and the entire frame shattered.
Burnt Toast Prototyping Vehicle
Duration: 10 months
3rd Year Undergrad
I designed a low-cost and durable vehicle using our flagship vehicle’s geometry to create a prototyping and testing platform and for new members to practice machining.
Frame Materials
I considered different tubing types for the frame, and eventually chose 1/16” steel square tubing because the flat faces provided easy interfaces for parts, the square tubing was stiff in bending, and steel was easily welded with our equipment.
A comparison between Burnt Toast's steel frame and Reuben's carbon monocoque frame.
Prototypes
I designed and machined the frame and attachment hardware over the summer. Then, I designed and machined two prototype steering systems and a drivetrain made of shafts and universal joints.

Burnt Toast was also used to test a seat adjustment system, created by one of the new members.
Machining Practice
A number of new members were able to practice machining on this vehicle, and it gave them a chance to build failure-tolerant, low cost, and simpler parts before they moved on to machining tasks for the flagship vehicle.
Welding jig plotting for the frame.
Racing
We later decided to race the vehicle alongside the flagship vehicle to allow more members to experience the competition.
Burnt Toast Shaft Drivetrain
Duration: 6 months
3rd Year Undergrad
I redesigned our former (unfinished) carbon shaft drivetrain and created the first proof-of-concept shaft driven vehicle. I optimized the design for cost and ease of manufacturing, since it was originally not supposed to be used in a race. However, we later decided to race with it anyway.
Redesign
The original carbon shaft design was split into two sections that ran on either side of the vehicle and were linked with a transfer axle, which suffered from reduced efficiency at each bevel gear interface.

My redesign moved the entire shaft to one side of the vehicle, which required fewer bevel gears but many more universal joints.
Materials Selection
As I redesigned the shaft layout, I optimized the design to reduce costs and manufacturing complexity. I switched all the components to aluminum (machine shop had spare aluminum), including the carbon shafts. I also changed our expensive universal joints to socket wrench joints. I also redesigned our bearing assemblies to reduce the number of bearings needed.
Burnt Toast Flex Shaft Steering
Duration: 1 months
3rd Year Undergrad
I designed and machined a new steering system using a socket set flex shaft to transmit torque.
Initial Design
The first design involved a very simple mechanism, with the steering wheel attached directly to a flex shaft that would transmit torque to a steerer tube clamp. I modified a steerer tube clamp from a previous project, and mounted the system to a welded post.

I 3D printed the wheel's handlebar grips and showed that 3D printed parts could be used in combination with metal parts to create both complex and sturdy parts. The 3D printed parts would create difficult features while the metal would form the structural parts.
Iterations and Results
After finishing my first prototype, I found out that the flex shaft was not stiff enough to hold the wheel in place, and it would "flop" which created a dead spot in the steering and caused the wheel to easily oversteer.

I worked on stiffening the flex shafts with bearings and shims to try to decrease the flop. After a few different tests, we decided that the flex shaft's coiled cables were unraveling, which caused the flop.

We searched for a more suitable flex shaft, but decided that any feasible alternatives were too expensive.
Burnt Toast Cable Steering
Duration: 1 months
3rd Year Undergrad
I designed multiple iterations of a cable steering system that would pull cables to steer the vehicle.
I designed a steering system that used bike cables to turn transfer torque to the steerer tube. My steering system used two grooved clamps to pull and guide the cables.
Two iterations of the cable steering design. Blue parts are 3D printed, grey parts are aluminum.
The grooves were much easier to 3D print than to machine, but 3D printed plastic parts are too easy to break for making a steerer tube clamp. I designed a bare clamp that could be made on the waterjet, then 3D printed a set of grooves that would go over the clamp. This allowed me to easily create a strong part with grooves, and I could easily remake the plastic parts to yield a different steering ratio.
HPV Tricycle Design
Duration: 1 year
4th Year Undergrad
I am currently leading the design for HPV's 2016 flagship vehicle. I am heavily involved with creating the high-level vehicle designs, keeping the team updated on the designs, and improving the design workflow.
I started by creating a set of concept models to frame our design problem. This was important because we pivoted away from our previous two-wheeled designs in favor of a three-wheeled design to improve stability. As a result, both the new members and the returning members needed a good conceptual understanding of the design parameters. These initial models gave the entire team something to talk about and design around as they all familiarized themselves with the design.
I am now integrating the entire team into the design process by splitting the team into subgroups and encouraging members to self-organize to work on the project. I plan to create a new CAD model each week with the help of every single group, to keep the entire team on track.
HPV Body Cleat System
Duration: 3 months
4th Year Undergrad
I am designing a body cleat system that will securely fasten the rider into the vehicle to improve power transfer, even at extremely prone seat angles.
In order for this to work, a few problems needed to be fixed:

My first iteration used a flanged round cleat that would clip into an indent on the seat. This implementation had issues with manufacturing and homing the cleat to its base.
My second iteration used a hollow seat with a pair of clips that would attach the person's back onto the bars.
These prototypes were manufactured in 1 day using digital fabrication machines (laser cutter, 3D printer).
Non-Slip Bike Pedals
Duration: 2 Days
3rd Year Undergrad
I designed attachments for a pair of bike pedals because they were very slippery in the rain.
My main goals: non-slip and quick to manufacture. Waterjet was the ideal choice for this modification. I designed the parts in SolidWorks and manufactured them in time for the rainy season!