
**A photo of the Bang Bang Boom Box (B⁴), our hardware testing apparatus**

**Take a look at [the avionics system design](/posts/cms-avi-hw) and
[PSPieChart](/posts/pspiechart) posts to get context on this document.**

This document is a direct continuation of Avionics System Design and details information about flight and GSE software for Purdue Space Program Liquid's next rocket, the CraterMaker Special.

## Flight Software

### Development Environment

The RP2040 has a very well-documented and easy-to-use SDK written in C.
Everything can be configured to CMake.

The first step to start developing software for the rocket was determining the
source tree organization and writing a build system.

I decided on using a single `CMakeLists.txt` at the project root so that it'd be
easier for new members to work without worrying too much about the build system.

The build process also includes `ccache` for insanely clean builds.

This is how the source code is organized

```
PSPL_CMS_Avionics_Code/
├── README.md <- This file
├── src/ <- contains main programs for each board
│   └── someprogram/ <- Main program folder, i.e., for a board
│       ├── someprogram.h <- All header stuff for this program
│       ├── main.c <- Contains the entrypoint
│       └── other.c <- Other source files
├── lib/ <- common libraries shared by all boards
│   └── example/ <- example library
│       ├── example.c
│       └── include/ <- header files, added to include path
│           ├── example.h <- top level header, included with `#include <example.h>`
│           └── example/ <- secondary headers
│               └── whatever.h <- included with `#include <example/whatever.h>`
├── external/ <- Gitignored, for automatically downloaded libraries
├── include/ <- Global include directory, used for configs and stuff
├── build/ <- not uploaded to the repo, contains compilation outputs
│   └── bin/ <- contains the files to be uploaded to the boards
├── .clang-format <- file containing autoformatter rules
├── .gitignore <- file containing things to not be uploaded to GitHub
├── Doxyfile <- Doxygen Documentation Generator Configs, mostly autogenerated
├── CMakeLists.txt <- Main build script
└── Makefile <- User-friendly build script, calls CMake
```

Finally, there's a top-level `Makefile` which handles dependencies, compilation,
and generating the compilation database (for intellisense)

Though Doxygen _is_ used for generating documentation, it's not commonly
used, and we usually just refer to the docstrings.

The dependencies for flight software development are very minimal, needing only
ARM GCC and newlib to get started. And as of writing this, everything clean
builds (with ccache cleared) in under 15 seconds.

### Peripheral I/O

The main peripherals on this rocket are ADCs, storage devices, radios, Ethernet
(more on this later), and digital output for pyro channels.

Digital outputs are easy enough, pico-sdk has all the code infrastructure
needed for that.

One of the requirements we have for peripherals on the rocket, which most of our
selected parts comply, is that they communicate over SPI.

SPI is a fantastic protocol and can be abstracted away to the level of
selecting a peripheral, and sending and receiving a bitstream to the peripheral
at a specified rate.

The process of writing the drivers themselves is mostly straightforward -
implement the protocols that the chip manufacturers specify in the datasheet.
The first version of the driver is always a fully synchronous version, i.e., all
communication with the device is commanded by the main thread. This makes it
easy to meet deadlines when it comes to upcoming tests.

The next step is implementing interrupt-driven I/O. For our purposes, this isn't
necessary 99% of the time, but it becomes a problem whenever we run any
long-running subroutines. On the hardware side, DRDY's from peripherals are
connected to a GPIO pin, which can be used to trigger a subroutine, to say, read
data off of an ADC and add it to the queue to be stored and transmitted.

Implementing DMA isn't really at the highest priority though - the only place
where it's applicable would be the Ethernet and Flash drivers. Devices
like the ADC read short bursts of data triggered by interrupts, and we decided
that it's not worth the effort to implement DMA for these devices.

**Fun fact: the RP2040's DMA system is turing complete. More info
[here](https://hackaday.com/2023/01/20/help-needed-on-thumb-image-rp2040-dma-hack-makes-another-cpu-core/)**

### Network Stack

The network stack was nicely handled for us by the W5500 chip,
which is what we use to add Ethernet capability to the RP2040. Communicating
over SPI, it includes a hardwired TCP/IP stack, with 6 sockets.

All we need to do is write a driver to access this functionality, and abstract away details such as socket creation, buffer management, configuration, etc. I won't be going into much detail about this driver, but you can read the datasheet for the chip [here](https://cdn.sparkfun.com/datasheets/Dev/Arduino/Shields/W5500_datasheet_v1.0.2_1.pdf)

### Communication Protocols

![CMS communication lines](/assets/cms-comm-lines.png)
_This is where the fun begins_

At the launch site, the rocket, the GSE system (Black Cat Launch System, BCLS),
and the launch operators' computers are all connected over
Ethernet.

While the rocket is on the ground, there are two primary requirements for
communication with the rocket.

- We need live sensor data to be available to operators
- We need remote procedure call capability

The EMU board is fully responsible for the launch countdown and autosequence of
this rocket, so RPC capability is important.

But first - how do we stream live sensor data from the boards to each other and
the ground?

My solution - **SensorNet**. The concept is very simple, it starts with this
struct definition.

#### SensorNet

```c
typedef struct {
  u16 sensor_id; // globally unique
  u64 time; // microseconds since UNIX epoch
  u64 counter; // per sensor
  i64 data;
} sensornet_packet_t;
```

The system is very straightforward - take one or more of these packets, put them
on a UDP packet, and send them on their merry way.

Decoding is simple enough. If it's another flight board decoding, it just has to
cast the packet it read to `sensornet_packet_t*`. On the ground side, just
manually decode the binary data. There are plenty of libraries for most
programming libraries to handle this.

Doing things this way has the blazing fast serialization time of 0ms.

On the networking side of this - each flight board (EMU, LFC, UFC), will have a
UDP multicast group IP assigned to it, and any devices interested in data from
that board can simply open a socket listening to that multicast IP.

#### CommandNet

Now this is slightly more complicated.

I concluded that we need two features from CommandNet

- The ability to directly set the values of certain variables
- The ability to call functions that don't have any parameters.

I see this as basically a more complicated version of the "set registers, run
instruction" model.

In order to simplify the implementation of both sides of this protocol, I
decided to go with MessagePack, which is a JSON-like binary format for
serializing information. Neither throughput nor latency was an important factor
for this application, so we prioritized simplicity. These packets would then be
sent over a TCP connection to the rocket.

This is the protocol "spec":

```
Request-response protocol for sending commands over a TCP socket
Request format:

