Mantis - Preventing School Shootings

Using AI and robotics to deliver an instant response to school shootings

Public Chat
Similar projects worth following
This last spring I was shocked with the news of the death of a high school friend and FIRST Robotics teammate during a mass school shooting.

Soon after that day I started working towards a goal of making these events impossible, not just improbable. This project, a proof-of-concept for a school security system, is a part of that effort. The system would be built into a school's infrastructure. It would deploy itself if audio sensors detect gunshots in the school or if a panic alarm is activated. A human operator with the assistance of computer vision would identify the threat. The threat would then be blinded by spray of fast drying molten wax.

The goal of this project is to demonstrate with open source technology that building such a system is achievable.

The Problem

We have all seen the headlines. 

Fundamentally, students are not safe. There is little in place, whether legislation or school security, to protect them from these types of events.  Teens know it.  Surveys show over half of them are worried about events like these happening at their school (source).

Losing a friend in a mass school shooting launched me into this project. I want students to know they are safe from these events while in school.

Project Goals

Mantis's design objective is to provide an instant response to stop a school shooting within seconds of its start.  This response needs to be powerful enough to deter would-be shooters from attempting an attack in the first place due to the presence of the system.  The goal of this project is to demonstrate that the technology for such a system certainly exists today and to develop it to a mature implementable form. 

Read the second half of Log #6 to get an idea of how Mantis would be built into a school.  

Mantis Prototype 1 Design

Goal of initial prototype was to demonstrate proof-of-concept capabilities of the system.

  • Vision recognition and tracking
  • Aiming at target
  • Effectiveness of molten wax spray

Wax Spray

Going into the project I knew the single most difficult problem I would face in the design was finding a method of actually stopping or impeding the assailant.  It should be obvious that lethal weaponry would be wildly inappropriate for an automated system like this in a school.  Other options such as tasers and kinetic energy (rubber bullets) “less-lethal” weapons are still off the table.

I realized method of stopping the assailant needed to conform to the following criteria:

  • Cannot cause serious injury
  • Precise, only affects the assailant, doesn’t impede people trying to escape
  • Has a range approaching 30ft
  • Is inexpensive
  • Stops or seriously impairs the assailants despite their knowledge that the system is in place

Pepper spray fails the 2nd and 5th requirement as it would affect nearly everyone in a room and pepper spray resistant masks exist. 

The concept behind a wax spray being used to blind an assailant is simple.  A wax would be stored as a liquid at a temperature above its melting point (waxes exist that have melting points of ~110F).  The wax would be fired at the assailant's face using pressurized air.  The liquid wax spray would solidify on the the assailant's face, making it difficult to remove.  The spray would remain effective regardless of whether the assailant wears googles or a helmet.  

Mechanical Design

