Harris Mohamed

Sentinel Prime

Overview

Sentinel Prime was a continuation of Project Sentinel. Sentinel Prime's goal was to detect and classify 3D objects in indoor environments in real time. Originally, the idea was to pair Sentinel with a camera and use the existing LIDAR sensor, then employ a signal fusion network to combine the data and outperform existing 2D and 3D pipelines. Then, the computation would be performed on an FPGA or embedded device to attain real-time computation. However, I set my timeline a little too aggressively. At the start, my approach was to use an NVIDIA Jetson Nano to run existing KITTI models (KITTI is a challenging 3D dataset, a useful benchmark for 3D object detection and classification). The Jetson Nano actually gave me a lot of grief. The primary issue was the ARM-based architecture, which required me to build several libraries from scratch, which took an extremely long time. In the end, I was only able to get a few models running, and had very little time to actually pair the camera and LIDAR sensor. However, I got to explore the state of the art in 3D classification, including testing of Google's Objectron model as well as some of the top-performing KITTI models. I also learned a lot about how to allocate time and perform literature reviews. Even though functionally Sentinel Prime was a failure, I learned a lot and will carry this forward in my career.

I also got the chance to test out some virtual simulators such as Microsoft AirSim, which I definitely aim to return to for another project.

Screenshot captured in the middle of an AirSim simulation

Advisor

Professor Deming Chen

Close Window

Project Sentinel

Video summarizing Project Sentinel

Overview

Project Sentinel doubled as my junior year research project as well as a submission to the 2019-2020 TiM $10K Challenge. The TiM $10K Challenge is an annual competition hosted by SICK. Inc, a German company that manufactures sensors for factory and logistics automation. The goal of the challenge is to use a TiM781 2D LIDAR sensor in any unique way. A colleague and I heard about this challenge and sent a proposal for an autonomous robot that could navigate indoor environments and detect intruders. This was inspired by the lack of any companies developing indoor LIDAR applications (the only company we could find had went bankrupt). Our proposal was accepted and we set out to design the robot. My colleague designed a novel mechanism which could rotate the LIDAR sensor in 3 dimensions, in a gimbal-like fashion. The robot would use a SLAM algorithm to map the environment. Unfortunately, the complexity of the algorithm and the time constraint of being a full-time student in college led to the algorithms never being finished. Even though we did not place in the competition, we were extremely proud of the progress we made. As electrical lead, my responsibility was to get Sentinel operational and communicating with the various sensors and databases.

Robot sensors and hardware

• MPU-6050 accelerometer, which was used to correctly orient the LIDAR data in 3D space
• The robot's ambulation was controlled by 2 motors and the robot mechanism was controlled by its own motor.
• Arduino MEGA: Control the motors with a PID algorithm was tuned to rotate the mechanism in a smooth manner.
• Raspberry Pi 3: Communicate with LIDAR sensor via Ethernet. Communicate with AWS servers using WiFi.

Sentinel in all of his glory

Software

• Point-cloud clustering algorithm implemented in Python
• AWS DynamoDB for data storage and S3 buckets to store visualization files
• Electron application to view environment scans

Screenshot of the Electron application with a point cloud loaded in

Close Window

Project Hybris

Overview

I've always had an interest in using AI for text generation. One of my friends is a part of a website called Hybris Forum where they publish articles discussing technology, culture, and the dysfunction of technology with society. That same friend suggested I write an article as well, but writing it definitely not my strong suit. This was the perfect opportunity to experiment with text generation AIs. The current state of the art is GPT-3, a transformer network developed by OpenAI. Unfortunately, GPT-3 is not available to the public, because the text it generates is too realistic to that written by humans.

Rather than go through the effort of training my own network, I decided to use GPT-2. The creators have open sourced a smaller version of GPT-2, which implies that it is bad enough to be given open access to, which is something I found out firsthand. The way I generated the article was by writing a long essay, and then finetuning the 355M model of GPT-2. After this, I generated lots of output text with input prompts. It was pretty painful to sort through the outputs and get something usable, and after spending a few days I didn't have enough text for an essay. Out of frustration, I turned to InferKit, a working demo of GPT-2. This was useful for the transitions in the essay.

Check my Git to find the final Colab notebook I used. Unless GPT-3 gets released, I won't be pursuing this project any further. I would honestly call this a failure, but the final essay (also on my Git) is pretty coherent.

Close Window

Custom pipelined RISC-V implementation

Overview

The RISC-V pipelined CPU is the capstone assignment in ECE 411: Computer Organization and Design. This is an intensive course that teaches fundamentals in computer architecture and then those fundamentals are designed in System Verilog. Working in a group with 2 others, we designed a 5-stage 32-bit classic RISC-V processor that could perform hazard detection and data forwarding.

My contributions

I played a significant role in implementing the base CPU and had the chance to augment the CPU with the RISC-V M extension, which supports multiplication and division operation. I decided to use the well-known Wallace Tree to achieve a faster multiplication than an algorithm like add-shift. For the divider, I used a shift-subtract algorithm.

Future work

Although I enjoyed this course, I feel that I could accomplish a lot more with more time. I am planning to revisit this CPU design and augment additional features, such as a tournament branch predictor, multiple-way L1 caches, and . My ultimate goal is to program an FPGA with this CPU and run actual code on it. I might even pursue Tomasulo’s algorithm, as that algorithm makes much more sense to me than a pipeline. Due to academic integrity violations, I can’t upload the CPU from my class but I will update my GitHub if I make something else not in a class.

Close Window

Blender

Overview

I have always had an interest in 3D design, modeling, and rendering (very much reflected by my research interests). I’ve been learning Blender ever since I built my new desktop. I am still a novice, but I have a few intro projects I have completed, and have many more planned. I upload all my renders on my VFX YouTube channel, Ethereal Studios.

More coming soon! I plan to experiment with physics simulations and video compositing.

Close Window

Project Loveless

Overview

I recently downloaded and began visualizing some of my Facebook Messenger messaging data, which led me to consider what an AI would think of my messages. This project will use AI to analyze intent, emotion, mood, and predict future messages. This project will be its own website at some point. More to come soon.

Close Window

Eigenmask

Overview

This was the final project for ECE 420, Signal Processing Lab. The final project is to take any signal processing application described in a paper and implement it on an Android app. I worked with a partner to create Eigenmask: an application of Eigenfaces with the purpose of distinguishing not only who the person is, but whether or not they are wearing a mask.

Process

The Eigenface algorithm works by finding the eigenvectors from the covariance matrix of the probability distribution over the extremely high-dimensional vector space of face images. This provides dimensionality-reduction, and unknown faces can be classified by comparing them to the eigenvectors determined in training. Training was done on Python, and this was ported over to Android. The project was a success, able to distinguish a few friends and I, as well as whether we were masked or maskless.

Close Window

CUDA-accelerated raytracing

Overview

This was the final project for ECE 408, Applied Parallel Programming. We had a selection of open-ended problems to choose from for our final; my group and I chose to speed up the smallpt implementation of raytracing, which only works on spheres.

Output of the raytracing algorithm

Details

The smallpt implementation of raytracing works by passing in a description of the “scene”, which consists of objects (spheres), lights, and a camera. The algorithm then approximates the complicated rendering equation by replacing the ray integral with a monte carlo sample that has the same average value as the integral. A series of samples are averaged to output a smooth image. The picture above is an example of the output of the raytracing algorithm. We were given the original smallpt implementation, which was run on a CPU and served as our benchmark to beat. The sequential implementation uses a recursive approach to approximate the rendering equation.

The algorithm was ported over to CUDA by utilizing two CUDA kernels. The first kernel is used to initialize random numbers and the other kernel is for running the ray tracing code parallelized across the pixels. For the class, we had to time our kernels on the university GPU cluster, which uses TITAN V GPUs. I used my 2060S to test out the code locally.

