RoboShield

Inspiration

RoboShield was inspired by a simple but scary question: what happens when a cyberattack does not just steal data, but makes a physical robot do something unsafe?

That idea became real when reports came out about hacked Deebot robot vacuums in multiple U.S. cities. Attackers were able to take over the robots, use their speakers, and even control their movement around people and pets. It showed us that home robots are no longer just software devices. They have wheels, cameras, microphones, speakers, and the ability to interact with real people in real spaces.

Most cybersecurity tools protect laptops, accounts, and networks. But robots need something different. A robot command is not just text on a screen. A command like “move toward the person” or “play audio near someone” can become a physical action. RoboShield was built around that gap.

Our goal was to create a safety layer between commands and the robot hardware. Instead of blindly trusting every AI-generated or user-sent instruction, RoboShield checks whether a command is safe before it reaches the motors, sensors, or speaker.

What it does

RoboShield acts like a preventive antivirus for robots. It watches commands before they become physical actions.

In our demo, the rover starts by doing a normal patrol. Then we simulate an unprotected attack where a bad command makes the robot move aggressively and play loud audio. After that, we run the same scenario with RoboShield enabled. This time, the unsafe command is blocked before it reaches the robot’s hardware.

The dashboard also explains what happened in plain English, so the user can see what was attempted, why it was risky, and what RoboShield did to stop it.

How we built it

We built RoboShield as a web dashboard connected to an Arduino rover. The rover represents a small home robot with motors and a speaker. The dashboard represents the security layer that sits between a command source and the robot.

The rover firmware supports different robot modes like normal patrol, rogue behavior, stop, reset, and lockdown. For the stage demo, we also created a hardcoded version so the robot could reliably act out the full story even if sensors or serial communication failed.

On the software side, the dashboard shows the robot’s current state, simulated command pipeline, firewall status, and incident report. The main idea is that every command must pass through a safety check before it is allowed to control the robot.

Challenges we faced

The hardest part was making the demo reliable. Our ultrasonic sensor started returning only zero values, so we had to redesign the demo around deterministic robot behavior instead of live distance sensing. We also had to debug the motor pins, speaker pin, GitHub repo setup, and the difference between a real connected demo and a staged but dependable hardware demo.

Another challenge was balancing realism with clarity. We did not want the project to feel like just another AI chatbot wrapper. The important part of RoboShield is not that it uses AI. The important part is that it treats robot actions as something that needs permission, context, and safety checks.

What we learned

We learned that robotics cybersecurity is different from normal cybersecurity because the consequences are physical. A hacked robot does not just leak information. It can move, record, speak, scare someone, or damage something.

We also learned how important it is to design demos that are robust. A project can have a strong idea, but if the hardware fails on stage, the message gets lost. By creating a reliable hardcoded demo, we were still able to show the core concept clearly: without protection, unsafe commands reach the robot; with RoboShield, they get blocked.

Built With

• api
• arduino
• c/c++
• github
• hardware
• html/css
• javascript
• motor
• next.js
• react
• robot
• speaker
• typescript
• vercel