Project Logs

Collapse logs

• Working Prototype and Moving Towards an Implementable Design

  David Gedney • 08/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 Gedney • 08/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 https://odriverobotics.com/.  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 Gedney • 08/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 Gedney • 08/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 (2^nd 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 Gedney • 08/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 Gedney • 08/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