After porting the algorithm over to CUDA, we further improved the raytracing algorithm by:

• Downsampling: A good enough image (constrained by the professor to be ~100 MSE when compared to the sequential output) can be achieved by passing in less samples for the monte carlo portion of the algorithm. In the original implementation, we used 5000 samples, but we were able to reduce this by half and remain within the bounds. This kind of output could be upscaled using DLSS if a higher resolution output is required.
• Depth constraining: The ray bounding portion of the algorithm is where the load imbalance comes in. Not every ray in the scene bounces the same number of times, so not every thread does the same amount of work. I confirmed this by using the NVIDIA Nsight Compute Profiler on my personal GPU (2060S). The profiler warned me that we were exceeding 80% of the GPU compute resources and it pointed to the radiance function as the source. After some experimenting, we noted that rays that continue after 10 bounces do not contribute to the final image enough, so we capped the ray bounce limit to 10.
• Double replacement: The original code used doubles, which we replaced with single-precision floats. This uses half the bits but gets an acceptable MSE.
• Fast math: There is a compiler option called -use_fast_math. This flag tells CUDA to use intrinsic float functions that are faster but might be less accurate. This aggressively optimizes the float functions, and I saw a huge speedup on my personal GPU.

Our results are summarized below:

Algorithm	System	Code	Time(s)	MSE
Sequential	Ryzen 7 2700X	Sequential, Iterative	2040	N/A
Downsampling	TITAN V (RAI)	Parallel	14	50.27
Downsampling	NVIDIA 2060S	Parallel	141	49.9
Depth Constraint	TITAN V (RAI)	Parallel	13	31.5
Depth Constraint	NVIDIA 2060S	Parallel	13	32.6
Single-point floats	TITAN V (RAI)	Parallel	19	32.4
Single-point floats	NVIDIA 2060S	Parallel	17	32.5
cuRAND	TITAN V (RAI)	Parallel	10	33.2
cuRAND	NVIDIA 2060S	Parallel	14	33.3
All optimizations combined	TITAN V (RAI)	Parallel	2	50.5
All optimizations combined	NVIDIA 2060S	Parallel	3	50.5

Close Window

LC-4

Overview

This was the final project for ECE 391, an intensive design course where I worked with a group of 4 to write code to design a unix-like operation system. This operating system (dubbed LC-4 after our university’s toy ISA, LC-3) featured device drivers (for terminal, file system, interrupt controller, real-time clock), support for system calls, context-switching, virtualization, and a round-robin scheduler.

Details

The following are some details that I worked on to implement this OS.

• Device Drivers
  • Interrupt controller: I programmed the PIC-8925A interrupt controller to interface with our OS. After this was complete, we could have the keyboard and real-time clock register as interrupts.
  • Real-time clock: All programs need some way to track time. I studied the datasheet for the RTC chip in order for it to interface with our OS.
• System calls
  • Once the interrupts were enabled, I set up support for system calls to be made.
• Context-switching
  • In order to run user programs, there is a context-switch that needs to happen: from the kernel space to the user space. This context switch needed considerable assembly code and something or other
• Scheduling
  • This was one of my favorite parts of the OS. At the point, we had three terminals and coded them such that they ran all at once. The scheduler would context switch between all 3 terminals using a special clock chip that was connected to interrupt line 0

One of my group members uploaded a video of our final OS here.

Close Window

Project Watchdog

Overview

innovateFPGA is a competition hosted by Terasic, where FPGAs are applied towards problems that involve AI at the edge. In this vein, my colleague and I submitted a proposal for Project Watchdog, an FPGA-based smart home security camera that performed all classification locally and only sent the output of the classification to a computer, thus reducing the amount of bandwidth needed to send video to an external server. In addition, this solution does not need an internet connection to perform a classification.

We placed as regional finalists in the competition, and our full write-up can be found here .

Close Window

Project LD

Overview

