Project with Kirman Hansen.

Pipe Dreams uses audio/video transmitters embedded into organic ductwork forms to provide glimpses of spatially disconnected locations in the Carnegie Mellon College of Fine Arts building. Pipe Dreams was shown as part of a larger exhibition of sculpture, projection, and musical performances. These wormholes introduce a sense of curiosity and exploration into the building and create a place of refuge to view other performances from the show in a quiet, intimate environment.

The pipes invite visitors to spy through the ductwork, showing video feeds from different parts of the exhibit. Putting an ear to a pipe allows visitors to listen in to conversations and performances from other parts of the building.

Pipe Dreams’ construction explores the combination of organic form with utilitarian building materials such as foil and ducts, giving the sense that there is a larger parasitic organism penetrating though the walls of the CFA Building.

Construction

Video equipment

Audio/Video Transmitters. Used hardware made for FPV Drone Racing.

“Thoughts of a Plant” explores the slowness and passivity of plant life by transducing plant biosignals into an evolving ethereal soundscape. A microphone wired into the plant allows visitors to speak into the system, transducing their own thoughts through the plant. When left alone, the soundscape evolves slowly over time as the plant biosignals drift over the course of minutes and hours. When the visitor engages with the plant, the sounds wildly change with the detected speech.

The project used a custom amplifier circuit and max4live to read voltages on the plant and modulate an ableton patch accordingly.

Technical: Tom Scherlis, Sam Zeloof. Design: Patricia Yu, Audio: Eli Wirth-Apley, Wearable: Juhi Dhanesha

“You are invited to listen” is an acoustic experience designed to promote focused listening through the use of a spatial sound system. We used an array of 8 studio loudspeakers in conjunction with a motion capture system, to create a soundscape that reacts to the visitor’s motion within the space. The sonic landscape invites the listener to reflect on the evolving auditory experiences, and commit themselves to focusing on specific elements of the acoustic scene.

The experience takes around 5 minutes, and involves an evolving soundscape played over the 8 speakers. As you approach a speaker, the sound will “come into focus” and the other speakers will become silent. We call this combination of spatial audio with user tracking “hyperspatial audio.”

This slideshow features the sounds from the installation:
https://docs.google.com/presentation/d/1-G7JF4utgPF7nfb8tlqncmiuncCGxQUxCtLR_YBi_mI/edit?usp=sharing

Nexum was a great little project I did with Juhi Dhanesha, Patricia Yu, and Sam Zeloof. I built the wooden bases and wrote the server code and embedded network software for the mushrooms. Credit to Patricia for creating the fantastic illustrations and interaction design, Juhi for the transparent mushroom caps, and Sam for wiring up the electronics for all 5 Nexum Lights. Nexum was part of a speculative design course at CMU taught by Sinan Goral.

The basic concept was to create remote, anonymous intimacy by linking random nexum lights within a network. When you squeeze your Nexum, someone else’s will briefly glow. If you see your nexum glow, you know that someone else in the network was reaching out. Networks could be global and made of strangers, or local with friends.

Background

“are you ok?” is a satirical implementation of a mental health support kiosk from the 70s. The inspiration for this project came from the feelings of frustration and alienation that come from dismissive, canned responses to serious mental health issues. The bingo card above would feel a bit too familiar to anyone who’s been through depression, anxiety, or other mental health issues. People often don’t know how to provide good support and end up gaslighting, diminishing your experiences, or providing dismissive advice like “take a deep breath.”

Good mental health support requires listening, validating, and responding thoughtfully. The biggest requirement for being a good supporter is simply empathy – you don’t need to be a therapist for this. The kiosk breaks all the rules, because it

• Doesn’t pretend to care about you or your emotions (it’s a robot…)
• Only provides canned responses
• The only input is a binary Y/N, you can’t open up to this thing
• It seems to solely attempt to diagnose you and move on
• It’s impersonal
• It only acts logically
• They might be in public locations, or in groups. There’s no privacy since it speaks aloud.
• It’s dismissive, ending each action with a “we hope you are feeling better.”
• There’s no debating it. Each “diagnosis” is authoritative.

The design of the kiosk is hostile, but very simple and “corporate.” The voice is distorted and robotic, and the CRT TV monitor is staticy and industrial, with small white text on a black screen.

Narrative and Interaction

The interaction is simple. In its idle state, the kiosk simply displays “are you ok?” with blinking options for “yes” and “no.” Answering yes will terminate the session, but answering no will kick off a series of prompts that attempt to provide mental health support.

Prompts are printed to the monitor sphere on the top of the kiosk in small white lettering, and read aloud by a robotic voice using the TV speakers. After each prompt, the user can select “yes” or “no” again to continue the interaction. Eventually, the user might end up on a prompt that is simply advice such as “Try getting more sleep” or “consider applying to graduate school” or “try chamomile tea.” Answering yes or no here will terminate the session, and display “Thank you for using this mental health support kiosk. We hope you are feeling better.”

The kiosk will reset if inactive for 15 seconds. While it’s running, the prompts are printed on my laptop so I can see what people are selecting even if I’m not within earshot.

The video below shows an example interaction, and the video at the top shows a longer series of prompts.

Photos and Display

I showed this in Gates and outside Purnell. Both times, we setup the kiosk in the middle of a walking area where we would get a fair bit of foot traffic, then sat nearby watching people interact with it. I printed a fake museum card to attach to the kiosk (see above) with a long-winded fake backstory that described it as a restored object from the 1970s.

Interestingly, demographic differences were very apparent in how people interacted with the kiosk. Outside Purnell, we had a lot more students laughing at the humor of the project, and most people engaged with the “depression” tree the most. At one point, a group of drama students went and grabbed their friends to show them the kiosk. A few parents used it! When we showed it in Gates, most people engaged primarily with the “stress” tree, and seemed more confused and frustrated by some of the prompts, but still usually ended up laughing at the end.

Most people were a bit nervous at first to answer it, and would kind of tentatively press the buttons at arms length. After the first prompt though, they’d get a bit more casual and start to actually engage fairly deeply with it. I was worried that people would be uncomfortable using it in public, but it turned out that a lot of people were very willing to engage with it either alone or with their friends. People would hang out and watch other people use it while reading the fake “artists statement” on the side, and try to explain their theories about where it came from.

The responses deeper into the tree tended to get a lot more abusive and emotionally painful to interact with. This was the “gaslighting” part of the tree, that asked users if they were “sure they were depressed,” making claims that they were “didn’t seem depressed,” or were “bringing down the vibe,” or that they were “using this kiosk to get attention.” It was interesting seeing the groups move from lighthearted responses to the more aggressive ones, since they would transition between laughter and clearly being uncomfortable. I think it was worth including that part of the tree, but it was really painful to watch random people engage with it.

