Project:Spacensus: Difference between revisions

From London Hackspace Wiki
(pretty sure this isn't current infra)
 
(45 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Project|members=[[User:Teabot|Elliot]]}}
{{Project|members=[[User:Teabot|Elliot]]}}
[[File:Spacensus-enclosure.jpg|250px|thumb|Enclosure]]
[[File:Spacensus-in-situe.jpg|250px|thumb|In situe]]
[[File:Spacensus bare.jpg|250px|thumb|Prototype]]
[[File:Spacensus bare.jpg|250px|thumb|Prototype]]
Part of the [[Project:LHS Graphs and Visualizations|London Hackspace graphs and visualisations]] project.
Part of the [[Project:LHS Graphs and Visualizations|London Hackspace graphs and visualisations]] project.


==Overview==
==Overview==
I have located two Laser Diode Retroreflective Sensors in our stores which I intend to use to monitor space occupancy by having the beams cross the main doorway. The beams will be staggered so that direction (arriving, leaving) can be determined by the order in which the beams are broken. I was thinking of mounting them at waist height.
We were donated two Laser Diode Retroreflective Sensors which I now use to monitor space occupancy. The sensors look across the main doorway. The beams are staggered so that direction (arriving, leaving) can be determined by the order in which the beams are broken. They are mounted at waist height.
 
The sensors are hooked-up to an Arduino via some optocouplers. The Arduino is connected to a PC so that the count can be queried over a network.
 