This was our final project for ECE 385, an introductory course about realizing digital designs on FPGAs. The project is named "Project LD", which is short for "Projects Legends Never Die", which is a nod to our professor, whose profile picture on our class website is the "Legends Never Die" meme.

Details

This project was originally meant to be augmented reality beer pong (without the beer). The goal was to track a bouncing ping pong ball using a camera in 3-dimensions in realtime and then superimpose the path of the bouncing ball on the video feed as well as superimpose the path that should have been taken to get the ball into the cup. We were able to get a successful 2D track of the ball's position and scale, but did not have time to work on the 3D track. For this project, we used the DE2-115 expansion board with the Altera Cyclone IV E FPGA. We were provided with the 1.3 megapixel camera module, and spent a majority of the project interfacing the camera with the FPGA. By the end of 2 weeks, we were able to have a fully functioning 1.3 megapixel camera outputting its feed via VGA to a computer monitor. In addition, we were able to interface the NIOS II E microcontroller as a System-on-chip to toggle the camera settings. We made heavy use of exposure, red gain, blue gain, and green gain settings to achieve the best picture quality we could. The tracking was done very similar to how the visual effects software Adobe After Effects achieves its 2D motion track: In After Effects, you choose the point you want to track, and it generates a small box on the screen. Frame-by-frame, it then tracks the change in position and scale by looking at the change in high contrast points within the box. We made an FPGA-module to do the exact same thing, except in realtime. It worked rather well, but could not keep the track if the ball was dropped. The reason for this is we need to add a module that accomplishes frame interpolation. Since a falling ball falls very fast relative to the frame, comparing the frame before the drop to the frame after the drop will show a large vertical change between frames. Frame interpolation will guess where the ball would have been between the frames, and would allow for a much better track.

Progress video

Close Window

HackMe

The HackMe Group

Overview

Every year, UIUC holds a competition called a Hackathon. The hackathon is a 36-hour competition where the competitors are asked to design (usually code) anything. At the end of the 36 hours, the results are judged based on merit and usefulness of the submissions. One of my friends has always had an interest in the concept of Electroencephalography (EEG waves). While usually used for diagnosing brain disorders (such as epilepsy and seizure-related disorders), there is actually much more information that can be gleaned from these EEG waves - and this premise is where Project HackMe was born. Everyone's brain generates miniscule electrical impulses (miniscule here meaning ~50 microvolts). By finding the frequency of these waves and then doing some signal processing, we can characterize a person's state. One of the key features of our project to show we could do all of this non-invasively and still gather useful information from the data gathered. Then, we can map a person's waves to thoughts by using advanced machine learning techniques.

Details

The idea is novel, but is a bit ambitious for a 36 hour competition. Instead, we set out to do a proof of concept where we would show that waves could be captured and then translated to a rough thought. My friend had already purchased some electrodes. We then took these electrodes and fed them directly into a 24-bit ADC (During the competition, there was no additional filtering done to the signal. Given more time, we would have designed a low pass filter circuit to properly filter the input signal). The ADC was a part of a Raspberry Pi 3 shield, which allowed us to easily access the data using simple Python scripts. Since the Raspberry Pi has WiFi built-in, it was simple to upload this data to an Azure database (we used Azure because it was free, however, it was not worth it. We lost countless hours trying to set it up on the Raspberry Pi). Once the data was on the server, the project split into a few different areas: Internet of Things (IoT) and Classification. These sections are discussed in more detail below.

IoT: As a commercial product, we imagined this being a beanie. The concept was that the beanie could house a custom PCB to perform the wave extraction and signal processing. It would then send the results to the cloud for further post processing and analysis. The idea of a beanie came up because people wear beanies for extended periods of time and we would be able to extract much more data and thus make meaningful observations on the resulting data. To demonstrate an IoT application, we showed that we could toggle the lights in a room just by thinking. This was shown by hooking an LED up to a Particle IoT board and toggling it based on the output from the EEG headset. We ended up with a very sophisticated mood ring.

Classification: Analyzing the frequency content of the waves can indicate the general feeling of the user. Some of the most common EEG waves:

