This is both cool and disappointing. I'm sure this is more challenging than it looks, and it's cool to see emergent complexity from a (seemingly) simply set of conditions to satisfy.
However, the reason I think about elevator programming isn't to make an elevator behave the way they do today. It's to make an elevator behave better than they do today.
For example:
* I don't want an elevator to close and reopen its doors on the same floor. That's horrible user experience.
* All the interesting problems arise when there are multiple elevators servicing the same set of floors. So let's control more than one elevator at the same time.
* If the elevator is on the ground floor, and has downward calls on both the 1st and 20th floors, then it is likely more efficient to service the 1st floor first rather than bypassing them just so you can keep travelling in the same direction.
I'd like to see a version of this that, rather than enforcing arbitrary rules, just has a lot of series of inputs and lets people compete to service those inputs in the shortest number of steps.
Single-elevator control and group control are usually separate. In many systems, the group controller's authority is limited to remotely pushing the buttons in each elevator in each elevator. Thus, the group controller has no safety responsibilities.
All the hall calls (from the buttons outside the elevator) go to the group controller, which controls dispatch policy. Early systems, such as the Otis Autotronic, used analog computer components to set dispatch policy. The newest ones use machine learning.
If you set an elevator to "independent service" (this is a key switch in most elevators) it disconnects from the group controller and only obeys its own cab buttons. This is used when you need a service elevator, but not often enough to have a dedicated one. The group controller is not necessary for basic elevator operation.
However, the criterion you're optimizing for is still unclear. Should it be:
a) the total number of steps the elevator takes
b) the average number of steps each user has to wait
c) the maximum number of steps each user has to wait
d) the 90th percentile of user waiting steps
Note: here, I'm counting the steps spent waiting for an elevator as well as the steps spent in the elevator till the destination as the same, but presumably you'd want to count steps spent inside the elevator as costlier, further complicating matters.
And this not even considering what happens if your algorithm answers 20 calls, without going to any destination floors, when the elevator capacity is only 10 people.
That's what makes this such an interesting problem.
This can be accomplished in a gamified way:
Game harness simulates people comming to an elevator, pressing destination button and waiting for some time (some wait longer, some wait shorter, should also depend on distance) before giving up and taking stairs.
The elevator could or could not know about it's capacity.
Assigning "price", optionally differentiated by input/output floors, to passenger, result would be €/time or €/level. Level - predetermined sequence of passengers.
Interesting thing here is that "price" does not have to depend on distance. Taking passengers travelling short distances might look cost effective, but that could have negative effect on number of people going to a 20th floor.
I guess we are looking at a trade-off in every case. Is speed, waiting time, or moves(energy saving) your priority. When you order a set of six to eight elevators for a 70 story building you probably are allowed to set your preferences of how your elevators want to perform. This is why I could not get constant (100%) success rate with one universal algorithm. I always had to change something.
Elevators enable skyscrapers. As you build taller skyscrapers, more and more of the floor space is given over to elevators. There must be a huge incentive to improve elevator routing. I'd love to peek behind that curtain.
> Modern elevators are strange and complex entities. The ancient electric winch and “maximum-capacity-eight-persons" jobs bear as much relation to a Sirius Cybernetics Corporation Happy Vertical People Transporter as a packet of mixed nuts does to the entire west wing of the Sirian State Mental Hospital.
> This is because they operate on the curious principle of “defocused temporal perception.” In other words they have the capacity to see dimly into the immediate future, which enables the elevator to be on the right floor to pick you up even before you knew you wanted it, thus eliminating all the tedious chatting, relaxing and making friends that people were previously forced to do while waiting for elevators.
> Not unnaturally, many elevators imbued with intelligence and precognition became terribly frustrated with the mindless business of going up and down, up and down, experimented briefly with the notion of going sideways, as a sort of existential protest, demanded participation in the decision-making process and finally took to squatting in basements sulking.
> An impoverished hitchhiker visiting any planets in the Sirius star system these days can pick up easy money working as a counselor for neurotic elevators.
The Hitchhiker's Guide to the Galaxy by Douglas Adams
i get angry at my building's elevators every damn day. They should park themselves at the ground floor before 10:30am and above ground after. I get to th building before 7am and there are times when 6 of us are waiting on one of 4 elevators for at least two minutes. It's inexplicable. They should be there waiting and ready. Ain't no on 11-21 trying to go DOWN before 7.
So yes I think I could program an elevator. And yes I think I could do it better than the shit it currently is.
so are you saying that, similar to the elevator programming challenge itself, writing the elevator programming challenge was more difficult than it looked?
cool. that probably put a bigger smile on my face than it should've, but still cool.
Obviously you did not reach the level when you can program the behaviour of four elevators in the same time :) About the first and the 20th floor: How about if you've got 15 people on the 20th floor and one person on the 1st? Every button press is a request that could add more weight to the particular floor. After all the goal is to transport as many people as possible for a given time.
> Also, there might be more than one criteria to optimize for.. shortest travel time? fewest moves?
More fundamentally: do you optimise for the users of the service (lift passengers) or for the person paying for it (building owner)? Because I can imagine very different drivers there.
Indeed. This seems like a good use case for a cost/utility function. Very long wait times should be very high cost, while short wait times should be disproportionately low cost, etc.
However, the reason I think about elevator programming isn't to make an elevator behave the way they do today. It's to make an elevator behave better than they do today.
For example:
* I don't want an elevator to close and reopen its doors on the same floor. That's horrible user experience.
* All the interesting problems arise when there are multiple elevators servicing the same set of floors. So let's control more than one elevator at the same time.
* If the elevator is on the ground floor, and has downward calls on both the 1st and 20th floors, then it is likely more efficient to service the 1st floor first rather than bypassing them just so you can keep travelling in the same direction.
I'd like to see a version of this that, rather than enforcing arbitrary rules, just has a lot of series of inputs and lets people compete to service those inputs in the shortest number of steps.