Introduction

The goal of our final project was to design an efficient elevator simulator that can accept input from a user and mechanically operate (on a small scale) a system of 4 floors and 3 elevators using pulleys and stepper motors.  Users enter input using physical pushbuttons or the computer.  This input is then processed by the MCU and orders are given to the elevators.  We attempted to devise an algorithm that can optimally handle any number of floors.  This project seemed like a fun challenge and something that had practical applications.  Both of us have been frustrated at times by the inefficiency of some of the elevators here at Cornell, and we wanted to see if we could do a better job.

Definition of Terms

Inside Button – A button on the inside of an elevator car.  A passenger would press this button after getting on an elevator.
Outside Button – A button outside the elevator cars.  There are at most two outside buttons on each floor (up and down).  In a real building there may be more for convenience, but the same functionality can be achieved with only two.
Request – A request to either get off on a floor (given to a specific elevator if an inside button has been pushed) or a request to be picked up on a floor going either up or down.  An outside button push will only assign a pick-up request to a single elevator.

High-level Design

The essence of our project was the high-level design.  Since it was our goal to simulate an efficient elevator system, designing the logic produce desirable results proved to be a challenge.  We decided the best way to control three separate elevators was to have each elevator respond optimally to any given set of requests (to pick up or drop off passengers).  We could then write an algorithm that would predict which elevator could respond the fastest to a passenger request and assign the request to that elevator.  While our physical elevator system only consists of 4 floors, the design can be scaled to any number of floors.

Individual Elevator Behavior

The basis for our elevator’s behavior is the elevator algorithm, in which the elevator handles all requests in one direction before turning around.  Our code ensures that a single elevator will follow this behavior.  The logic that controls a single elevator is shown below.  Remember that in the case of outside buttons, a request is not necessarily the same as a button push (see definition of terms).  Handling these buttons is covered in the next section.
Delegating Requests
In order to control our system of three elevators efficiently, we had to come up with a way to appropriately assign requests to each elevator.  Assigning requests from the inside button pushes was trivial, as an elevator must respond to its own inside buttons.  For each outside button pushed, only one elevator receives the request.  Our algorithm to assign requests favors the elevator with the fewest other requests in order to split traffic evenly among the elevators and minimize time spent waiting to get off.  In the case where two or more elevators have the same number of other requests, we compute the worst-case distance that each one must travel to answer the request.  The three scenarios are explained below.
Case 1:  In this case, the elevator is traveling towards the floor that the request is on in the same direction that the request is in.  The worst-case distance (maximum number of floors) between the elevator and the request is just:
|requestFloor – currentFloor|
Where requestFloor is the floor that the request is on and currentFloor is the floor that the elevator is currently on.
Case 2:  In this case, the elevator is traveling in the opposite direction that the request is in.  The worst-case distance between the elevator is the distance from the elevator to end of the shaft in its current direction of travel plus the distance from the end of the shaft back to the request floor.  So, if the elevator is traveling upward, the distance is:
(floors–1–currentFloor)+(floors–1–requestFloor)
If the elevator is traveling downward, the distance is:
currentFloor + requestFloor
Where floors is the number of floors in the elevator system.
 Case 3:  In this case, the elevator is traveling away from the floor in the same direction that the request is in.  The worst-case distance is:
2*(floors – 1) – |requestFloor – currentFloor|.

Alternate Modes of Operation

We included several other modes of operation aside from the normal mode described above.  Below is a quick description of each mode.
Trivial Mode – Sends elevator 1 to do everything, ignores other elevators.
Simple Mode – All the elevators chase each outside button press and respond to their own inside button presses.  This is equivalent to having 3 separate elevators in trivial mode.
Sabbath Mode – Elevators ignore any button pushes.  They move up and down stopping at all floors along the way.  The elevators are staggered to minimize worst case waiting time.
Hardware Design
We built a 3-shaft, 4-story elevator model consisting of K’NEX and wooden dowels.  We added motors and pulleys to raise and lower the elevators.  The elevators are controlled using eighteen pushbuttons, twelve of which represent internal elevator buttons.  The other six outside buttons call elevators to particular floors.

Mechanical Design
Our elevator shafts are built from plastic K’NEX pieces.  We chose this material because it offered flexibility in design, ease of construction, and was available for free.  We added wooden guide dowels to align the elevator cars within the shafts.  The elevators are raised and lowered with twine using a pulley system.  The other end of the twine was attached to pulleys on each motor.  The motors were nailed to two parallel pieces of wood.

Parts List:

For more detail: Elevator Bank Using Atmega32