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 isnt 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 OSs.
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 Hampshires
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
- 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, its 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.
|