OPM Parking Meters¶

Check out our new poster and video (30MB)
Watch our video on youtube: http://www.youtube.com/watch?v=J3UzYLFrjIM.

• OPM Parking Meters
• Members
• Concept
• Motivation
• Competition
• Technical Specifications
• Requirements
• Architecture
• Use Cases
• System States
• Risks & Mitigation Strategies
• Error Handling
• Implementation
• Test Cases
• Evaluation
• Lessons
• Fun Stuff
• References

Members¶

Andrew IDs - @andrew.cmu.edu

Emily Hart	erhart
James Kong	jykong
Chris Mar	cmar
Kevin Woo	kwoo

Concept¶

• Low-power wirelessly networked parking meters
  • Vehicle detection
  • Find parking spot status using a web interface connected to Google Maps
  • Wireless updates from parking meters to the central server

Motivation¶

• Finding Parking Spaces Is Tedious
  • Drivers waste time and energy searching for open spots
  • Enforcement wastes time checking meters

Competition¶

• Smart Parking Lots
  • Rockridge Bay Area Rapid Transit - BART
    • Large LED Displays the number of spots available
    • Wireless sensors communicate to solar powered base station
  • Baltimore-Washington International Airport
    • LEDs along aisles
    • Ceiling mounted ultrasonic sensors
    • $450 / space
  • San Fransisco Experiment
    • Low-power mesh networked wireless sensors
    • Use EMF to detect cars

Technical Specifications¶

• Hardware
  • Parking Meters
    • Custom PCB
    • Atmel AVR ATMega168
    • 2 x 16 character LCD Screen
    • Digi XBee 802.15.4
    • Devantech SRF04 Ultrasound Rangefinder
  • Relay Nodes
    • Laptop Computers
    • XBee to USB Dongle
    • (Not yet implemented) Embedded Gumstix with XBee and Wi-Fi
  • Central Server
    • Laptop Computer
• Software
  • Parking Meters
    • AVR-GCC toolchain
  • Relay Nodes
    • GCC
  • Central Server
    • Apache
    • PHP
    • MySQL
• Protocols
  • 802.15.4
  • Ethernet, TCP/IP, Wi-Fi

Requirements¶

• Functional
  • Parking meter mounted sensor to detect the presence of a car
  • Parking meter nodes will track car presence and remaining time will be displayed on an LCD
  • Internet connected relay nodes will maintain an up to date aggregate record of parking meter status
  • Parking meter status will be accessible via a web interface

Architecture¶

• source:/pub/opm_architecture.pdf (Block Diagram)

Use Cases¶

• Diagrams
  • source:/pub/opm_use_cases.pdf (UML diagrams)
  • Whiteboard Version
• Cases
  • Car arrives and user pays, car leaves before time runs out
  • Car arrives and user pays, car doesn't leave before time runs out
  • Car arrives and user does not pay, car leaves before being towed
  • Car arrives and user does not pay, user pays before time runs out (this leads back to the first 2 cases)
  • Car doesn't arrive and user pays
  • Car doesn't arrive and user doesn't pay (this is not an interesting case)

System States¶

• source:/pub/opm_state_diagram.pdf (State Transition Diagram v1.0)
• source:/pub/opm_state_diagram_2.pdf (State Transition Diagram v2.0)
• Whiteboard Version

Risks & Mitigation Strategies¶

• Fundamental
  • Rangefinders do not work for car detection
    • Test a variety of rangefinders
    • Try other types of sensors (weight, etc)
    • Drop this feature
  • Cannot get mesh networking up and running
    • Research other network architectures (tree/star topology)
  • Relay nodes have technical issues
    • Use a laptop
• Ancillary
  • Nodes use too much power
    • Investigate low-power sensors
    • Use external power supply
    • Make all nodes routers
    • Use custom protocol with forced sleep
  • Cannot get payment protocol (card swipe, authentication) working
    • Use cash / a button
  • Rain/Snow/Precipitation causes interference problems
    • Construct durable housing for nodes
    • Find rangefinders that can handle this
  • Smartphone display infeasible
    • Use custom pages
    • Use normal browsers
    • Display available spots with a list (sorted by block?)

• Parking Meters
  • Atmel Raven
  • Custom board with Atmega168
• Relay Nodes
  • Robostix with Zigbee
  • Laptop with Zigbee Dongle

Error Handling¶

• Sensor Node goes down
• Relay Node goes down
• Server goes down

• Hardware Failures
  • Rangefinder
    • No response signal after trigger
      • ERROR: bad read
      • Try multiple times
      • Flag as broken after several tries, stop polling
    • Readings below distance threshold for too long
      • ERROR: Obstruction
      • Flag as obstructed, requires "maintenance"
      • Unflag if no longer below threshold
  • Money (Coins, Buttons)
    • Receive too many interrupts
      • ERROR: Jam
      • Flag as broken, requires "maintenance"
      • Disable interrupt
      • Periodically enable interrupt, unflag if OK
    • No Interrupts
      • Nothing we can do about this
  • Battery
    • Voltage drops below threshold
      • ERROR: Low power
      • Send signal to relay node / server
      • Flag for maintenance

Implementation¶

• HowToUse
• NevarPartList
• NevarHardwareInfo
• NevarBoardStatus
• LCDNotes
• PowerNotes

Test Cases¶

Evaluation¶

Lessons¶

Fun Stuff¶

References¶

• source:/pub/opm_initial_concept.ppt (Initial Proposal)