[request type(u8), args...]
EXEC_CMD: [EXEC_CMD, command name]
ALL_CMDS: [ALL_CMDS]
SET_VAR: [SET_VAR, variable name, value]
GET_VAR: [GET_VAR, variable name]
ALL_VARS: [ALL_VARS]

Response format:
[status(u8), args...]
EXEC_CMD: [status(SUCCESS/ERROR)]
ALL_CMDS: [status(SUCCESS/ERROR), [command 0 name, ...]]
SET_VAR: [status(SUCCESS/ERROR), old value]
GET_VAR: [status(SUCCESS/ERROR), value]
ALL_VARS: [status(SUCCESS/ERROR), [[var 0 name, var 0 value], ...]]
```

All names are strings (I know, strings are evil), and all values are 64-bit
integers.

A full CommandNet exchange would take place as follows:

```
+---------+             +---------+
| Client  |             | Rocket  |
+---------+             +---------+
     |                       |
     | Open TCP Socket       |
     |---------------------->|
     |                       |
     | Send request          |
     |---------------------->|
     |                       |
     |         Send response |
     |<----------------------|
     |                       |
     |      Close TCP Socket |
     |<----------------------|
     |                       |
+---------+             +---------+
| Client  |             | Rocket  |
+---------+             +---------+
```

The way the network at the launch site is set up, it's possible that
people outside our team can plug into the network and send packets to the
rocket - this isn't a problem we expect to encounter, but it's one we have to be
ready for anyway.

To solve this, we simply add AES256-CBC symmetric key encryption, with a key
derived from a passphrase.

Now, instead of sending the bare MessagePack encoded packet, we send a
base64-encoded ciphertext. The reason for using base64 is so that it's easy to
know where a transmission ends by just checking if there's an endline.

### EMU State Machine

The state machine is a failsafe method of performing launch control.
Interacting with this state machine is the primary objective of CommandNet. It
looks like this:

![EMU State Machine](/assets/emu-state-machine.png)

Most of the time launch will be spent in the Countdown - Go/No Go loop.

At preset points in the countdown, the launch operators will need to issue a
Go/No Go to the current poll. If the poll either times out or a "No Go" is
issued, the countdown is placed on hold until manual intervention.

The countdown also automatically goes on hold if there's an off-nominal
situation, whatever that may be.

If all goes well, and the final poll is answered, the state machine goes into
autosequence at a set point in the countdown (T-auto).

In this case, if communication with the rocket is lost before autosequence
starts, the rocket will not launch.

The autosequence phase contains the ignition sequence. A manual abort can be
issued during the autosequence, which would place the vehicle in a safe state.

### DevOps

Back to the boring stuff.

All this software needs to be tested on actual hardware, and it's inconvenient
and expensive for everyone working on software to have test hardware.

To solve this problem, [Taylor](https://www.duchinskiprojects.com/cms-avionics)
devised the Bang Bang Boom Box, the picture at the start of this page.

The box contains a Raspberry Pi which is connected to whatever board is
currently being worked on, through USB and GPIO lines to the RESET and BOOTSEL
pins.

The source files include simple scripts which can then flash binaries to the
board. The RP2040 has a UF2 ROM bootloader, so when it's RESET with BOOTSEL held
active, it shows up as a USB storage device, and the firmware file can be copied
into it to write it to device flash.

The flight software can be compiled either on the Pi itself or copied over.

The Pi is added to a [tailscale](https://tailscale.com/) network, so it can be
securely accessed anywhere there's internet.

## GSE Software

This basically comes down to implementing everything in this data path diagram.

![Data Path Diagram](/assets/data-path-diagram.png)

Every maroon block in this image is a separate piece of software that needs to
be written.

These are the ones with development underway

### PSPieChart

[See this post](http://localhost:3000/posts/pspiechart)

### SensorNet Server

This is a very crucial piece of software with this core requirement

- Log every single SensorNet packet that hits its socket

We selected NodeJS as the platform for this because it made it easy to integrate
REST endpoints for setting and retrieving sensor calibrations, and to add
WebSocket support so that packets can be forwarded to PSPieChart.

We also decided on using InfluxDB as the timeseries database, because it's
popular and fits our needs.

This server includes endpoints to configure sensor ID to name mappings,
calibrations, custom expressions for derived data, and retrieval of historical
data.

### CommandNet Server

This is just a Python implementation of the protocol, with a REST API.


Liquid Rocket Software


**WIP revision of one of the flight boards**

## Background

In Summer 2022, after a 3-hour road trip from LA to the Mojave desert, we arrived at
the Friends of Amateur(FAR) launch site, 30 miles north of Edwards AFB. After
countless hours of setup overnight, we launched BZB for the 3rd and last time.

![BZB Launching](/assets/bzblaunch.jpg)
**Photo by Andrew LaPrade**

BZB is a MethaLOX bipropellant rocket. Built for the FAR-MARS competition by
Purdue Space Program, and designed to reach 35k ft, the project started nearly a
year before I joined the team.

![BZB Cutaway](/assets/bzb-cutaway.png)

**Cutaway render of BZB, me**

BZBs avionics got a few improvements after I joined the team, some of which I
contributed to. But the next rocket, CMS, I'd play a much bigger part in.

![CMS Render](/assets/cmsrender.jpg)

It was decided that this rocket would use a bang-bang tank pressurization
system, where instead of a regulator, solenoid valves would be switched
on and off quickly to flow helium into the fuel tanks. This made Avionics
a critical system of the rocket.

As work on BZB slowed down, [Taylor
Duchinski](https://www.duchinskiprojects.com/cms-avionics) and I got started
working on the avionics for CMS. On his website, you'll find an incredible
amount of detail on the CMS's electronics. The picture of the board above was
designed by him.

As the (other) avionics lead and CS student, I'll be focusing on the system
design, and how we arrived at some of the hardware design choices that we did
for this rocket.

## Microcontroller selection

This one's a never-ending tug-of-war between the CS and the ECE. All things
aside, I would've opted for the **STM32H7** line of MCUs, or at least something
like an **STM32F**. STM32s are great, they have all the performance you need,
and a passable SDK and toolchain. Unfortunately, system design on the rocket
occurred around the same time as a massive chip shortage. Stock for these chips
was uncertain, and we knew we were going to fry more than a few.

With these factors considered, we opted for the RP2040, by the Raspberry Pi
Foundation. Rocking two ARM Cortex M0+ cores and 264K of SRAM, this chip was a
beast by no means. But for our purposes, it was sufficient, cheap, and very much
in stock.

One of my most emphasized factors for MCU selection was how easy it was to
program. With Arduino's at a 10 and whatever NXP is doing at a 1, RP2040 scored
a firm 11.

The SDK for this chip was a single Git repo, and the entire build process could
be managed with a short CMake script.

I mean, just look at this (from the [SDK
docs](https://www.raspberrypi.com/documentation/microcontrollers/c_sdk.html))

```cmake
cmake_minimum_required(VERSION 3.13)