• Delta (3 Hz): Most commonly found in deep cycles of sleep
• Theta (3.5 to 7 Hz): Most commonly found in children. Implies an abnormality in the person if they are an adult
• Alpha (7.5 to 13 Hz): Most commonly found in people who are relaxing and is eradicated by any deep concentration
• Beta: (14 - 38 Hz): Most commonly found in people who are thinking a lot of thoughts at once
• Gamma: (38 - 42 Hz): Greater than the frequency of neuronal firing, gamma waves relate to processing of different brain areas at once.

The data was sent into a rudimentary Matlab linear classifier. Given more time, this would probably be implemented with a CNN that would be trained per individual user. This project was very well received at the 2019 Hackathon. It won the Caterpillar and Particle Design Awards, and was also a runner-up for the Hackathon. More information can be found here.

Close Window

DAQA Leader for Illini Formula Electric

IFE competition, summer 2018

Overview

Illini Formula Electric (IFE) is a club at UIUC where we design and build a formula-style electric racecar from scratch. The club is entirely student-run. In the summer we compete at the FSAE competition in several events. I was a member of IFE for two years, detailed below.

2017-2018

We were limited to 300V (that limit has since be raised to 600V). The battery that our car runs off of is comprised of 336 LiFePO4 cells that are wired together in a series-parallel combination that yields 300V and 175A overall. The competition rules require us to monitor the temperature and voltage of each battery cell. The old method of doing this was using the Elithion Proprietary Battery Management System (BMS). This system only runs on very old team laptops, which are archaic, cumbersome, and limited to a hardwire connection. As a freshman, I designed a PCB that could read data off the CAN bus and then output it over bluetooth to a laptop. I also developed a GUI that was capable of outputting the data in realtime. This was done in C# using the .NET framework.

Screenshot of GUI application

2018-2019

After my first year on IFE, I got promoted to the leader of the Data Acquisition and Quantitative Analysis (DAQA) team, whose primary goal is to log data from all the sensors on the car, timestamp them, and then upload it to a server. It gathers data from 4 accelerometers, 30 strain gauges, a GPS, the position of the steering wheel, the coolant temperature, the brake pressure, the throttle and regen pedal potentiometer, CAN, hall effect sensors, and the voltage of the low voltage battery pack. The system consisted of Raspberry Pi Zero boards with a custom PCB on top of each Pi. There would be one board near each tire and one in the center, by the driver's seat, which would distribute the data evenly across each board. Each Pi would then send data to the central pi, which would then timestamp and upload the data. The data would then be parsed and analyzed using AWS. Due to time constraints and hardware issues, the final system did not work as intended. However, it was a valuable learning experience.

Render of board developed for DAQA

Close Window

Smart Home

Overview

My attempt to make a secure, AI augmented version of my apartment. More to come soon!

Close Window

OCR & Dyslexia

Overview

As part of the 2018 ECE PULSE competition, me and 3 other group members interfaced a Tobii eye tracker with a C# application to assist those with dyslexia. This would operate by using OCR to analyze when someone is trying to read text on a computer screen and based on how long someone is looking at text, analyze if they are having trouble reading it. Then, it can take the data and then graph it. Due to time constraints, we were only able to get the eye tracker data and figure out what parts of the screen were being looked at. We were 2nd place runners up in the competition.

Close Window

STEVE

Close up of STEVE's flight controller

Overview