Progress Pics

I found a JVC Videosphere TV from the 70s to use for the kiosk display. Using a UHF modulator it’s able to accept HDMI!

Project with Juhi Dhanesha, Patricia Yu, and Sam Zeloof.

About Spotlight

Spotlight (AKA: Disruption) was an art installation that explores the relationship between humans and their environment by means of a robot observer. Visitors wearing gardening hats were allowed to enter a garden scene, with three abstract animatronic Creatures. The centerpiece was a mechanical Lamp, which would periodically observe the robotic Creatures in its garden. Visitors could walk calmly through the scene, but being too aggressive would disturb the Lamp causing it to shine oppressively on the intruder.

Spotlight explores the intrusive role we often play in our environments, as well as the powerlessness of that environment to respond. The Lamp shines a light on it’s disturbers, but it’s ultimately up to them to decide how to respond.

The Garden Creatures:

Technical Overview

I was the software and motion lead on Spotlight, and implemented all software and kinetic behaviors of the Creatures and the Lamp. Spotlight’s software was implemented using ROS for python. There were several key components to Spotlight:

1. The Creatures. The Creatures of the garden were controlled by stepper motors and arduinos running software developed by Garth Zeglin. Creatures were controlled by commanding each actuator sinusoidally with an amplitude, frequency, and damping ratio, allowing them to behave like spring mass systems.
2. The Lamp. The lamp itself was controlled by a brushed DC motor for azimuthal motion, and a servo for altitude. The brushed motor had no feedback, so the azimuth control loop was closed using feedback directly from the motion capture system.
3. The mocap system. An OptiTrack system was used to track the lamp itself, the positions of all three Creatures, and the positions of the Visitors using the mocap trackers on their hats.
4. Coordinator. The coordinator was a ROS app that interfaced with the mocap system, Lamp, and Creatures to dictate their behavior. A basic simulator was also written to enable hardware-in-the-loop testing outside of the mocap environment.

Software is available here: https://github.com/Toms42/Disruption-ROS

Project with Alvin Shek.

Check out our slides here: https://docs.google.com/presentation/d/1c7nvPH4lnh2w3DKnrLayHfO5ZFBT8kSY3hoLUGLD9bQ/edit?usp=sharing

Download our pdf final paper here:
Drone_control_16899_final_paper

I worked with Alvin Shek to develop a trajectory generator, controller, and software stack to control a simulated agile racing quadcopter in order to race through a set of virtual drone racing gates. We implemented a minimum snap trajectory solver with specialized constraints for drone racing gates, a model predictive controller (MPC), and low level controllers in order to follow the trajectory. All software was written in python for ROS and is publicly available on my github repository here: https://github.com/Toms42/drone_controls