# initialize the SDK based on PICO_SDK_PATH
# note: this must happen before project()
include(pico_sdk_import.cmake)

project(my_project)

# initialize the Raspberry Pi Pico SDK
pico_sdk_init()

add_executable(hello_world
    hello_world.c
)

# Add pico_stdlib library which aggregates commonly used features
target_link_libraries(hello_world pico_stdlib)

# create map/bin/hex/uf2 file in addition to ELF.
pico_add_extra_outputs(hello_world)
```

To top it off, these chips were impossible to brick. I mean it. These
chips come with a permanent bootloader ROM activated with an input pin, so no
matter how much you mess up the firmware, you can always flash it again over USB.

## ADC selection

Honestly, my only constraint was that it communicated over SPI. I2C sucks. We
settled on the ADS131M02. It

- Sampled up to 32ksps
- Used SPI
- Didn't multiplex inputs
- Delta Sigma sampling

And this is all we were looking for in an ADC.

### Why I2C sucks

My hatred for I2C was born after working with the BNO055, a cheap IMU that's
commonly found in older smartphones and model rockets that land themselves.

While writing a driver for this chip, I discovered the lovely fact that I2C has
a "feature" called clock stretching, where if a peripheral device needs the host
to wait, it can pull the SCK line low until it's done.

This excuse of a feature caused me several unnecessary hours of frustrating
debugging, after which I vowed to never work with an I2C device again. And so
far I haven't.

## Inter-board communication

After much deliberation, we decided that the rocket is to have 3 computers (not
for redundancy).

These are as follows

- Engine Modulation Unit (EMU) - closed loop tank pressurization, pyro ignition,
  launch countdown
- Lower Flight Computer (LFC) - all non-critical sensors in the fin can
- Upper Flight Computer (UFC) - all non-critical sensors in the mid-airframe, an
  IMU (inertial measurement unit), telemetry radio, LTE modem

The reasoning for keeping upper and lower flight computers is simple, the
sensors they need to sample are in different parts of the rocket, and we'd
prefer to keep analog wires short.

EMU is a separate board because it's flight critical, and it's the minimum
amount of hardware needed to fly.

With these computers, we need these lines of communication:
![CMS communication lines](/assets/cms-comm-lines.png)

All computers need to store all data (for redundancy). UFC needs data from LFC
and EMU to transmit. GSE needs data from all three, for launch operators to view
while the rocket is on the pad.

Our options were as follows

- SPI
- CANBUS

SPI was very quickly dismissed, because even the thought of routing
voltage-mode, single-ended, physical specification-less wires across the length
of the rocket is the stuff of nightmares.

CANBUS didn't have the bandwidth we needed.

During one of our workdays, I jokingly suggested that we use Ethernet across the rocket, and right after I said that, I realized we found the solution. Ethernet is going to be our mode of communication between the boards on the rocket, and to the ground.

It's perfect, it ticks all the boxes

- Physical spec
- Cheap, proven, off-the-shelf hardware
- All the bandwidth we need

Just one problem - RP2040 doesn't have an Ethernet MAC. But this wasn't a problem at all because, as it turns out, there exists a market for SPI to Ethernet chips, and WizNet happens to make one called the [W5500](https://www.wiznet.io/product-item/w5500/). This, with an [off the shelf switch](https://botblox.io/products/micro-gigabit-ethernet-switch) was enough for all our communication needs.

Of course, Taylor's attempts at a physical implementation weren't without hitches, but no problem was encountered which wasn't fixed by throwing multiple transformers at the problem (joking, only one transformer needed to be thrown).

## Radio

Oh boy, where do I even begin? At the solution - the RFD900.

It's a 1W 900MHz (the unlicensed ISM band) radio, with an LOS range that can
reach 60 km in some scenarios. We only needed 25.

Arriving at this wasn't easy, and I wasn't set on the decision until an industry
expert vouched for its effectiveness.

I spent an unreasonable amount of time looking at sample implementations for
chips like the TI CC1101, and shopping for >1W amplifiers that we could
(presumably?) use with a HAM license.

The antenna design was also a whole can of worms. At some point, we were designing
for the mid-airframe panels to be carbon fiber, a conductive material that
severely impedes radio. We explored the use of getting PTFE copper-clad, etching
a patch antenna on it, and heat-forming around the circumference of the vehicle.
This wasn't our idea, we got it from [this
paper](https://apps.dtic.mil/sti/pdfs/AD1105046.pdf), which contains this very
promising sentence: "Destroy by any means possible to prevent disclosure of
contents or reconstruction of the document. Do not return to the originator.", followed by "UNCLASSIFIED".

In the end, we decided it would be too impractical to do anything other than just change the mid-airframe panels to be E-glass, a class of fiberglass transparent to radio, and use an off-the-shelf monopole antenna.

We also added LTE to the rocket, because we found that our launch side had reception when we were launching BZB.

## System Design

Combining all of this, we arrive at

![CMS System Diagram](/assets/cms-system.png)
**From our preliminary design review slides, some details are outdated**

The full PDR can be seen here

<div style="position: relative; padding-bottom: 56.25%; height: 0">
<iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src="https://www.youtube.com/embed/nS-GY2aki7s?si=21iAFowE6RR6o30J" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
</div>


Designing the Avionics for a 65k ft LOX-Ethanol rocket

Liquid Rocket Avionics


At Purdue Space Program, we're developing a liquid bipropellant rocket, and I'm one of the Avionics leads. The avionics system's job includes actuating solenoid valves to pressurize the propellant tanks, read sensor data, fire pyros for valves and engine ignition, etc.

In order to orchestrate all this, and to view sensor data while on the ground, we needed a dashboard software. The first place we looked was Grafana. Almost everything about Grafana was perfect, except its plotting performance. We had multiple sensors logging at thosuands of samples a second, all of which needed to be visualized. We also tried OpenMCT, which turned out to be less than satisfactory with an undocumented interface.

The conclusion I reached was that we needed a custom dashboard, so lo and behold, PSPieChart was born. The first iteration of this software turned into a proof-of-concept of a better plotter, and that turned out to be the only thing it was successful at. Everything other than that was a mess. Learning my lesson, I rewrote the whole thing. The screenshot above is the current state of PSPieChart.

It features high-data rate plotting with real-time downsampling (nothing too fancy, just average every n samples, where n is the right amount to occupy a horizontal pixel). The system to manage all your sources and charts and stuff is also super neat. It's similar to inodes, where each source is like a file. Things like charts and dashboards are treated as directories. And to wrap it all up, there's a very readable factory pattern to decide how to render the currently selected item, both in the tree and the main view. If you want a data source to, say, be in a chart, you'd just create a "hard link" by dragging the source into the chart. Very intuitive!

It's written in React, and packaged with Vite. The line count comes in under 2000 SLOC, and the final bundle clocks in just under 250 kB, gzipped. PSPieChart is a lean, mean, charting machine. Responsiveness and precision are prioritized over everything else.

![Pyro testing with PSPieChart](/assets/pyrotest.jpg)

Here's PSPieChart in action! We conducted a successful test of the pyrotechnic channels, using PSPC as our dashboard.


High-performance dashboard for rocket operations

PSPieChart


**Note: I created this bot almost 2 years before ChatGPT was released, any foreshadowing is accidental**

After gaining a bit of experience in working with natural language models and the transformers Python library, I wanted to make a Discord chatbot for a server that my friends and I were in.

The picture above shows the chatbot in action. As you can see, it is called AMOGUS for comedic effect, referencing the popular pandemic game Among Us. You can also see that the bot does not know how to perform multi-agent reinforcement learning, which is expected behavior.

The first hurdle in making a Discord bot was communicating with Discord servers. Thankfully, there was already a Python library that abstracted all of that away into a simple Flask-like interface.

I then made an abstraction to keep track of all the conversations that the bot should be handling. I did this so that I could isolate conversations between different users, as the chatbot model I was looking to use did not seem to support having multiple people talk in a conversation.

For the NLP model itself, I decided to go with Facebook's pretrained Blenderbot model. Before choosing this model, I experimented with other models such as DialoGPT, but many of them had problems with the model getting repetitive, and I was not able to fix that problem with different sampling parameters (temperature, top-p, top-k, etc).

I also added an abstraction for the model itself, so that I always have the option of switching between different natural language models. I am currently working on getting the GPT-J model working with the Discord bot, and while the model is a tad bit overkill, it seems to be good at keeping track of multi-user conversations, which is a feature I had always wanted to add to the bot.

I am also currently working on optimizing the server code so that it can run fast on a server with multiple GPUs and automatically schedule text generation tasks.

**2023 update**

Haven't modified this text in a while, but this bot now runs on Facebook's LLaMA foundation model, eating an entire V100 on an NVIDIA DGX-1 that Purdue lets me use for free. It gets a surprising amount of activity on Purdue's CS Discord server for how useless it is.

The code for this project can be found on [GitHub](https://github.com/sagarreddypatil/nlp-discord-chatbot)


A delightful and uninformative addition to your Discord server

LLM Chatbot


The marching cubes algorithm is used to generate a 3D surface out of a scalar field. As a side project, I wanted to implement the Marching Cubes algorithm efficiently in the Unity3D game engine to generate interactive, procedural terrain.

The first method I tried was to write the algorithm in a compute shader. However, this proved to be too slow due to the time it took to move the vertices from the GPU back to the CPU.

After that, I tried to implement the algorithm in Unity's Job system, which allowed for automatically parallelized tasks. This offered a significant speed benefit.

In order to make the terrain editable, I also added a chunking system, so that the terrain could be split into chunks and only one chunk had to be regenerated when the underlying voxel data changed.

The code for this project can be found on [GitHub](https://github.com/sagarreddypatil/Marching-Cubes-Unity)


Generating isosurface meshes for dynamic terrain

Marching Cubes


Summer after high school, I was bored and jobless, so I decided to build and test custom solid rocket motors (yes, sugar rockets, no do not try this at home), so I built a test stand to measure the thrust of motors.

To achieve this, I used a load cell along with an ESP 8266 microcontroller, to read the load cell and transmit the data.

All the code that runs on the ESP was written in C++ using the Arduino ecosystem.

The program on the ESP was responsible for reading the data from the load cell, storing the data in SPIFFS, sending data over TCP to connected clients, and broadcasting mDNS.

An Electron app was created to receive and visualize the data. The Electron app used mDNS to find the IP address of the ESP, and then received data on a TCP socket. It uses uPlot to graph the data in real time, and also records the data.

Finally, it includes an interface to perform various functions on the ESP, such as starting/stopping data collection, downloading onboard data, and calibrating the load cell.

All the code for this project can be found on [GitHub](https://github.com/sagarreddypatil/rocket-test-stand).


Cheap and easy way to characterize your rocket motors!

Model rocket test stand


This was a Hackathon project for BoilerMake X.

The premise is simple, just drawing anywhere with your hands and a laptop with a camera.

Aref and I was responsible for the drawing part of the whole thing, basing
off of the work of a [previous Python prototype by Aref](https://github.com/arefmalek/airdraw).

This version had to be in the browser, and we decided to make a game out of it, similar to [Gartic Phone](https://garticphone.com/).

We used an open source model by Google to track the player's hand, which ran
entirely in-browser. All we had to do after that is match hand positions to
different tools. For example, if only the index finger and thumb were up, you had the drawing tool, and you could control the size of your brush based on the dot product of the pointing vectors of each finger.

Then to draw, we simply stored a list of strokes, where each stroke was a list of positions. Showing the drawing was as simple as drawing lines according to the strokes.

The code for this project can be found on [GitHub](https://github.com/arefmalek/DrawticPhone)


Draw anywhere you want, zero consequences

Drawtic Phone


For the HackJPS hackathon, my friends and I decided to create a chrome extension that could summarize articles. However, we didn't want this extension to be like the usual summarizer which just extracts sentences that are already in the article.

In order to achieve this, we decided to use a natural language transformer model to perform the summarization.

First, we needed to extract text from any article, so we used a library called mercury-parser. On the backend side, we used Python with Flask. For the summarization model itself, we used a version of BART finetuned on the CNN/DailyMail dataset.

We also attempted to quantize the model using ONNX in order to run it on users' machines, but that wasn't possible within the scope of the Hackathon. Regardless, we were able to win the hackathon. We completed the entire project, start to finish, in the span of just a few hours, which was incredibly convenient because we entered the competition 12 hours late.

More information about the project can be found on [DevPost](https://devpost.com/software/summarizer-extension) and the code can be found on [GitHub](https://github.com/sagarreddypatil/quick-summary).


The quickest way to decide if that article is worth reading

Article Summarizer


_The Programmers’ Credo: we do these things not because they are easy, but
because we thought they were going to be easy_

I didn't want to pay for Coursicle so I decided to webscrape the Purdue course
catalog at regular intervals to find out if seats opened in any classes. It
worked satisfactorily.

I was able to complete this in a week, which is only 7 times more than the
intended amount, which might be a personal record.

I scraped the course/section lists for entire departments using Selenium/BeautifulSoup in Python and then cached them. This is because the request took a good couple seconds.

The next step was monitoring a list of courses, which I did by using the builtin requests library, and a User-Agent string from my web browser. These pages were available on the public web, so no funny business was required here.

Except requests were IP ratelimited, because of course they were, so I had to space out the requests, even across multiple sections. That is, even if I only checked diffs every hour or so, requesting information on multiple sections at once triggered the ratelimit, and I had to wait for a certain time for it to resume responding to requests.

It did work at the end though, which was awesome. I also used Pushover to send notifications when a course opened up to my phone, which was very convenient. A few of my friends got some use out of this too, so I consider it a success.

Code on [GitHub](https://github.com/sagarreddypatil/purdue-course-monitor)


Because Coursicle costs money and I decided this was easier

Purdue Course Monitor


HawkVision is a computer vision project I developed during my time at the FIRST Robotics Team 2554.

The goal of the project was to track a target marked with retroreflective tape. The camera that we used on the robot had a green ring light on it, so that the vision target appears bright green on the camera view.

To track the targets, we used a program called GRIP to build an OpenCV pipeline with color thresholds that narrowed out the vision target. We also calibrated the camera and found its focal length to determine the angle to the target.

With this information, we were able to run a PID loop on the robot so that it could automatically align with the target on command.

The code for this project can be found on [GitLab](https://gitlab.com/team-2554/hawkvision-2.0).


One-stop-shop for all your machine vision needs

Sagar Patil

Fall 2021

Spring 2021

Fall 2022

Spring 2022

Fall 2023

Spring 2024