The occupancy level is [http://hack.rs/cacti/graph.php?action=view&local_graph_id=35&rra_id=all charted on cacti].
 
==Status==
====Debugging====
* I added a fair bit of code to log the various states of the system to try and determine why it over counts.
* Writing to the serial port takes time I had to place the logging code carefully so as not to interfere with the critical timing of beam break detection.
* I now have a log file to analyse which includes a good amount of traffic from a Tuesday evening.
* Summary stats from the log file:
  Beam breaks:
    Outer:    655
    Inner:    694
 
  Actions initiated:
    Entrances: 401
    Exits:    337
 
  Actions completed:
    Entrances: 173
    Exits:    129
   
  Actions never completed - timed out - noise:
    Entrances: 84
    Exits:    83
 
  Actions not counted because they were fast/slow:
    Entrances: 144
    Exits:    125
 
  Beam re-breaks:
    Same beam broken: 131
    On entrance:      48
    On exit:          83
 
* Observations
** There are significantly more entrances than exits as expected from reports that it over-counts.
** The number of abandoned slow/fast actions is very high.
* Conclusions
** The system is unbalanced. Something in the setup is causing one or more of the following to occur:
*** Exit events missed
*** Exit events interpreted as Entrance events
** Many actions are not counted because they either take too long or are too short..
*Next steps:
** Look for patterns in the log that might describe the miscount of exits - remember fewer exits are initiated!
** Time beam break speed when opening door.
** Observe actions as they occur and correlate with logs (time consuming).
** Move the sensors to a more neutral position - perhaps the proximity to the doorway has introduced a bias.
 
====Recent modifications====
* Milled [http://www.flickr.com/photos/travelbot/5571860429/in/pool-londonhackspace new bracket] for sensors.
* Graphical display with graph showing the days occupancy
* Detection code now completely interrupt driven
* Beams are now polarized
* Beams are now very close together
* Prism reflector
 
==How it works==
====Sensors====
These sensors emit a low power visible laser. They detect the beam reflection - if the reflection is obscured then we can surmise that a person is in the way.  The sensors were manufactured in 1996 and use a [http://en.wikipedia.org/wiki/Laser_safety#Class_II Class II] laser rated at 3mW (peak), 2kHz 2% duty cycle, with a wavelength of 655-670nm ([[Media:Banner-q45bb6ll.pdf|datasheet]]). The model number is: Q45BB6LL
 
A good signal can be obtained at 1.5m by using a reflector made of aluminium tape but alignment is critical. [http://en.wikipedia.org/wiki/Bicycle_reflector Prism reflectors] are far more forgiving.
 
====State machine====
The detection aspects of spacensus use an interrupt driven state machine. Anything that isn't time critical stuff happens in a run-loop.


* This will probably get caught out by clusters of people: --[[81.105.17.61]]
[[File:Spacensus state machine diagram.png|border|640px]]
** We only need an approximate count
====Code====
** The doorway is narrow so it's unlikely that the steps of more than one individual will overlap.
The code is available on [https://github.com/londonhackspace/spacensus GitHub] - please be kind it's my first Arduino project and I know the code is filth.
** Most of the time people won't arrive in clusters
* Can we detect some other event such as the door opening after a prolonged lights-out period to force the count to zero? --[[81.105.17.61]]
** Yes, using the door/lights data for reset would be good if  we get large amounts of drift - but I don't plan to just yet
** This might fail if people spend the night there.  AIUI this happens rarely enough that we may not care about the inaccuracy.
** We could also use some kind of probabilistic model with the 'door-open' and 'bell' data


==Location==
==Instructions==
====Changing the count manually====
* Press the black increment (+) or decrement (-) buttons on the main unit.
====Disabling/Enabling the laser beams====
Sometimes you might want to turn off the lasers - perhaps if there are children in the space. Note that no people detection can take place with the lasers off, so please remember to turn them back on.
* If you need to turn off the laser sensors then press and hold both buttons for ~5 seconds
* Repeat above step to enable them.
====Silencing the alarm====
If the sensors are blocked for more than 15 seconds then an alarm will sound. If you can't remove the blockage you can turn off the sound to prevent irritation.
* Disable the beams as described in the section above.
====Powering off====
# Remove the USB cable from the side of the unit.
# Remove the 12VDC jack from the side of the unit.
# Check the beams are no longer emitted and that no sensor indicators are illuminated.
====Location====
The [http://www.flickr.com/photos/travelbot/5421523049/ current mounting location] has the lasers In close proximity in the middle of the entrance way. To avoid issues with occlusion of beams by coats etc, the coat hooks have been moved to the next wall along, with the lab coats. This arrangement greatly simplifies the detection of the true direction of someone entering/leaving the space. Detection works reasonably well.
The [http://www.flickr.com/photos/travelbot/5421523049/ current mounting location] has the lasers In close proximity in the middle of the entrance way. To avoid issues with occlusion of beams by coats etc, the coat hooks have been moved to the next wall along, with the lab coats. This arrangement greatly simplifies the detection of the true direction of someone entering/leaving the space. Detection works reasonably well.
====Safety signs====
{|
|[[File:Laser-safety-emission-sign.svg|300px|thumb|Positioned above sensors.]]
|[[File:Laser-safety-door-sign.svg|225px|thumb|External door warning.]]
|}
==FAQ==
'''Q:''' This will probably get caught out by clusters of people: --[[81.105.17.61]]
'''A:'''
* We only need an approximate count
* The doorway is narrow so it's unlikely that the steps of more than one individual will overlap.
* Most of the time people won't arrive in clusters
'''Q:''' Can we detect some other event such as the door opening after a prolonged lights-out period to force the count to zero? --[[81.105.17.61]]
'''A:'''
* Yes, using the door/lights data for reset would be good if  we get large amounts of drift - but I don't plan to just yet
* This might fail if people spend the night there.  AIUI this happens rarely enough that we may not care about the inaccuracy.
* We could also use some kind of probabilistic model with the 'door-open' and 'bell' data


The occupancy level is currently [http://hack.rs/cacti/graph.php?action=view&local_graph_id=35&rra_id=all charted on cacti]. The [https://github.com/londonhackspace/spacensus python script] that provides the data to cacti implements only the 'pool for status' command, but will later allow more control and configuration of the counting sensors.
'''Q:''' Why didn't you use an ethernet shield?


==Sensors==
'''A:''' There was already a networked PC in the vicinity.
These sensors appear to be in working order. They'd should be safe to use below child-head height. They were manufactured in 1996 and use a [http://en.wikipedia.org/wiki/Laser_safety#Class_II Class II] laser rated at 3mW with a wavelength of 655-670nm ([[Media:Banner-q45bb6ll.pdf|datasheet]]). The model number is: Q45BB6LL


A good signal can be obtained at 1.5m by using a reflector made of aluminium tape.
[[Category:Projects]]
==Code==
[[Category:Space_Infrastructure_Projects]]
The code is available on [https://github.com/londonhackspace/spacensus GitHub] - please be kind it's my first Arduino project and I know the code is filth.

Latest revision as of 19:31, 21 October 2021

Spacensus


Members Elliot
QR code
In situe
Prototype

Part of the London Hackspace graphs and visualisations project.


Overview

We were donated two Laser Diode Retroreflective Sensors which I now use to monitor space occupancy. The sensors look across the main doorway. The beams are staggered so that direction (arriving, leaving) can be determined by the order in which the beams are broken. They are mounted at waist height.

The sensors are hooked-up to an Arduino via some optocouplers. The Arduino is connected to a PC so that the count can be queried over a network.

The occupancy level is charted on cacti.

Status

Debugging

  • I added a fair bit of code to log the various states of the system to try and determine why it over counts.
  • Writing to the serial port takes time I had to place the logging code carefully so as not to interfere with the critical timing of beam break detection.
  • I now have a log file to analyse which includes a good amount of traffic from a Tuesday evening.
  • Summary stats from the log file:
 Beam breaks:
   Outer:     655
   Inner:     694
 
 Actions initiated:
   Entrances: 401
   Exits:     337
 
 Actions completed:
   Entrances: 173
   Exits:     129
   
 Actions never completed - timed out - noise:
   Entrances: 84
   Exits:     83
 
 Actions not counted because they were fast/slow:
   Entrances: 144
   Exits:     125
 
 Beam re-breaks:
   Same beam broken: 131
   On entrance:       48
   On exit:           83
  • Observations
    • There are significantly more entrances than exits as expected from reports that it over-counts.
    • The number of abandoned slow/fast actions is very high.
  • Conclusions
    • The system is unbalanced. Something in the setup is causing one or more of the following to occur:
      • Exit events missed
      • Exit events interpreted as Entrance events
    • Many actions are not counted because they either take too long or are too short..
  • Next steps:
    • Look for patterns in the log that might describe the miscount of exits - remember fewer exits are initiated!
    • Time beam break speed when opening door.
    • Observe actions as they occur and correlate with logs (time consuming).
    • Move the sensors to a more neutral position - perhaps the proximity to the doorway has introduced a bias.

Recent modifications

  • Milled new bracket for sensors.
  • Graphical display with graph showing the days occupancy
  • Detection code now completely interrupt driven
  • Beams are now polarized
  • Beams are now very close together
  • Prism reflector

How it works

Sensors

These sensors emit a low power visible laser. They detect the beam reflection - if the reflection is obscured then we can surmise that a person is in the way. The sensors were manufactured in 1996 and use a Class II laser rated at 3mW (peak), 2kHz 2% duty cycle, with a wavelength of 655-670nm (datasheet). The model number is: Q45BB6LL

A good signal can be obtained at 1.5m by using a reflector made of aluminium tape but alignment is critical. Prism reflectors are far more forgiving.

State machine

The detection aspects of spacensus use an interrupt driven state machine. Anything that isn't time critical stuff happens in a run-loop.

Spacensus state machine diagram.png

Code

The code is available on GitHub - please be kind it's my first Arduino project and I know the code is filth.

Instructions

Changing the count manually

  • Press the black increment (+) or decrement (-) buttons on the main unit.

Disabling/Enabling the laser beams

Sometimes you might want to turn off the lasers - perhaps if there are children in the space. Note that no people detection can take place with the lasers off, so please remember to turn them back on.

  • If you need to turn off the laser sensors then press and hold both buttons for ~5 seconds
  • Repeat above step to enable them.

Silencing the alarm

If the sensors are blocked for more than 15 seconds then an alarm will sound. If you can't remove the blockage you can turn off the sound to prevent irritation.

  • Disable the beams as described in the section above.

Powering off

  1. Remove the USB cable from the side of the unit.
  2. Remove the 12VDC jack from the side of the unit.
  3. Check the beams are no longer emitted and that no sensor indicators are illuminated.

Location

The current mounting location has the lasers In close proximity in the middle of the entrance way. To avoid issues with occlusion of beams by coats etc, the coat hooks have been moved to the next wall along, with the lab coats. This arrangement greatly simplifies the detection of the true direction of someone entering/leaving the space. Detection works reasonably well.

Safety signs

Positioned above sensors.
External door warning.

FAQ

Q: This will probably get caught out by clusters of people: --81.105.17.61

A:

  • We only need an approximate count
  • The doorway is narrow so it's unlikely that the steps of more than one individual will overlap.
  • Most of the time people won't arrive in clusters

Q: Can we detect some other event such as the door opening after a prolonged lights-out period to force the count to zero? --81.105.17.61

A:

  • Yes, using the door/lights data for reset would be good if we get large amounts of drift - but I don't plan to just yet
  • This might fail if people spend the night there. AIUI this happens rarely enough that we may not care about the inaccuracy.
  • We could also use some kind of probabilistic model with the 'door-open' and 'bell' data

Q: Why didn't you use an ethernet shield?

A: There was already a networked PC in the vicinity.