Home About Contribute CommunityBike.org Safety Program Development

Hampshire Computerized Check-Out Community Bike Program Development
Last Updated: 05/04/2002 - Jared Benedict

This document has been mostly superceded by the project summary page. The pages will likely be reorganized/merged at some point.

We are developing an advanced computer check-out Community Bike program. We intend to share our findings with others interested in implementing similar programs in their community. All our findings will be documented on this page, or on the Community Bike website.

Objective

  • Develop and implement a sustainable alternative method of transportation for communities.
  • Use Hampshire college as a pilot program and model for other communities.
  • Make the Hampshire community less reliant on cars for on campus transportation.
  • The Hampshire campus is fairly small, however buildings and other areas of interest are relatively spread out. Implement a quick, dependable mode of transportation to effectively diminish the feeling of a spread out campus.
  • Promote clean and healthy transportation.

Proposed Solution

Using standard technologies, develop a computerized check-out community bike program.

How the System Works

1. Each member of the Hampshire community is issued a Hampshire ID card. The card has a magnetic strip which contains a unique identification number.

2. A user goes to one of the scooter racks around campus, swipes their Hampshire ID card.

3. The user is authenticated, a scooter is unlocked from the rack, a screen displays that the user must return the scooter to any one of the racks around campus in a certain amount of time. The user, scooter number, and time are recorded into a database.

4. When the user arrives at their destination, they simply return the scooter to an available lock at any rack around campus. The locking rack identifies the returned scooter and makes the appropriate update in the database.

If the scooter isn’t returned in time, at all, or if it is found to be damaged due to misuse, the user will be fined and/or contacted. Their privilege to use the system could be revoked.




System Specifications

Rack Specifications



Rack Location

The number of vehicles each rack should accommodate, and the number of racks in a community will depend on the size of the community and the traffic patterns. We are currently doing research for more concrete numbers.

The racks should be located in high traffic areas.

Click the map for possible rack locations around Hampshire campus.

Rack Communication

Each rack has a computer which much communicate with a central server to authenticate users and keep track of the scooters. The server will be an Internet connected computer meaning the rack nodes can be connected via ethernet, dial-up, or wireless.

Rack Construction

The racks will need to be waterproof to protect the internal electronics. Also, the entire rack should have a "roof" to protect the scooters from rain.

Locking

Vehicles need to be securely locked to the rack.
Locking mechanism must be very durable. Work in wide range of temperatures. Fewer moving parts the better.
If possible, no user interaction should be required when a vehicle is returned.

Possible solution is an electric strike as seen below. It uses a electromagnetic solenoid.


A crude mock up of the locking bar which would be mounted on the front of the vehicle. The black circle is a mounted iButton, the protruding piece slides into an eletric deadbolt type lock. (Click for larger version.)

Vehicle Identification and Location in the Rack

Vehicles need to be accurately identifiable when in the rack. It also must be possible to identify which lock each vehicle is in. Several technologies have been explored and considered including Radio Frequency Identification (RFID), Bar Codes, Inductance proximity sensors, and reed switches were looked into.

We then learned about "touch memory" technology developed by Dallas Semiconductor. This technology meets all our needs, and unlike RFID, takes care of both the vehicle identification and the vehicle's location in the rack.

A touch memory device will be installed on the locking bar piece of the scooter or bicycle. When the vehicle is placed in one of the locking racks, the touch memory device will come in contact with a reader inside the rack. The reader will identify the scooter and its location, and send the data to the rack computer.

Rack Wiring Diagram


System Communication Schematic

Data Flow

Bike Program Database

The Community Bike Program database is responsible for keeping track of all vehicles, and users, and racks. It stores information such as:

  • Whether specific docks are empty or full.
  • Which vehicles are in which locks
  • Who has signed out a vehicle. Which vehicle it is. When they signed it out. When they returned it.
Table: events

Description: Records a history of events. Keeps track of:

  • Who signed in/out a vehicle
  • When they signed it in/out
  • Which rack they signed it in/out from
  • Which docking station they took it from/returned it to.
  • Which vehicle they took/returned
Field Name Data Type Example Data Description
event_id int unsigned 23 An auto incrementing unique id
date_time timestamp(14) 20011208120445 Date_time the event took place
action enum sign_out, sign_in, remote_oos, remote_is, error Whether the vehicle is being taken, returned, remotely put in or taken out of service, or if an error has occurred.
user_id mediumint unsigned 123456 The user id of the person signing in/out the vehicle
rack_num tinyint unsigned 5 The rack the vehicle was signed out/in to/from
dock_num tinyint unsigned 8 The docking station the vehicle was signed out/in to/from
vehicle_num tinyint unsigned 16 User friendly vehicle identification num
time_interval smallint unsigned 60 Number of minutes before the user must return the vehicle. Null for returns or other events.

 