The core of the mechanical design is a rotating gimbal carrying the spray gun.  The gimbal is powered by two brushless motors via Servocity gears.  The structure of the gimbal was cut from birch plywood with a cnc laser at a local makerspace and painted black.  Part of the original design (see Project Log #3) was a mechanism that loaded paintballs into the barrel of the launcher from the side via a cog rotating around the barrel.  This loads the paintballs regardless of the position of the gimbal.  Two aluminum tubes support the gimbal and electronics.  The CAD is available on Onshape via this link:


The electronics are powered by a 12V DC power supply.  I used an Odrive (a previous Hackaday Prize entry) to control the motors.  Brushless motors controlled by Odrive are mind-blowingly quick, precise, and powerful, perfect for this application.  An Arduino will control power to the the loading system and paintball launching...

Read more »

plain - 4.86 kB - 08/22/2019 at 03:50


View all 7 components

  • Working Prototype and Moving Towards an Implementable Design

    David Gedney08/25/2019 at 10:15 0 comments

    As I mentioned in log #3, I really wanted the prototype to be functional to the level at which it can demonstrate an actual ability of stopping someone.  This needed to happen quickly with my school semester starting and the Hackaday Prize wrapping up.  Unfortunately, the design of a wax spray system is complicated by the fact that the entire system must be kept at a temperature above the waxes melting point.  Since the prototype was not designed from the ground up for this (it was supposed to launch sticky paintballs), spraying molten wax in this time frame was impossible.

    Instead I went with what might be the next best thing, paint.

    A paint spray has similar properties to a wax spray, except that wax might dry faster.  Some people I have discussed the idea with are convinced paint would be more effective than wax anyways. 

    My initial design was an evolution of the standard pneumatic sprayer mechanism.  A vertical pipe is filled with the paint spray, air pressure is applied at the top of the pipe, and a solenoid valve releases the paint spray from the bottom. 

    I went to the hardware store to find parts and came up with this.

    Its a pipe acting as a pressurized liquid storage reservoir with a valve release on the bottom.  Critical to the design were two reducers from ¾” thread to a 1/4“ NPT thread.  Unfortunately, after building and pressurizing the system, it became obvious that the ¾” reducer thread did not interface with the ¾” NPT thread on the piping.  I looked up the part number to find that the reducer’s thread was for a garden hose.

     I found ¾” NPT to garden hose adaptors on Amazon, but then realized I had an even better option.  I could simplify the design by directly connecting a garden hose filled with the spray to the valve and spray nozzle on the gimbal.  This eliminated a problem I had with the old design where I felt the valve and spray storage was too far away from the spray nozzle on the gimbal. 

    After some testing, I found that, again, the 0.23CV valve was not up to task.  The spray released by the system, even when the air pressure was over 100PSI, was far too weak to be useful. 

    I finally decided to purchase a new valve.  With a CV of 7.6, it is more up to task. 

    Soon I had the entire system setup.  This early prototype will have to be scaled down by an order of magnitude or two for a final implementation. 

    I rethought the valve placement (again), placing the valve below the turret with a tube going up to the turret.  The new valve is too big to fit in the turret.

    I ran a few initial tests (on myself) with water then with paint.  I was happy to find that with automated aiming and tracking the turret had almost perfect accuracy.  Cool. 

    Something that I found during these tests (and you can see in the video, watch the laptop screen) is that the automated targeting would get messed up while spraying because the line of spray was blocking the camera’s view of the target.  While the initial spray hit my face directly, the automated tracking would break a fraction of a second and afterwards the spray would mostly miss.  A way to fix this would be to use short bursts rather than a continuous stream.  As you can tell in the video, these short bursts, especially with molten wax, would still be highly effective.  

    Moving Towards Implementation

    Having a working proof of concept prototype is fantastic.  It’s a nice reward after two months of work and a great demo for “selling” the idea.  It still doesn’t tell much about just what the system would look like in a school.  In parallel with getting the POC prototype working I have been working furiously on developing an implementable approach.

    In Log #1, I discussed two possible implementation...

    Read more »

  • Developing the Code

    David Gedney08/22/2019 at 04:23 0 comments

    Going waaaay back to the very beginnings of this project, when I only had a vague concept of an automated system that could stop a school shooting within seconds, I knew that computer vision would be crucial for the system to work. 

    My programming experience can only be described as basic (e.g. most of what I know has come from college classes which have titles starting with “Intro to”) and I certainly had no experience with computer vision.  Honestly the fact that I got anywhere with CV in this project is a testament to the power and general total awesomeness of the open source community. 

    As a junior electrical engineering student, and someone who follows tech news, I already had a basic understanding of the capabilities of today’s computer vision software (Tesla autopilot exists after all).  In my initial correspondences with subject matter experts (law enforcement, school administration, i.e. people not as in tune with the capabilities of modern CV) I wanted to show them something that demonstrated where computer vision tech is today … something that might convince them the idea is not that crazy.  Google brought me to a TED talk given by a University of Washington grad student on his YOLO computer algorithm:

    The impressive demo shown in the video (after 3:10) served my purposes.

    I met with Dr. Chao Liu, an electrical engineering professor specializing in computer vision at CU Denver (my school!).  I explained to him exactly what I was trying to do (design a system that assists a human controller with identifying and tracking shooter).  He confirmed that the computer vision part of the project was not impossible with today's software (for me, this was a necessary sanity check) and explained an initial breakdown of how an “identify-track” algorithm might work. 

    Dr. Liu pointed me towards OpenCV as a starting point.  Harrison Kinsley’s incredible introductory series on OpenCV quickly got me up an running.  I would 100% recommend it to anyone who wants to get started with unlocking the power of computer vision for their projects, regardless of their python experience. 

    I met with Douglas County law enforcement personnel (an officer who has done SWAT … and has responded to some of Colorado’s mass shootings and a local high school SRO) and had a good discussion about current measures in place to protect students.  Programs like Safe2Tell are effective and have saved lives.  Many schools’ security cameras are constantly monitored by a person. Understandably, they were skeptical about my idea … but I’ve kept in touch and can’t wait to show them the Mantis prototype working. 

    I huge takeaway for my project was that it is practical for a person to provide direct assistance and control to Mantis (e.g. I no longer had to worry about the practical and ethical difficulties with an autonomous system identifying someone as “the shooter”).  The person already monitoring the school security cameras could take control of Mantis during a shooting.

    I returned to the YOLO algorithm to continue developing the prototype.  It’s open source and I knew it could do what was needed for a proof of concept prototype (identify individual people in a live feed).  I’m a big fan of python, so I ended up using darkflow for implementation.  

    Knowing nothing about what I was doing, I ran into a ton of bugs and obstacles during that process.  After hours of troubleshooting I finally got YOLO working.  And the results were worth it. 

    I had bought an ODrive by that point  It is such a cool piece of hardware.  The speed and precision it allows for brushless motors is mind-blowing.  It was also super easy to setup and get working.  Its power and precision...

    Read more »

  • Prototype Tracking Demo

    David Gedney08/13/2019 at 16:42 0 comments

    Next step is to put a sprayer in place of that barrel.  

    Sorry about the shaky voice and camera; it was after a long day of design work.

  • Saying Goodbye to Sticky, Icky Paintballs

    David Gedney08/11/2019 at 05:08 0 comments

    Reading through the project details, you’ll probably have the impression that the concept of “sticky paintballs” are crucial for this project.  Demonstrating their theoretical ability of precisely covering someone’s vision in a way that's difficult to wipe off would be huge.

    Making the Paintballs

    To start, I knew I needed to make some physical sticky paintballs to experiment with.  Trouble is manufacturing paintballs is a pretty complicated process.

     My go to DIY resource, Google, was useless as for finding a way to make them.  I’m still open to any ideas!

    I decided the only realistic way to do it was to modify normal paintballs and change their filling to be something that’s a little stickier.  I picked up a package of 1000 at Dick’s (which is apparently not a lot as far as paintballs go). 

    Today I made my first attempts at modifying the paintballs.

    My first method was to split one in half, drain out the “paint,” fill both halves with honey, and finally weld the two halves together … with a soldering iron.  Yeah, terrible idea, but it was worth a shot. 

    Honestly, I thought it would turn out way worse.  The outer shell burned instead of welding, leaving a useless "paintball" only held together by the honey inside.

    For my second attempt I poked two holes through either side of the paintball with a needle and then used a syringe to empty the paintball …

    and then fill it with honey.

    The first few attempts ended up as messes but soon I had it down.  It wasn’t long before I had a handful of sticky paintballs.  Minus the pinholes they looked unaltered. 

    My first experiment was to throw a couple of the sticky paintballs at the ground as hard as I could.  I quickly realized something was wrong, the sticky paintballs only cracked (next picture); they did not smash into goo like normal paintballs would after that type of impact (2nd picture).

    Sticky Paintball

    Unaltered paintball

    I initially attributed this to there still being air pockets in the paintballs.  I changed the method of replacing the paint fill with honey by directly injecting the honey while pushing out the fill.  It didn’t help.  I discovered that the real cause of the paintballs not smashing is that the honey is holding them together.  This same stickiness that’s key for blocking an aisalants vision would keep them from exploding and spreading on an assailant’s face.  Not good.

    The number one safety rule for playing paintball is using eye protection.  Standard paintball guns are calibrated to fire just under 300 ft/s.  They are powerful enough to know out an eye.  For the final implementation of sticky paintballs, I was planning on using a larger diameter (of over an inch) to help distribute the impact force and reduce the risk of eye damage.  However, as explained above manufacturing custom paintballs is off the table for now. 

    Now however, I realize that the sticky paintballs will have to be fired with even more force to ensure they burst.  This was something I completely overlooked and it changes things quite a bit.

    Launching Paintballs

    Prototype 1 was designed to launch paintballs

    I duct taped to the back of the barrel a tube that lead to a 12V solenoid valve attached to a 90 psi airtank.  Switching on the valve released pressurized air to launch the paintball.   Unfortunately, with the 8-inch barrel, the paintball just rolled out the front of the barrel.  By extending the barrel length, the system managed to fire shots that were powerful enough that the (unaltered) paintballs burst when they hit a hard surface.  Since a 3-foot barrel isn’t realistic for the prototype, I’ll have to find a more powerful valve than the one I have currently.  It’s only 0.23 CV,...

    Read more »

  • Calibrating the Launcher Aim

    David Gedney08/09/2019 at 22:38 0 comments

    Yesterday, I had the first chance in two weeks to work with the physical prototype.  Since at this point in the project it is important to get feedback from professionals in the field of school safety (school administrators, police officers) I want to be able to show them the prototype as a proof of concept.  For the initial proof of concept what’s most important is the computer vision human recognition code (which I have) and the prototype aiming the launcher.  The aim of the launcher needs to be in reaction to what the computer vision system is seeing and a human user input. 

    Something I feel is completely necessary is that the aim is accurate, the launcher needs to be pointed directly at the target’s face.  Demonstrating that precision would probably be crucial to getting anyone to think that robot launched "sticky paintballs" is a remotely feasible method of stopping a school shooter.  

    To do this, I knew I would have to correlate the position of the motor encoders to the camera feed.  I set up the prototype, oriented the launcher to be pointed at some arbitrary target in the room, and then selected the same target on the camera feed.  A python script I wrote recorded the position of the encoders and the position I of the cursor on the feed.  I repeated the process to get a distribution of points.

    Selecting a target in the feed

    while manually orienting the launcher at point at the target (using“bore sighting” ).

    I originally intended the to have a more systematic and complete distribution of points as I was expecting a complicated relationship between the pan and tilt encoders vs. the x,y position on the screen (as well as that the pan and tilt would both be x, y dependent; 3D scatter plots ftw!)

    But I had the very pleasant surprise of finding the relationships between the x, y positions on the camera feed position and the pan, tilt encoders were almost perfectly linear!  It must be an artifact of the 170-degree fish-eye lens, but this will make my life a whole lot easier!

    While I anticipated this to be one of the larger hurdles for getting this prototype working, I am happy it was an easy process (unlike getting the YOLO algorithm to work :O ). From here, correlating the position of what Mantis is "seeing" to where it aims should be straightforward.  

  • Two Implementation Approaches

    David Gedney08/07/2019 at 20:13 0 comments

    Something I did fail to address in the description and details portion of this project is what it would “look like” in its final form when built into a school. This was partially intentional. I have yet to completely define how I want to approach it. But I do have a couple of ideas 

    Idea #1 Launchers mounted on stationary turrets.

    A system analogous to this approach is the automatic fire sprinkler ubiquitous in any modern building. Distributed on the ceiling in every room, they are activated by the presence of fire. The sprinkler heads release pressurized water onto the fire, hopefully preventing injuries or fire damage. 

    The basic concept for this implementation is the same. Turret mounted sticky paintball launchers would be situated in the ceiling or on the walls of every room and the hallways of a school. In the event of the sensors built into the system detect a gunshot, the launchers would deploy from tamper-proof enclosures and engage with the assailant.

    Render of the current prototype, a stationary turret, in a classroom in a "deployed position."  Deployment would only occur in the event of a shooting; students would hopefully never see the launchers.  I apologize for being really terrible at photo editing!  

    Idea #2 Launchers mounted on mobile robots

    Putting automated paintball launchers into every room would require a lot of automated launchers. Since each of these robotic devices is a significantly expensive unit of hardware, the cost of the entire system would be driven up very quickly as it is implemented everywhere in the school. 

    The main advantage of mobile over stationary launchers is that it requires fewer units per school. Instead of needing say 200 units per school (avg. square footage of a U.S. high school is 173,727 sq. ft, meaning each unit needs to cover ~900 sq ft, a 30x30ft area) along with each of those units wiring and data management, you would only have about 10 mobile units distributed throughout the school. The mobile robots would be largish (fit within a 3x3x3ft cube) and would drive teleoperated along the floor from its base to the room or hallway where the assailant is present. The 10 units within the school would hopefully be able to provide a much faster response than a school resource office (SRO) to any place within the school and would be more immune to gunfire than an SRO. 

    I believe that building teleoperated mobile robots that directly engaging with a shooter in a chaotic scenario are, unfortunately,  unrealistic with today’s technology. The robots would also be susceptible from being barricaded by the shooter to keep them from where they need to be.   Although perhaps faster than an SRO, the robots are slower than turret launchers already placed in a room.  The shockingly short timeline of the Dayton shooting this past weekend showed just how important each and second is in these scenarios.  

    Perhaps there is a third method. I am trying to arrange a meeting with an architect with school design experience so I can start crunching some real numbers and get a better idea of how a school’s infrastructure really works.

View all 6 project logs

Enjoy this project?



John Opsahl wrote 03/07/2020 at 19:33 point

Have you considered using CO2 cartridges for low volume compressed air storage. Is the intention to have the camera move with the turrent?

  Are you sure? yes | no

David Gedney wrote 06/15/2020 at 04:33 point

CO2 or compressed air is definitely the way to go.  The only possible concern is the rapid loss of temperature caused by the depressurization, which might freeze what it is spraying.  There would definitely be ways to work around that. 

  Are you sure? yes | no

John Opsahl wrote 08/11/2019 at 02:27 point

Sorry to hear about your friend. I admire you decision to do something to stop school shootings. Good work on putting the paint ball loader at the center line of the barrel rotational axis. That doesn't look like it was easy. I have had good experience with cheap slip rings for cable management on multi axis heads like this. I am curious on the mechanical connection at the top rotational axis. Thanks for sharing.

  Are you sure? yes | no

David Gedney wrote 08/20/2019 at 15:59 point

This section view screenshot might help you understand the top axis.

The top axis turret is floating, sandwiched in a system of 12 ball bearings (the support parts for the bearings are not visible in the screenshot).  The motor rotates the top axis via a shaft mounted gear.  

The Onshape CAD document is publicly available here:

Let me know if you have any other questions!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates