GridSense

• 

  Logo

Inspiration

A lot of high-performance hardware is surprisingly cheap. For example, the BNO086, a high-performance Accelerometer, Gyroscope and Magnetometer with an integrated CPU for automatic calculations, comes in at only about $13. With a breakout board from SparkFun, the total only comes out to about $30. Despite that, the BNO086 is still very impressive. With the built-in CPU, it isn't necessary to apply filters or manually fuse sensor reading. Its all handled over a simple SPI or I2C protocol. With that in mind, I knew I wanted to do something with cheap hardware that could easily be adopted without a large investment.

What it does

GridSense is a full-stack solution to reporting, monitoring, and responding to potholes. On the physical side, a small device is mounted to a vehicle. The device consists of an ESP32 ($10), a BNO086, and ideally, a GPS (The ublox DAN-F10n is only $10). I don't have one, so the device simulates coordinates for now.

The device will use the BNO086 to detect potholes. Then, the location and severity of the pothole is reported over WiFi to a central server (I'm assuming that WiFi will eventually be a free public service. Otherwise, LoRa could be used instead, with a LoRa module only costing about $10).

The central server handles clustering reports into a list of potholes. Then, it calculates a score for each pothole, which is a weighted function of the number of reports, the chronological separation of reports, the number of unique reporters, the average reported severity, and the variance in reported severity.

The frontend allows anyone to view where clusters (potholes) are being reported.

The frontend administration page is accessible to city officials. The page allows for general configuration, marking false-positives, and marking potholes as fixed. When a pothole is market as a false-positive, the function weights are slightly adjusted. In the long-run, this should lead to a decrease in false-positives.

How we built it

The tech stack was pretty minimal: C++ for the ESP32 code, and Python+Flask for the backend and frontend. To keep things simple, Sqlite was used for the database.

To actually build the app, a lot of time was spent planning with Claude Code. After coming up with an exhaustive list of requirements and bouncing them back and forth with Claude Code, it implemented most of the code. After implementation was complete, a lot of testing and tweaking was done to get the final result. This workflow allowed me to spend most of my time thinking about how to tackle problems while Claude handled quick implementations for testing.

Challenges we ran into

This was my first time heavily using an AI agent to facilitate working on a project. In order to maintain as much understanding about the codebase as possible, I made sure my requirements gave specific implementation instructions. I also spent time reading the generated code to committing it. With all this, I didn't run into any scenarios where I was lost asking the AI to fix bugs I didn't understand. I also had some trouble wiring the BNO086 since the breakout board itself has some hardware on it. After looking at the schematic for the breakout board and comparing it to the datasheet for the IC, I realized I had to solder two spots on the board to tie communication selection pins high in order to use SPI.

Accomplishments that we're proud of

Pothole detection isn't exactly a cutting-edge challenge, but I'm proud of the implementation. It aims to avoid false positives from events such as jumping onto curbs, jumping off curbs, or knocking the vehicle over (for example, falling off a scooter shouldn't trigger pothole detection). Many parts of the detection algorithm are parameterized, so they could be fine-tuned for a specific vehicle (scooters, bikes, full-size cars, etc).

Additionally, GridSense is a full-stack solution, not just a hardware hack. Once GridSense devices are installed on vehicles, cities can immediately begin identifying potholes with the centralized frontend. Since the severity function adapts to indicated false positives, the algorithm will also improve over time.

What we learned

I learned quite a bit about communicating with embedded devices, making detection mechanisms with physical sensors, and cheaply clustering data. That being said, I think the most important skill I learned is how to better develop software with an LLM. I've been pretty reluctant to try using AI heavily since I feel a lot more in-control when I'm writing the code, but a healthy balance does exist between writing and generating code. This project let me spend time finding that balance, and I think I was able to.

What's next for GridSense

There are still a lot of features to add all-around. On the device side, implementing an actual GPS is crucial. Additionally, though some spam detection measures exist on the server side, more measures need to be put in place to prevent a bad actor from shaking the sensor over and over to report many false positives.

On the frontend side, authentication could be greatly improved. Instead of authenticating directly with a key, some sort of OAuth should probably be used instead.

Built With

• bno086
• c++
• esp32
• flask
• python
• sqlite