Table: dock
Description: This table keeps track of the status of each and every dock on all the racks. It's used to determine what dock to unlock etc.
Field Name Data Type Example Data Description
dock_id varchar(16) AD0000087124BA01 1-wire serial number for each dock. Used internally.
dock_num tinyint unsigned 3 dock id (unique to each rack)
rack_num tinyint unsigned 2 rack id (unique to each system)
dock_status varchar(5) empty, 16 (vehicle_num) Whether the dock has a vehicle in it or not. If it does, it's set to the vehicle_num.

 

Table: vehicle
Description: Used for keeping track of vehicles.
Field Name Data Type Example Data Description
vehicle_id varchar(16) 58000006377AD201 ID stored on the iButton. Used internally.
vehicle_num tinyint unsigned 16 User friendly vehicle number. Used to easily identify vehicles
availability varchar(11) available, unavailable, 0533928 Available means it's in a dock ready to be signed out, unavailable means it is out of service, if it's signed out, it's set to the user_id of the person who signed it out.
vehicle_type enum scooter, bicycle Describes what the vehicle is, a scooter, bicycle, etc.
description text   More indepth description of the vehicle

 

Table: user
Description: The user database. For now, I guess I'm just using a mySQL database for this. There are two options for the future, create scripts that keep this database in sync with a primary user database such as an LDAP database. Or, modify the functions to access the user data directly.
Field Name Data Type Example Data Description
user_id mediumint unsigned 1234567 user id
account_status enum enabled, disabled If the user user never returned a scooter etc. they're account_status is set to disabled and they can't sign out a scooter.
first_name varchar(20) Joe user first name
last_name varchar(20) Brown user last name
phone varchar(12) 413-555-1234 phone number
email varchar(100) joe_brown@hampshire.edu email address

 

Function Specifications

The function specifications describe the details of each function, including the name, description of what it does, the arguments it takes, and what it returns.

Vehicle Specifications

General

Simplicity
Minimize number of parts and welds/bolts required
Usable by various human heights
Locking mount
Non-spoked wheels
Flat proof tires
Difficult to disassemble without special tools
Easy to repair
Simple, but solid braking system - avoid hand brakes if possible

Scooter



Bicycle

Coaster brake
No derailer

User Identification

User Input Method

Users must be identified during vehicle check-out and check-in. This implementation should remain as flexible as possible allowing for users to be identified in different ways depending on the community. In the Hampshire community all members have a identification which contains a unique identification number on a magnetic strip. Instead of implementing another identification system we intend to use the users Hampshire ID card.

Other methods of identification include smart-cards, credit-cards, public transit card , fingerprint, retina scan, and facial scan. Ideally the authentication method would be abstracted from the rest of the software similar to the Pluggable Authentication Modules (PAM) used with UNIX OS’s.

Authentication Database

The database system which is used for authentication should also be flexible if possible. Hampshire is in the midst of implementing a LDAP database to use for authentication among several other applications. In Hampshire’s case, using LDAP for authentication is a natural choice.

Team

Adam Shapiro
Founder Hampshire Yellow Bike program.
Three years experience running the program.
Very in touch with issues around community transportation
Studying sustainability

Jared Benedict
Strong background in implementing appropriate technology in communities
Studying sustainability, information technology, and design.

John Fabel
Expert on issues of Sustainability
Leader of Hampshire Sustainable Campus Plan
Strong background in design and entrepreneurship

Support

Hampshire Yellow Bike Program
Project already implemented. In use since 1999.
Already have hands-on experience.

Hampshire Community
A community already familiar with the project.
Ready and willing to take advantage of the project's next level.

Hampshire Sustainable Campus Plan


Budget

Bicycle rack

  • locking mechanism
    • Electric strikes
  • identification equipment
    • transmitters
    • scanner
    • antennas
  • location confirmation equipment
    • induction sensors
    • reed switches
  • computer Node equipment
    • low-end computer
    • card reader
    • display
  • controller equipment to interface
  • materials

Vehicle construction scooter/bicycle

  • Off the shelf equipment
  • materials

Computer Equipment for authentication

  • Centralized server
  • Software