S.T.E.V.E. (which stands for Self Teaching Elevated Vehicle Entity), is a drone designed from scratch that was designed to serve as an aid during natural disasters. S.T.E.V.E. was designed for Senior Tech, which was a high school capstone course where we could work on any STEM related project for a year. The concept was to create an autonomous drone capable of surveying locations where individuals stranded in dangerous situations could be without risking the life of an emergency responder. To accomplish this, we made a fully featured drone with a custom flight controller, camera to view the surroundings (to live stream what the environment looks like back to a VR headset at the base station), a speaker with an onboard AI (to communicate to a victim of a natural disaster), and sensors (to make sure it doesn't fly into any obstacles as well as update location). Even though we were extremely ambitious and did not meet all of our goals, this project was ultimately a success. The project was met with high praise and was presented at a limited engineering expo at Navistar. This is also the project that made me realize I wanted to be a Computer Engineer, as this project was worked on during the time in which I applied to colleges. Working on this project made me realize my love for combining hardware and software to produce something greater than the sum of its parts.

Progress video

Flight Controller

A crucial part of any drone is the flight controller. The flight controller is responsible for controlling the speed of each motor to Most drone projects will use an inexpensive off-the-shelf flight controller that takes care of all the flight algorithms. All you have to do is plug in the motors and battery to have a functional drone. However, we thought it would be better as a learning experience if we designed and programmed the flight controller from scratch. We used an Arduino MEGA as our primary microcontroller and an inexpensive MPU-6050 as our Inertial Measurement Unit (IMU). We then progreammed a PID controller to realize our flight controller. This took a bulk of our school year (and grew into a thousand line plus program) but was an incredibly rewarding experience. The microcontroller was programmed in C/C++ using the Arduino IDE.

Proof of concept of PID

Camera/Virtual Reality Headset

The goal here was to come up with a way to stream camera footage from the drone back to a virtual reality headset. This could be used to allow emergency responders to remotely survey a disaster area without the need to send in personnel. From an engineering standpoint, it is an interesting feature to try to implement. We used a Raspberry Pi 3 as the computer and Raspberry Pi Camera for the camera. There were two reasons we went with this combination: (1) Raspberry Pis (and their cameras) are cheap, easy-to-use and well documented, and (2) This allowed to split the hardware for the project into two categories: flight essential and not flight essential. One of the most important factors optimized in a flight controller is how long the main loop of the code takes. The faster (typically) the better. By separating the hardware into what was essential for flight and what wasn't, we could could aggressively optimize the flight controller and still have other devices on the drone. If we tried to get the Arduino to compute and transfer the camera footage, the flight loop might get severely impacted and the drone would no longer fly smoothly.

Speaker/AI

This is also not flight essential hardware and was supported by the Raspberry Pi (this was made simple by the fact that there is an audio out jack on the Pi). The main goal here was to give STEVE a natural language artificial intelligence so that STEVE could talk to people and let them know help is on the way. The initial thought was to use simple if-else constructs and hard-code the speaker outputs (i.e. "Help is on the way"), but then we had the idea of using IBM AI APIs to get a natural language output from the Raspberry Pi. After struggling for a few weeks with the IBM documentation, we contacted them and they sent us a sample Android app that used their APIs. After this, it was easy to link this with the Raspberry Pi and output it through the speaker. We trained the AI and attempted to make the outputs as helpful as possible in the relevant situation.

Object detection and location updates

One fundamental aspect of a drone is to not fly into nearby objects. Real drones use laser-detection to detect nearby objects, but those sensors are expensive and difficult to get working so we chose to use inexpensive ultrasonic sensors. Our end goal was to have 6 sensors in each axis, 3 in each direction (for instance, we would have 3 pointing directly upwards and 3 pointing directly downwards, thus covering the z-axis). We used a MUX shield, which adds 37 additional inputs to the Arduino and we ended up writing our own custom drivers to capture the ultrasonic values (it turns out provided library functions start to fail when you try to use an external shield). The driver code worked perfectly fine, but due to time constraints we were not able to interface it with the rest of the drone. We were able to add an off-the-shelf GPS module, which was capable of logging the drone's coordinates. Combined with the ultrasonic sensors, we were able to show that we could capture coordinates in 3-dimensions.

GPS output visualized

Even though we were not able to meet all of the goals we set for the project, we consider STEVE an incredible success.

Close Window

Shipping Generator

Overview

The first programming language I learned was Javascript. From there, I use Codeacademy to learn HTML and CSS, and I was cranking out simple, unaesthetic webpages like nobody's business. During high school, a trend that took off (and is still extremely relevant today) is "shipping" people together. "Ship" is short for relationship, and it essentially means pairing people together as couples. This idea led directly to the Shipping Generator. We loaded everyone's name from our classes, and everytime "Generate" was clicked, a boy's name and a girl's name would be chosen at random. Incredibly simple, but the project took off and soared in popularity. The generator got hundreds of page requests a week, a lot of which was actually during class time, since the website was not blocked by the firewall. People began asking for more features, the most prominent of which ended up being a leaderboard. Designing a leaderboard in high school with no concept of what databases were was actually a difficult task, but we ended up having the website complete a Google Form and then had a public readonly spreadsheet where we sorted the results. This led to people figuring this out and filling out the forms themselves, which led to us adding in obfuscation and security features. While rudimentary, still one of my favorite projects that I have worked on.

Close Window

NVIDIA

Overview

I will be a computer architecture intern this summer. This page will be updated after I have completed my internship!

Close Window

Kratos Defense and Security Solutions

Overview

Due to COVID-19, my internship at Kratos was online. I had two projects. The first project was a Python migration task. The company has a python script which intercepts HTTP requests from a website, grabs data from a map server, and then sends this data back to the webpage. The existing python code was written in python 2.7 and the original requirement was to rewrite this script in python 3. A coworker actually finished this project using C# before I was able to finish it using Python, but it was still a valuable learning experience.

My second project was writing a thread safe queue that could receive RF packets and then parse them. One thread would continuously receive packets and place them on a queue, and another thread pops the packets and parses them. This project was extremely interesting and allowed me to explore multithreading in a professional environment.

Close Window

Kratos Defense & Security Solutions

Overview

I went to the company in Colorado Springs, Colorado for the summer. This was really my first introduction to a defense constractor and I really enjoyed it. My summer was split into two tasks.

My first task was software. The team I was on worked on a tool that could take in satellite transponder data and output many useful visuals primarily in the field of Space Situational Awareness, such as satellite position prediction and bandwidth utilization. This tool's frontend was programmed using Angular JS, and my first task was to create a testing suite for the UI. Once I finished that, I moved on to add some features and fix some bugs with the GUI.

My second task was hardware. There was a narrow-bandwidth high-speed FPGA-based digitizer, which was designed to sit at the base of an antenna and in real time, quantize incoming packets. The digitizer had actually been put aside, with no progress made on it for a year due to the fact that the clock on the board was not locking. After quite a lot of hours spent in the lab, the error was revealed: the input clock signal was specified by the datasheet to be AC-coupled, but by accident was DC-coupled. Fixing this issue allowed the board to function properly and move on to next phases of testing.

Close Window

Continental Automotive

Overview

I worked on a board which was intended to become an electronic torque redistribution tool for a car. The board needed to have a diagnostic mode, so that engineers working on the board could enter an "admin" mode and run any command. I added a new CAN header which would allow the user to do just that. I had worked with CAN bus previously with Illini Formula Electric, but this was my first working with CAN in a professional environment. Instead of using Arduinos with CAN shields, I got to use the Vector suite of CAN tools to test out my code and make sure it was working.
I also debugged a watchdog timer on the board, which was continuously sending a reset signal back to the microprocessor, rendering the board useless. After some debugging, it was attributed to an erroneous line of code triggering a reset.

Close Window

Weber Packaging Solutions

Overview

This was my first internship. I worked on python code to automate a number generation process. I also learned how to use Visual Studio to develop windows apps using the .net framework and C#. I also used Inventor to update CAD drawings that had 1000+ parts.

Close Window

ECE 385 UA

Overview

After Project LD, my professor invited me to become a part of course staff. I accepted, and now hold office hours and help students with their projects. I am currently looking into implementing a class discord for office hours that is authenticated with Shibboleth and the Queue system. I have already implemented a Queue system which is used by other TAs for office hours.

Close Window

ECE 411

Overview

This course is an intensive introduction to the fundamentals of computer architecture. Design principles were applied when realizing these concepts in System Verilog.

Concepts covered:

• Basic computer organization and design
• Integer and floating-point computer arithmetic
• Control unit design
• Pipelining
• System interconnect
• Memory organization
• I/O design
• Reliability and performance evaluation

Close Window

ECE 420

Overview

This course involves applying signal processing concepts learned in earlier courses to create Android applications that can run real-time signal processing algorithms.

Close Window

ECE 448

Overview

This course covers several topics relating to search, classification, reasoning, machine learning, games, planning, robotics, computer vision, and natural language understanding. Among the most relevant and useful of these was using PyTorch to quickly test and tune neural nets.

Concepts covered:

• AI languages and formalisms
• Problem solving
• Knowledge representation
• Deductive inference
• Inductive inference and machine learning
• Natural language understanding
• Computer vision
• PyTorch

Close Window

ECE 408

Overview

This course teaches how to use CUDA C++ to drastically speed up the speed of sequential programs. I really liked this course, and ran some of the algorithms on my personal GPU.

Concepts covered:

• CUDA basics
• Tiling
• Reduction and Scan operations
• Tiling to speed up convolution
• Different methods of sparse matrix multiplications
• Speeding up raytracing using CUDA

Close Window

ECE 391

Overview

This course is all about the synthesis between hardware and software, working together to make a Linux-like operating system. This starts from nothing more than a few boot files. The final operating system has a read-only filesystem, interrupt support, device support (Keyboard, Interrupt Controller, Real time clock), paging, and a round-robin scheduler for multitasking. The operating system was completed in a group of 4.

Concepts covered:

• Interfacing C to assembly, macros, stack frame and calling convention
• Synchronization: primitives, memory semantics, mutual exclusion, semaphores, scheduling, and race conditions
• Interrupts: controlling generation and handling, chaining, cleanup code, interactions with device functionality
• Resource management: virtualization and protection, virtual memory and hardware support
• Exceptions and signals: exceptions due to instructions, memory accesses, and floating-point operations; signal semantics and delivery
• Device programming: basic abstractions, character and block devices
• File system abstractions: disk layout, access control lists and capabilities, log-structured and traditional filesystems as design problem
• I/O interface: file descriptors, buffering, control operations, memory mapping

Close Window

ECE 310

Overview

This course covers the theory of Digital Signal Processing. The course was heavy in mathematics, but I've seen the concepts from that class show up in several places: the lab, my internships, etc. I also took the associated lab section, where we used Python to visualize a lot of the concepts taught in the classroom.

Concepts covered:

• Discrete-time linear shift-invariant systems
• Difference equations
• Convolution and impulse response
• Z-transform
• Transfer functions and block diagrams
• Discrete-time Fourier transform (DTFT)
• Sampling Theory
• A/D and D/A conversion

Close Window

CS 498

Overview

This course had several projects that introduced me to networking and general IoT applications. The most prominent and relevant of these was AWS.

Concepts covered:

• IoT device programming (Arduino and Raspberry Pi)
• IoT protocol stacks (Zigbee, 5G, NFC, MQTT, etc)
• Networking backhaul design and security enforcement
• Cloud-based IoT platforms such as AWS IoT

Close Window

ECE 385

Overview

This class covers several topics that are important to the field of programming and using FPGAs. Similar to parallel programming, impressive speedups can be achieved using FPGAs. This was one of my favorite courses.

Concepts covered:

• Combinational logic circuits
• Storage elements
• Hazards and race conditions
• Circuit characteristics (fanout, delays, etc.)
• Field Programmable Gate Arrays (FPGAs)
• Combinational networks (adders, multiplexes, etc.) in SystemVerilog
• Sequential networks (counters, shift registers, etc.) in SystemVerilog
• Synchronous state machines
• Static timing analysis, clock domains, metastability, and synchronizatio
• Logic simulation and testbenches
• Microprocessors and system on chip

Close Window