Video:
[youtube https://www.youtube.com/watch?v=uN9TzCkSSKk&w=560&h=315]

I am the Co-Founder and President of Tartan AUV: Carnegie Mellon University’s competitive RoboSub team. Each year we design and build an autonomous underwater vehicle (AUV) to compete autonomously in a variety of underwater tasks. We’ve raised over $40k in cumulative funding so far, and placed 5th overall in the 2020 season – our second year competing.

In addition to leadership responsibilities, I am responsible for the vehicle electronics, software architecture, and Guidance/Navigation/Control (GNC) system. The team has about 6 core members, 3 mechanical, 2 software, and 1 logistics.

Check out tartanauv.com for up-to-date information and official team information!

Monarch connect is a dataflow editor for creating modular command-and-control systems quickly.

View on github: https://github.com/Toms42/Monarch-Connect

Monarch allows users without significant client-side programming experience to construct custom interfaces to talk to a wide array of external nodes. Example applications include command-and-control systems for mobile robots, telemetry interfaces for remote sensing systems, web bridges for non-networked devices, control interfaces for automation systems, and more! Monarch is designed to interface with any device with a serial link, whether it be over TCP/IP, USB, or something else. Monarch is not tied to any particular hardware platforms, so users can easily connect their own systems to Monarch.

Monarch uses an easily-understood dataflow system, where endpoints, filters, remappers, and other nodes can be connected together with a drag/drop interface to create robust command/control systems in minutes. This dataflow system is powered by 3 interface types:

• Payloads: tag/value pairs for data. Payload interfaces are automatically propagated across nodes as data updates in real-time. Ex: raw sensor readings, command values, etc
• Events: Binary “kick” events to synchronize nodes. Ex: button press, connected/disconnected events, fault indicators.
• Streams: Payload+Event interface. Allows directional data streaming with discrete packets. Ex: sensor feed, comms links.

Monarch is developed with C++/Qt, and is designed to be fully cross-platform compatible. (Temporarily limited to Windows only until xinput for USB controllers is replaced though). Currently, Monarch is in early development. The editor frontend and dataflow systems are done, but nodes need to be written and a post-install library system should be added to support custom nodes. Nested flows are a major planned feature. For more info and up-to-date progress, check out the github page.

This page details my contributions to Carnegie Mellon’s effort to develop a low-cost, swarmable lunar-rover. Currently, the project has Phase II NASA funding, and we are hoping to land on the moon around 2020. Expect more information to be available down the road, but for now I am limited in what content I am allowed to share on this page, including the rover name. My role included many responsibilities including:

• One of three main firmware developers for the onboard software
• Lead operator interface developer
• Validation and fabrication of the single board computer, as well as power systems work on the actual design and routing.

The majority of my work was done in Spring 2018 when I connected with the team for the first time since Summer 2016. I took a leading role with several other software team members to design from scratch the software and hardware for this generation of the rover. This initiative resulted in the first driving, functional SBC in nearly three years of development of the project prior to this work. Unfortunately, much of this work is confidential so I can go into limited detail here.

This is one of the best learning experiences I’ve had at Carnegie Mellon, and helped teach me not only a significant amount about embedded systems engineering – both software and hardware, but also about *systems* engineering under in general. CubeRover is in early development, so while technical requirements are well-defined and tight, mission-level requirements are extremely loose and in a state of constant flux. The project is used as a learning-experience for many undergrad/grad students, so inter-semester turnover is very high. This leads to overall stagnation most semesters, so I am proud to have been on the team in a time of significant improvement and progress. A couple other students and I took significant ownership over avionics during my time on the project, which allowed us to move very quickly and formalize mission requirements for avionics development. The rover prototype we developed in Spring 2018 was even featured on Discovery Channel Canada in May 2018.

The Rover:

This is a test platform specifically for testing our avionics equipment and control software, and it does not represent the actual appearance and form of the final rover. However, it handles significantly well in sandbed testing, and is being entirely controlled by software built by the Spring 2018 avionics. The rover on the left was built to house our custom avionics system, and I created the laser cut board mounts. The rover on the right is a more flight-accurate prototype built to perform mobility and robustness tests. We took both rovers to NASA’s Glenn Research Facility in May 2018 to perform tests. Expect to see footage on Discovery Channel Canada’s “Daily Planet” program!

Here we are at the SLOPE lab at NASA’s Glenn Research Center for mobility testing.  You can see both the avionics-equipped rover and the mobility-testing rover which features a flight-representative carbon-fiber unibody and aluminum wheels. Behind our rovers is the much larger Scarab rover which was also designed at Carnegie Mellon University. Scarab was designed to drive in dark craters in the lunar polar regions, hence it’s lack of a solar array.

Rover demo:

This video shows obstacle navigation of the rover test bed:

This video shows reverse traversal of the rover test bed:

Software

My primary contribution to the project was my work as one of three software engineers working on the firmware for the main processor. We developed software in C for a FreeRTOS running on an TI Hercules automotive microcontroller. Due to the critical nature of the mission, all software needs to be written safely with reliable execution, and we worked to the specifications outlined by JPL’s safe coding practices. A significant aspect of the software development is the fully-custom telemetry/command protocol, developed specifically for the high-latency, low-bandwidth application of space-robotics.

I specifically wrote threads for sensor management, communications, and motor control, as well as drivers for sensors. I learned a significant amount of good firmware practices from my peers, John Lore and Jae Choi, who worked on FreeRTOS task management, BLDC motor control, and IMU filtering.

Overview of a Hercules RM42 Processor:

Operator Interface

I took the lead developer role on the software interface for the rover, which has been primarily used for testing our avionics pipeline. The interface displays, graphs, and logs real-time telemetry data from the rover, and allows for command and control of the rover’s various onboard systems. The interface was written in C++ using the Qt framework, and communicates via a TCP socket connected to the rover.

Electronics

I worked closely with a colleague, Jae Choi, to develop a single-board computer (SBC) for the current iteration of the rover. To date, this is the most successfully avionics SBC that we have used, and it has resulted in nearly-flawless system bring-up. We have successfully driven three-phase brushless DC-motors (bldc), on-board IMU filtering, thermal monitoring, encoder feedback, and radio-operations from the main microprocessor, a Texas Instruments Hercules RM42.

In Summer of 2018 I designed an 8-layer board for the FPGA-based video-processing pipeline, which included 2 parallel camera interfaces, memory interfaces, and an Altera (Intel) Cyclone-10 FPGA. This board has not yet been fabricated.

Images:

Comparison to older boards:

3d model:

These modules were designed for Carnegie Mellon’s Formula SAE racecar, which is currently undefeated in the North America Electric Vehicle division!

2019 Safety Module:

Safety module for the racecar. Based on the GLV template, with emergency stop circuit and brake-pressure sensor interface.

2019 GLV Template:

This is the template for 2019 car boards, and is based on the ST STM32F413RGT6 microcontroller:

The board is just under 2 inches on it’s longest side, and features a microsd card reader, CAN transceiver, current/voltage sense, and JTAG programming. Ideally, this board will also feature a CAN-enabled bootloader for system-wide firmware updates.

Telemetry Module

I designed the Telemetry Module for the Carnegie Mellon Racing (CMR) Formula SAE racecar this year with my roommate Advaith Sethuraman. This module connects with the other modules over a CAN bus, and sends telemetry over an XBEE radio. More information on our car can be found on the Carnegie Mellon Racing website.

It’s based on an Atmel AVR32UC3 MCU, and I designed it in Altium Designer. It’s a 4 layer board, with JTAG, dual power supplies, filtering, and an XBEE in addition to the AVR.

Pictures:

Dynamic Lighting Controller (DLC)

The Dynamic Lighting Controller (DLC) is an add-on for next year’s Formula SAE racecar built by Carnegie Mellon Racing (CMR). You can find out more about their car here.

The DLC is currently in early design, and will likely change before fab. It currently features an Atmel AVR32UC3 microcontroller, but that line is discontinued, so the next revision will use either a TI Hercules processor or an ST automotive processor. The goal is to provide hookups and dynamic lighting configuration to the various lighting fixtures of the racecar, including brake lights, hazard lights, under glow, tractive trunk lighting, and anything else that needs dynamic LED strips. Currently it is designed to use dotstar LEDs, which are controlled via SPI, so they are easy to control from a 32 bit MCU, as opposed to the more popular neopixels. It also features a larger 10A power supply and a fuse to control these LEDs.

Picture:

This was a project I built for CMU’s one-week hackathon Build18. We implemented quidditch in VR using a novel spring-based haptic rig that does not rely on expensive actuators. Project writeup and demo video to come soon! This project won the Faculty and Staff Choice Award as well as the Builder’s Choice Award at Carnegie Mellon University’s Build18 Hackathon in January 2018!

Short video featuring some early demo clips from the first version of the game:

Some additional info here: http://www.build18.org/garage/project/256/

Hagrid’s Wild Ride was an experiment in creating a low-cost, fully passive haptic feedback system for virtual reality environments. In our case, we created a haptic “broom” that served as the input for a virtual reality Harry Potter Quidditch flight simulator. My responsibilities included:

• Hardware design and fabrication lead (Solidworks CAD + machining)
• Procedural map generation (Unity + MapMagic plugin)
  • Used various types of procedural noise, as well as erosion and terracing systems to create realistic procedural mountains.
• Game creation (Quidditch + Dragon Fighting)
  • Interfaced an Oculus Rift VR headset with Unity, and created/tuned a flight simulator for the system. Added some basic enemy ai’s as well.

Other team members created the orientation input electronics, Unity Engine asset creation, and Unity Engine scene creation.

In the meantime, here are some photos:

Github Link: https://github.com/Toms42/logisim-RISC-V-CPU

Description:

This is an emulated CPU based on the RISC-V architecture. It is emulated in the Logisim environment, which is designed to simulate logic circuits.

The CPU can execute RISC-V assembly programs when assembled using a custom toolchain developed by Sol Boucher for the independent study I developed this in. It features a working RISC-V ALU, Register File, Datapath, and Control Unit. It also includes a special byte-addressable memory module that was developed by Sol Boucher to replace Logisim’s built-in word-addressable memory.

Modules:

Datapath:

This is the datapath that instantiates a regfile, memory, and the ALU. It has a number of control points to control data flow through the ALU, which can be controlled by the Control Unit. It features integrated program/data memory, as well as hard-coded interrupt register locations that can be utilized by a custom kernel.

control unit:

This control unit decodes the 32 bit RISC-V instructions. It manipulates the datapath’s control points to execute each command. It can do all of the basic RISC-V instructions including arithmetic as well as JAL and BRANCH type instructions. It also contains the keyboard and TTL components for IO, as well as the interrupt controllers!

Usage

Usage is documented in the RISCVTESTPROGS submodule! It requires msys2 for the toolchain. A custom kernel is included with basic placeholders for the keyboard and timer ISR’s. In a later version context-switching and full support for user code will be added! Email me if there are any questions!

CUDA-Accelerated Lattice Boltzmann Simulator

This is a fluid simulator I made with Henry Friedlander using the Lattice Boltzmann Method for computational fluid dynamics.

The software uses Nvidia’s CUDA framework for GPU acceleration and it is rendered with OpenGl.

Video:

Technical Report:
(click here to download)
 

Powerpoint:
(click here to download) 

Features:

• 150ft Ethernet Tether
• Over 35 pounds
• Live video and telemetry feed!
• Custom PCB and firmware
• Pitch and depth control
• Rated for over 50ft depth

Video:

Code:

Operator Interface

Firmware

There is an overview of this software on the Subcontrol page of this website!

Hull:

The hull was largely unchanged in this update, although it was polished considerably. More info on the actual construction of the hull is in the “nautilus” page of this portfolio.

Sealing:

We used 3m adhesive boat sealant. The key to this stuff is that you MUSTtake care to sand the surfaces and clean them with acetone before generously applying the sealant, and buy several tubes because you aren’t technically supposed to apply them after they’ve been open for a few days.

To find/patch leaks, I made a second bulkhead with a hose barb so that the hull could be pressurized. To detect leaks, pressurize the hull, dunk it in a bathtub or pool, and look for air bubbles streaming out. Find the source of the bubbles, patch them with sealant, and repeat until you can pressurize the hull adequately with no bubbles appearing. The most difficult part to seal is the rear bulkhead, and I recomend gas teflon tape and pipe dope, as well as tightening it for 3 turns beyond hand tight. Try not to break the hull when tightening.

Sleds:

We added the weight sleds for this version, filled with about 10 pounds of washers to weigh down the ROV.

Painting:

Electronics:

This is where the bulk of the overhaul was. The old system flat out didn’t work, and we realized that the best option would just be to overhaul it entirely and start from scratch. We kept the USB protocol, but we added a usb over ethernet extender, replaced the bulky circuitboard, and completely re-engineered the communications protocol.

System breakdown:

Communications protocol breakdown:

(More details on how this is done will be uploaded to a seperate post.)

Images:

v2.0 (older version):

Overview of power board:

Overview of control board:

This version failed due to a leak, and was also nearly too large to fit in the tube. It was redesigned for v3.0:

v3.0 integrated PCB (newest version):

This version features the control and power circuitry integrated onto one small board!

Schematic:

Board layout:

Screenshot of control software:

More info on this later!

More prototype videos:

Info:

This was made for my calculus teacher to demonstrate volumes of revolution, where a 2d function is rotated around an axis, forming a solid with a calculable volume. It runs on a very minimal setup of an AtTiny85, which controls a generic brushless ESC via PWM. This is a relatively old project of mine, and was my first test of doing things like PWM on an AVR chip without any libraries.

Pics:

Github Link

Preview:

Overview:

I’ve just started this project, so not much to show yet. The goal is to brute force hashes using an unrolled, fully pipelined Verilog version of the MD5 hashing algorithm. If all goes well I’m looking at something in the range of 100 gigahashes per second, which blows CPU hashing out of the water. Maybe I’ll try to find a way to get it to integrate with hashcat or something, otherwise I’ll just write my own control software. The usage would be something like this:

-Create text file with brute forcing formats/character lists

-Create another text file full of the hashes

-Run command line C program that will transmit that data to the FPGA using UART

-FPGA will generate passwords, hash them, and compare to the given hashes.

-Send back any working hashes along with the original password that generated them.

Check back soon!

Github Link

Video:

Pictures:

Features:

• Custom speed VGA output: Uses a 12bit DAC (but only actually uses 3 colors now for Snake lol)
• No sprite engine or frame buffer! Requires no memory!
• SNES Controller input! It’s a lousy controller but it’s got that recognizability/nostalgia value.

Module Overview:

In Quartus that looks like this: (sorry for resolution. You’ll want to open it in Quartus if you want to zoom)

Design units:

1. PLL’s: (Phase Locked Loop)
   1. Altera PLL:
      1. This is altera’s hardware-based PLL which takes the 50MHz input clock down to 25MHz for the VGA clocks.
   2. Refresh Divider:
      1. This divides the clock into a low frequency in the range of a few hertz for the game to run at. The snake moves over 1 tile per pulse of the refresh clock.
   3. SNES divider:
      1. This divides the clock into the frequency required by the SNES controller, which uses a clock/latch/data interface.
2. SNES Controller:
1. This module takes the snes clock and polls the snes controller in the gpio. To poll the controller, the latch pin is first released, then on every clock pulse the controller’s data pin is high or low depending on the state of the button.
3. VGA Controller:
   1. This module controls the vga video bus for the display. It manages the horizontal and vertical pixel counters, and pulses hsync and vsync accordingly to keep the display in sync. It outputs the x and y coordinates of the current pixel on the x/y busses, and has inputs for rgb that any other module can set. Setting the rgb inputs changes the color of the current x/y pixel.
4. Snake Controller:
   1. This module runs the actual game and stores game data. It has an array of tiles for the snake field, and each tile has a current length variable that is decreased down towards 0 every refresh cycle. If the tile’s length is greater than 0, it displays on the screen as green, otherwise nothing.
   2. There is also a headx, heady, and direction coordinate set, which keeps the position of the head and its direction. Every refresh cycle it makes the tile to the direction direction of the head’s length variable equal the current length of the whole snake. That way the tile stays active for length cycles, and it looks like a snake slithering around on screen, even though the system is fully modular.
   3. The snake controller also creates a random food tile who’s coordinates are generated using a bucker pass method. On every pulse of the main clock (not refresh clock) the position of the food is shifted one tile over or wrapped to the start of the next line. When the actual food is eaten, the next food tile’s coordinates are sampled from the pseudorandom coordinates generated from the bucket passer.
   4. If the head coordinate is on a food tile, it increases global length by one and moves the food.
   5. If the head coordinate is out of bounds or is on a tile with a length variable greater than 0 (ie the snake’s body), then the dead bit is flipped and the screen goes red and waits for a reset.

            All modules are built as finite state machines, as that is the best way to make non-simultaneous operations in HDL. It is based around “always” blocks, which run their contents every time the event described in the always block’s parameters is detected. For example, an “always (@posedge clock)” code block will run on each rising edge of the clock.

            The modules all have variables defined at the top. These variables cover both inputs, outputs, local variables, and constant parameters. Each variable has to be defined as a register or a wire. Wires are just wires, but registers have hardware registers that save their state. A wire’s value can’t be accessed if the wire is not being driven by something else, but a register has more complex timing restrictions.

            There are two types of equals systems, “=” and “<=”. The one on the left is a normal definition, but the right one is a blocking definition. It waits for the value on the right to be updated before defining the value on the left.

Problems faced:

            When writing this, I had a few issues. The first was being unable to drive some busses at all. In quartus, if two always blocks define the same variable it won’t compile because two sources cannot drive the same wire or register as it would short the hardware. I had to restructure a lot of code to fix that.

            Another big issue was figuring out how to access the individual bits of a larger data bus, ie getting each bit of the rgb busses to output their values to the DAC. This was just a matter of figuring out all the names and bracket syntax.

            Another issue was that the death detection system didn’t work especially well. It seems to be checking death at the wrong time, so crashing into your tail doesn’t always kill you. In addition, the way that the length increases is not consistent with actual snake games. Because changing the global length variable only affects snake tiles defined after the change, eating food won’t increase the visible length of the snake until the tail arrives at the position the head was at when it ate the food. I would have to completely restructure the program to change this, possibly by making a linked list instead of a static array for the field.

            Yet another issue was that I was storing a lot of data on the FPGA in its logic blocks rather than memory. Because the field array is rather big (10 bits per tile for length and there are like 300 tiles multiplied by however many times the synthesizer needs to replicate the data registers) it wouldn’t always fit on the fpga. This issue wasn’t a big deal, but I had to write a lot of the code with complexity and hardware resources in mind.

I made a segway with some friends this year! It’s not totally done, but here is the report of its early stages:
Here is a pic of one of the team members riding it:

Here are some pics of the custom control board I designed (in progress):

Here is the paper detailing the physical construction:
PDF Download link!

This page includes various projects that my students or I have made at Leap@CMU.

Summer 2014:

Air hockey robot:

This was a project I did with two other team members, Karan Bokil and Ansuman Das. The system relied on a stepper motor and a belt for mobility and a camera to detect the puck. Unfortunately, camera lag and issues with driving the steppers at high speed caused this project to not work very well. It would often skip steps, and the camera had a lot of trouble tracking the puck so we had to do away with predictive algorithms.

2015:

This summer I TA’d for the robotics track, and helped three groups of students greatly to make their projects. Here is what they did:

Tic Tac Toe Robot:

This robot was built by Jasmine Lee, Rhea Kudtarker, Jacob Lokay, and Anotonio Garcia-Smith.
It relied on an array of photosensors to detect the O’s, and had an algorithm that could win in every game unless the player started in the center, in which case it might tie.

Laser Harp

Jacob playing the laser harp:

This project was built by Eric Zhang and Raj Thimmiah, with heavy help from the other TA Rohan and I. It used an arduino to detect the broken beams and plays the note over midi. We used a MicroKorg to play tones from it.

Kinect Turret

Another group made a kinect based Nerf turret, but I didn’t really have much of a role in their project and unfortunately don’t have any pictures or video.

Status: design phase

This is the avidrone, one of my favorite projects. I’ve been working on it since august, so it’s a fairly long term project. Currently it is in its design phase in solidworks, which I hope to complete by the end of March and get it cnc routed by the end of April, to keep me on track for completion in June.

Renders:

here is a short animation showing the flapping of a single wing. This is an old render so the actual motion has been altered since its creation:

Specs:

Controller board:

The board is a custom ATTINY based pcb that I designed specifically for this purpose. Its function is to take the input from the aileron channel as well as the status of a hall effect sensor to twist the wingtips to achieve a variable angle of attack for the forewing. This function is critical in an actively flapping ornithopter, and it provides the forward thrust as well as aileron control necessary for successful flight. I got these boards printed at OshPark for $2 each, and I have 6 of them that I plan to give to the others working on similar birds.

Acknowledgements and other info:

The progress of this project is periodically updated here on rcgroups.

A large amount of this design is based on similar designs by Festo Engineering, here, and by Hiro, here.

This is a java minesweeper ai, which can play the windows 10 variant of minesweeper: minesweeperX available here. Unfortunately, because the AI relies on using screenshots and having constant window border sizes, it will only work on win10 computers.

Here is a preview showing how it works:

The current high scores as of 3/6/2016 are:

Here is a short video of the best expert run:

The java AI has a few basic stages:
-start guessing squares until it can “seed” itself and actually have some options. ie start on a blank, not numbered tile.
-continue running iterations
-once no moves can be made, guess moves then keep iterating.

Each iteration is broken up like this:
-examine each tile and determine if it is a known bomb or flag
-dig all tiles that are known to be empty
(digging and flagging is done with mouse operations)
-attempt to iterate again.
-if moves were available, continue to the next iteration.
-if there were no available moves, take a cropped screenshot and analyze the tiles to update the field, then repeat.

Time: Winter 2015-2016
Status: Nearly Archived
Completion Level: 90%

Download PDF report here!

Download PDF report here!

Status: Archived
Time: 2013-2014 Winter
Completion Level: Complete

Description/Goal:

This was a small (<30cmx30cmx30cm) robot designed to compete in the Scioly division B event: Robocross. Your score was calculated based on each piece (ping pong balls, lego’s, batteries, etc) moved into the various quadrants of the field, with multipliers for being in an upright jug. My robot was designed to easily achieve a perfect score within the 3 minute time limit, and win by the tiebreaker: fastest time. A video of a practice run for our final robot is below:

[youtube https://www.youtube.com/watch?v=Qz9cXYQ2z1M]

Solution:

Version 1: Old non-programmable vex platform.

.        

This first attempt was severely limited by the inability of the sheet metal scoop to get under the lego bricks, as well as the slow process of raising the scoop. We used it throughout the invitational season so we could develop our second robot without worrying about keeping it secret or having to rush versions.

Version 2: Modern vex cortex programmed in robotc.

For the second iteration, we explored more innovative solutions to the problem. My driver Rakesh Ravi was unhappy with the time required to dump each scoop of items, so we searched for a way to have the jug held on the back and quickly ferry the items into it. We landed on a sticky belt with a scraper on the back, so the driver would only have to push the belt up to the the item and the robot would lift it into the jug.

Obviously, this was more complicated than expected. The first iteration of the belt utilized transfer paper for book sealing, which was too weak to firmly hold the tennis ball. Gorilla tape on the other hand was too strong and would not release the batteries, jamming the belt. After trying every possible combination of duct, masking, packing, and adhesive coated tapes, I ended up choosing to apply gorilla tape, with transfer tape over most of the belt except for a small chunk to grab the tennis ball.

The next issue was grabbing the jug. We needed some sort of arm that could pick it up and hold on to it firmly for the rest of the run. I settled on a dual-jointed arm with potentiometers for position feedback and a control loop that was based on a set of known positions that the arm would “snap” to at the press of a button. This meant in the match the driver only had to approach the jug and in three button presses the jug was firmly clamped to the robot.

We used an omnidirectional drive platform for easy repositioning, and once the driver became used to it we saw a huge increase in speed. This robot was programmed in robotc, and featured a complex but very efficient controller layout view-able below:

This robot could easily get a perfect score in under half the time limit, and occasionally saw times under 1 minute. In the national competition, we had a somewhat unlucky run mostly due to the immense pressure to perform, and got a 1:50 run securing a top 15 (11?) position.

Status: Ongoing
Time: 2015 October-November
Completion Level: 80%
Participants: Tom Scherlis, Haoran Fei, Chirag Kulkarni

note!! This project has been significantly updated since the writing of this page! Here is a newer video showing off the finished ROV and its operator interface:

Goal:

For our ROV, dubbed the Nautilus after Captain Nemo’s vessel in 20,000 leagues under the sea, we decided to create a unique design featuring fully analog motor control and a USB interface, which has rarely been done.. We were able to purchase the parts required ourselves, and then construct and test the performance of the ROV. The ROV would have sealed brushed motors, obtained from bilge pumps as thrusters so that it could move horizontally in the water. It will be primarily designed to function in shallow water, such as swimming pools or small lakes. We planned for a maximum depth of at least 50 feet, but have not tested deeper than 12. We planned to control it via a USB XBOX controller. When it was underwater, we would have an Ethernet tether to connect the ROV to the controller. A camera would be installed on the ROV to provide a first person optical feed as we test it in various environments. The following picture shows the overall design of the ROV system.

Challenges:

The major challenges of this project would include controlling the motors, keeping the unit neutrally buoyant and upright, sealing the entire system, communication over ethernet, and testing to ensure the reliability of the ROV in water.

Objectives:

For our ROV to function properly as to our specifications, we needed to accomplish several goals. Our ROV must be
1. Waterproofed
2. Remotely controllable via Ethernet tether
3. Able to maneuver through tight spaces
4. Stable underwater and neutrally buoyant
5. Maintain visual feed through front window with headlights.
6. Capable of collecting sensory data
7. Able to run for at least 45 minutes, long enough to get data and record observations.
8. Must have removable weight tubes to adjust underwater buoyancy.

Materials!

Tools Required:

Knowledge of operation and safety of the following tools is required to build this project:

• Electric miter saw (at least 12 inch)
• Drill press
• Hand drill
• Soldering iron
• Use of lighter and heat shrink tubing
• Hacksaw and saber saw
• Dremel
• Assorted glues including:
  • PVC cement
  • #16 acrylic cement
  • 5 minute Epoxy
  • Epoxy putty
  • Boat sealant
• Large (>2 feet) plumbing wrench
• Assorted consumables:
  • Teflon plumbing tape
  • Heat shrink tubing
  • Electrical tape

2 pin Speaker wire and normal wire

Construction of the Frame:

The frame is the backbone of the ROV. It needs to be able to support the main tube, which both stores the electronics and has windows so that a clear line of sight can be established. It also must remain upright under water and withstand the pressures underwater while holding a seal. A solid frame is the foundation of every other part of the ROV.

Requirements for the frame:

• Sealing
  • The frame must be completely sealed-any minor leak will destroy the electronics and possibly make the battery combust because water will short the electronics.
  • The frame must have at least three openings: One for the tether wire to the control panel, another for the pressure sensor that functions only in direct contact with water, and finally a removable cap large enough so that we can remove the batteries and the motherboard after each test. All of these openings have to be completely sealed, like the rest of the frame.
  • The motors must be completely sealed and able to function properly, given that the thrusters must be placed outside the main tube.
• Windows
  • The frame must have a main window that is large enough for the Mobius camera’s field of vision. This window must be clean because otherwise the quality of the video would be compromised.
  • There must be separate windows for the LED lights; if we put the LEDs and Mobius camera together the glare will make the video incomprehensible.
  • The window should be fairly strong so that it can sustain reasonable hits from small objects in the lake and pressure from deep water depths. Thus, the window should be thick.
• Materials
  • The frame must be sturdy. There will be significant amount of extra weight added to the main tube, and the strength of the frame is significant.
  • The material of the frame has to be easy to cut and connect. The material must be durable and preferably reasonable in price as well.
  • The material has to be stable under water and resistant to light corrosion by lake water.
• Shape
  • The shape of the frame combined with the distribution of weight must make the ROV stable in water–it cannot flip over or tilt while submersed. It has to be symmetrical as well so that it is balanced and easy to control.
  • The frame cannot have an extreme volume, either too high or too low, so that the buoyancy is controlled–too much buoyancy will cause the ROV to float, and we would have to add a lot of ballast to balance it. Too little buoyancy means it will sink to the bottom of the water and require a large amount of propulsion to rise.
  • There have to be places to mount the vertical and horizontal thrusters, and such positions have to be symmetrical.

Buoyancy and Balance in Water:

As a submersible vehicle, our ROV must have the ability to control its depth in water. Since the water/air pumping system that real world submarines use is too complicated to be practical for our uses, we decided that we would utilize two vertical motors to control our depth in water. Therefore, the balance of the ROV–namely the balance of the buoyancy and the gravity–is incredibly important. As a safety measure, we want the ROV to be able to float to the surface just in case the motors failed; we do not want to lose the ROV in the bottom of a lake. Therefore, the thrusters have to spin in way that will provide a vertical propulsion downwards. As a result, we want the ROV to be overall balanced, with a buoyancy slightly larger than the gravity. This is achieved by adjusting the weight in the weight tube. For reference, the calculation of Buoyancy and the measurement of mass are as listed below:

Therefore, the total volume is 12,521 cm^3, giving us a buoyancy of about 122.7N. The mass of the finished ROV, as we measured after the presentation, is about 9.2 kg; this gives us a gravitational force downwards of about 90.2 N and a net force of 32.55N upwards. This can also be expressed as 12.521-9.2=3.321kg upwards. The weight tubes fit 3 0.5kg weights each, giving us an additional 3kg of mass, making the final buoyancy equal to 0.321*9.8=3.14N upwards. This slight vertical force is mostly negligible, but means the ROV will likely float up in the event of power loss assuming no current. It also means that if we are hovering near a silt floor, the thrust from the propellers will be constantly upwards so that we will not stir up the silt.

Stability of the ROV

The ROV’s stability in water is one of the key concerns in the design of the frame. There are two primary factors to consider in the underwater stability of the frame: the center of gravity and the center of buoyancy. Because the ROV is almost completely symmetrical horizontally, the center of buoyancy as well as the center of gravity will lie on the axis of symmetry. The general formula of the center of gravity and center of buoyancy are as follows respectively:

CoM = Σ(m_n * X_n) / M

CoB = Σ(v_n * X_n) / V

We measured the center of mass by balancing the ROV. This method is more accurate than theoretical calculations, as mass of items such as glues and other small pieces are difficult to include in the theoretical equation. However, for the center of buoyancy, we decided to use theoretical calculations. Our volume measurements were precise, and it was impossible to measure the center of buoyancy experimentally.

Calculations:

CoB = (V_maintube * H_{maintube +} V_support-tube * H_{support-tube +} V_thruster * H_{thruster +} V_flaotingtube * H_flaotingtube) / V_total = 20.09 cm from the bottom of the main tube.

Design of the Frame:

Based on the requirements previously specified, we came up with a design of our frame suitable to the under water conditions. We decided that the ROV needs to have at least three windows. To avoid glare and optimize the video quality, we need to ensure that there is considerable distance between the LED window and the main window.
With regards to the material of the windows, since glass is too fragile, too harmful, if it cracks, as well as too hard to attach to other materials, we decided that acrylic plastic is the best alternative material that we could use for the window. In addition, we already had some reserve acrylic from our Robotics project. Therefore, we were able to also reduce the cost of the project since we had more than enough reserve proxy glass to make all the windows.
As to the material for the frame, after carefully comparing multiple possible materials, we found that PVC pipes are the best choices considering all relevant factors. In comparison, ABS pipes are much lighter and equally good in durability, but they are about twice as expensive as the PVC tubes and also harder to assemble, making them not as suitable to our purpose compared with PVC pipes. We decided to use the PVC pipes, since they are inherently water proof, easy to connect and cut, standardized, and inexpensive.
As for the shape of the frame, we first decided that a main tube with a diameter of at least 4 inches was necessary to store all the basic electronics and batteries. Because the camera had to be mounted on the motherboard to avoid wiring difficulties, the main window has to be in front of the main tube. Thus, the back side is the only place to create a removable cup for all the electronics.
Then, for the purpose of additional buoyancy as well as places to place the LED windows and to mount all the thrusters, we decided to include a ring of smaller tubes above the main tube. Because we wished to make the center of buoyancy above the center of gravity to allow the ROV to sink, these tubes had to be mostly hollow.
Finally, we decided that the weight tubes be removable; they should be attached below the main tube through wholes clamps. Also, the top tubes and the main tubes had to be connected very sturdily; this required multiple connection tubes. We ended up deciding that six connection tubes with an inner diameter of ½ inch is appropriate for this purpose.
The theoretical finalized design is represented by the three schematics below, representing the side, top and front views. It had to be modified during construction, as detailed in the next section.

Building the frame:

I won’t go into detail here because it is a pretty extensive process. The pdf version of the report should have more info on this. Instead, here are some photos from the process:

The basics is that we used pvc cement and epoxy to hold everything together, and a thick coat of boat sealant over the seams as a seal.

Building the thrusters:

The thrusters were built from bilge pumps, because they were already contained pre-sealed DC motors. We simply cut the white plastic housings off of the motors, and attached the props via small shaft couplers and threaded rods. Here is the procedure:

1. Cut off white housing with hacksaw or Dremel
2. Wedge the propeller off of the shaft with a flathead screwdriver
3. Attach shaft coupler to the shaft of each motor
4. File head off of 20mm m4 screws with a wheel grinder
5. Attach threaded rod into the shaft coupler as well
6. Put a spring washer on the threaded rod
7. Screw the propeller on the threaded rod

Attach thrusters to frame using hose clamps

Electronics

The ROV requires a significant amount of electronics to function properly, and the electronics must be able to operate in the harsh environment of the ROV main tube. Important note: most of this reference material relies on moderate existing knowledge of Arduino and general wiring. Attempting to replicate will require the ability to solder, protect equipment from shorts and reverse current, knowledge of reading datasheets and reference material specific to a product, and basic electrical knowledge.

Requirements for the electronics:

• Physical:
  • Must fit in the main tube
  • Must be removable as to retrieve video and program it
• Power:
  • Must be battery powered with long of battery life (>45 minutes)
  • 12v source voltage for thrusters
  • 6v stepped down voltage for LED’s (3v forward voltage per LED, 2 parallel sets of 2 in series)
• Thrust:
  • Provide high current to each thruster (At least 5 amps)
  • Must be able to provide variable power to the thrusters
  • Thrusters must be able to be reverse propulsion
• Control:
  • Must be programmable
  • Must have a USB interface with hosting capabilities
• Sensing:
  • Read and save temperature and pressure (depth) data
• Data:
  • Be connected to the surface via >100ft 8 pin Ethernet (RJ 45) cable
  • Return live video to the surface
  • Be controllable via a USB gamepad
  • Return telemetry data to be displayed on a control panel

Must display main battery voltage at the surface

Diagram:

This is a simplified diagram of the basic layout of the electronics. Parts used:

• Arduino microcontroller: This offers standard pinout and layout compatible with a large variety of “shields.” It also offers USB slave connectivity for programming via FTDI.
• USB Host Shield. This shield allows the Arduino to function as a USB host, and interpret input from a USB gamepad such as an XBOX controller.
• 4 Cytron 13A 5-25v dc motor driver boards. These very cheap ($13) driver boards offer huge amounts of current, directional control, and thrust control via pulse width modulation.
• 4 Brushed dc motors from Bilge Pumps. These 5A motors are detailed in the previous section.
• 2 three cell (11.1v) 5Ah lithium polymer batteries. These high energy density batteries offer high current draw capabilities and very high capacity in a small form factor. We use 2 for 10Ah total.
• 2 Dual LED circuits: We used 1 watt 3v LED’s, which have built in heat sinks and very high illumination intensity.
  • Each circuit consists of 2 LED’s in series for 6 volts each, both wired to a 6v regulator
• Ethernet tether cable: Detailed in the gray box. This tether allows the transmission of all data from the surface to the ROV and back.
• Not shown: Serial LCD display. This display can be hooked up to the 5v source and the serial out pin of the Arduino and display data.

Not shown: USB over Ethernet converters. These convert the Ethernet signal to an AC signal, preventing it from being lost to the high capacitance and resistance of a 100ft cable.

Detailed section designs:

This schematic shows the distribution of LED’s to ensure each gets exactly 3v. As described in the frame section, each set of 2 LED’s is in its own window and must be detachable from the motherboard.
It is important to ensure that the LED’s are wired correctly, as they will quickly burn out if over-volted.

The motor controllers must be hooked up to the battery voltage as shown, as well as the motor through the A and B plugs. The location and type of pin varies depending on the controller. Ours used screw terminals for the high current pins and 0.1 inch male headers for the data and Arduino ground pins. The pulse width modulation (pwm) pin must be connected to an Arduino pwm pin (marked with a ‘ ~ ’ ) to be able to use the “analogWrite” function for controlling power. Dir can be connected to either a pwm or generic digital pin.

The USB host shield is connected to the top of the Arduino as shown. The small USB A-type plug on the shield can be used for the xbox controller. To connect it over the tether, a male USB plug must be purchased or cut off of an existing wire to access the USB D+ and D- pins for data, and the power pins. The pinout of the USB connector is shown below.
Connections to the Arduino can be made by soldering wires to strips of breakaway long male header pins. This way the wires can be unplugged easily, but are all connected together in a way such they do not fall out.
An important note is that the USB host shield (Circuits@home brand) uses pins 9 and 10 as the INT and SS respectively, as well as pins 11-13 for the ICSP data connection. You must cut the INT solder jumper and reconnect it to a non-pwm pin (we used pin 7) in order to use pin 9 as a motor pwm pin. If all connections are made, the Arduino pin setup should look like this: (shown below)

Arduino Pin Connections:

1. (Arduino Rx) Not Connected
2. (arduino Tx) Pin 1 of tether (LCD Rx)
3. Motor 1 dir
4. Motor 1 pwm
5. Motor 2 dir
6. Motor 2 pwm
7. Motor 3 pwm
8. N/C (usb host shield INT pin)
9. Motor 3 dir
10. Motor 4 pwm
11. N/C (USB host shield SS pin)
12. N/C (ICSP)
13. N/C (ICSP)
14. N/C (ICSP)

Motor 4 dir pin can be connected to either an analog in pin on the Arduino, or to the USB shield’s GPIO (general purpose in/out) pins. We used GPIO out pin 0 to keep all analog pins free for sensors.

The tether:

The tether is made from 100 feet of underground Ethernet cat5e cable. Our cable had a long metal wire to prevent twisting and kinking. The pinout was as follows:

1. VCC: battery main voltage
2. +5v: for USB and LCD display
3. LCD Tx signal (from Arduino pin 1)
4. Video signal
5. USB D+
6. USB D-
7. Ground
8. Ground

The video signal will depend on what camera you are using. We used a Mobius action camera, which came with a cable for signal and ground.

The tether and all cables were routed through the brass fitting described earlier. In order to disconnect the tether from the ROV, an underwater junction must be used. We used a Buccaneer Ethernet Coupler by Bulgin. Unfortunately, it still leaked and thus it is important to coat the gap between the threaded ring and the side it is attached to with boat sealant. (Area to coat is shown with an arrow)

You must be consistent with terminating the Ethernet cable. We utilized a continuity tester to ensure that each segment of cable was terminated correctly and that the final pins stayed in the correct order. The order of data wires is arbitrary, but you must be consistent. There are several sections of Ethernet cable that have to be terminated as follows:

1. Board to male rj45 (<1 foot). This is a small segment to allow the board to be removed. One end is a male rj45 connector, with all of the small data wires soldered to their appropriate pins.
2. Female rj45 to male rj45 (2-3 feet). This cable goes from the inside of the ROV to the outside through the brass fitting. It is connected on one end to the board cable via a female rj45 connector and a male connector on the other end. Ensure that the Bulgin coupler is inserted on the cable before terminating, as it cannot be added later.

Male rj45 to male rj45(100-200ft). This is the main tether cable. Similarly to the previous section, one end must have the Bulgin coupler before terminating.

USB is rated for about 15 feet, and anything longer requires a signal booster. We used a small USB over Ethernet converter to boost our signal. There must be one on both ends to boost the signal up then take it back down. This connection is critical to the working signal. In our ROV, this connection was poorly made and as a result the connection was very unreliable.
To find the pins of the connection, you can connect it to a USB plug and use a continuity meter to identify the solder joints of each pin so you can disconnect the plugs and solder everything directly to the board to save space. Instead of soldering the Ethernet cable directly to the board and removing the connector, you can instead plug in a small piece of Ethernet cable and use the wires from there.

Sensing:

The pressure transducer was wired with the data to A0. It is a Honeywell PX2EF1XX050PAAAX, 0-50psi 5v ratiometric sensor. Be careful with this as it is a $60 sensor. We did not include a thermistor, as it broke and we did not have time to obtain a replacement. We soldered servo wires to the Arduino and sensor cable for easy removal and insertion of the board.

Final Board:

We laid out the board on a sheet of acrylic that can easily be inserted into the main tube, sized to fit in the main tube with just enough clearance to fit the batteries underneath. The final layout is as follows:

All boards were attached to the acrylic sheet with m3x20mm screws, with 1cm m3 spacers to offset them from the sheet. Power wires were routed under the boards for organization.

The tether is connected to the surface via a small control panel. Holes were cut for each port: voltmeter, analog video plug, female USB plug, LCD display, and Ethernet port. Each item was glued in place on a small piece of acrylic and a section of 2 inch pvc was bolted on the back with m3x20mm screws. The USB over Ethernet adapter is also housed in the control panel, as well as a small 2s LiPo and 5v buck to provide additional power for the control panel.

Ensure that wiring is kept neat to prevent shorts and disconnects. The LCD is wired so that the Tx from the tether attaches to the LCD’s Rx, and it is also given 5v and ground.

The board must fit in the 4inch tube along with the wires. It is important to keep wiring neat to prevent tangles and snags from preventing the board from being inserted. It will be a tight squeeze, but should fit as shown below. It is difficult to insert, but can nevertheless be done.

FINAL PHOTOS!!!!

Testing results:

• Propulsion Test: October 26th. Result: leaks detected.
• First pool test: October 28th and 29th Result: more leaks….
• Second pool test: November 1st Result: Fixed the leaks! Communication issues…
• Third pool test/ First Lake test: November 8th (Incomplete)

USB Issues:

This was the biggest issue for us. USB is finicky, so trying to run it over 150 feet of ethernet is difficult. I think our issue came from only using 1 pin on the ethernet tether for the data lines, resulting in too much resistance in the cable. If we were to do that part over, I would remove the USB host shield and Mobius camera, opting instead for a webcam and usb hub. This would allow us to use a laptop as the USB host, and transfer all the data through the usb over ethernet converter, without the need for extra data lines. The arduino can read all the voltages we need, so we could drop those lines as well. I’m currently working on writing a java program to visualize the ROV’s state, including the orientation and thruster powers, as well as send messages regarding thruster power to the ROV obtained from an xbox controller, and read sensor data back from it. All of this could be done with one usb line, which could use the whole tether cable. I also plan on removing the brass fitting at some point, because it’s too difficult to insert the board.

Overall this project was a success. Even though we were not able to test the ROV with the electronics yet, given unforeseen complications, we were still able to construct a functional ROV. We learned much from each other and our struggles.