Miscellaneous

  • Travel
  • Research supplies
  • CAD software
  • Specialized Tools

Benefits

  • Individual accountability means theft and vehicle damage is diminished.
  • By implementing racks in specific areas around a community, users know where to find a scooter or bicycle. This mean users can depend on the system as an alternative means of transportation.
  • Because scooters must be returned, it’s easy to for maintainers to find vehicles which need repair. In an anarchic system, users often leave broken vehicles out in the community. Maintainers must track them down.
  • Reduce the need for community members to bring or buy their own bicycles.

Pitfalls

  • Bicycles and scooters are likely not usable or safe in snowy conditions.
  • Advanced community bike programs which use computer check-out are expensive. However, equipment should theoretically last longer.
  • The community must be involved and feel ownership for such a project to succeed. In an anarchic system, the sense of ownership is greater when users donate their own bicycles or volunteer their time to fix bicycles. Because of the complexity of a computerized check-out system, certain aspects will require specialized knowledge which may limit community involvement. While community involvement should remain a top priority, a computerized check-out system is designed to be a true transportation alternative. Anarchic systems on the other hand rarely if ever get to that stage. Finding a yellow bike on Hampshire campus when one needs it is a rarity and convenience, not something people expect or depend on.
  • Although it is not predicted to be a major issue at Hampshire, some communities may have traffic patterns which require program maintainers to transport vehicles from racks at popular destination, to popular departure areas. The status of racks can be remotely monitored and data can be archived over time to predict when certain racks may need attention.

Related Files

Frequently Asked Questions

What happens when a rack is full?
One way to address the problem is to have users enter their destination when they sign out a vehicle. Doing so would reserve a spot in the destination rack.This technique has been used in a bike program in Europe. It has been received with mixed results by users. Some people feel there is a big brother aspect and others may not know where they will end up, for instance, they may just being using the vehicle for recreation.

How many racks will there be?
Using rough estimates Hampshire would need 10-15 racks around campus. Traffic patterns need to be looked at. It's also possible that some racks may be able to accommodate more vehicles than racks depending on how much traffic each area receives.

How many scooters will fit in each rack?
Hard numbers have yet to be determined. However, we estimate racks at Hampshire will accommodate 6-12 bicycles. We are attempting to design a rack which can scale up to accommodate many vehicles.

How many scooters will be used in total?
Again, we need to do more traffic analysis at Hampshire. We will likely have more locking bays in the rack, than the number of vehicles we have in circulation. This way, the chance of a full rack will be diminished. We hope 50-100 vehicles will be able to accommodate Hampshire's community.

Why scooters?
We are designing our system to accommodate scooters, bicycles, or similar vehicles such as the recently introduced Segway Human Transporter. We are exploring the use of scooters for several reasons. To our knowledge scooters have never been used in a community bike project. We think it would be a good match because scooters are cheap, use simple construction, easy and fun to use by various body sizes.

In community bike programs, how often are the bicycles used, and who is using them?

Will the user be charged each time they use a vehicle?
Our intention at Hampshire is provide vehicle use for no charge to the user. We want to make the use of green transportation as appealing as possible. The system and its maintenance would be paid for by outside funding, or by the college itself. In other implementations at different campuses or cities, the use could be charged a flat fee, or a per use fee.

Will there be a time limit as to how long a user can use a scooter?
The system is primarily intended to be a quick means of travel between campus buildings, not a long-term sign-out vehicle. In order for vehicles to be available to the most number of users, we plan to place a time limit on vehicle. use. A specific time limit has not been determined. It's possible that the time limit may vary depending on certain variables. Such variables include the number of scooters available, and historical scooter use. For example, as the program is used, vehicle. use will be archived. Analyzing this data may show that scooters are in high demand at specific times of the day.

What if the user has the scooter longer than their time limit, never returns the it, or damages the scooter?
Because the system tracks vehicle use by individual, the system would work in a similar way libraries sign out books. If the vehicle. is returned late, not at all, or damaged, the individual can be charged.

What sort of maintenance is required in an advanced community bike program?
The system is being designed to minimize the amount of maintenance required. This is being accomplished by:

  • using high quality, strong, simple vehicles
  • using computer controlled locking racks

The maintenance required includes:

  • dependent on traffic patterns, we may have to transport vehicles from full racks to empty racks.
  • vehicles will need to be checked occasionally for wear. Those vehicles need to be taken in for repair.


Home | About | Contribute | CommunitBike.org | Safety | Program Development