Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

So You Think You Can Program an Elevator

github.com

Post reply on HN
Print view View original

81–90 of 118 posts

Re: So You Think You Can Program an Elevator

#81

Post by rodgerd »

platz wrote: post #38
phasmantistes wrote: post #22

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 doo…

Also, there might be more than one criteria to optimize for.. shortest travel time? fewest moves?

> 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.

Re: So You Think You Can Program an Elevator

#82

Post by rodgerd »

caf wrote: post #60
The_Magistrate wrote: post #24

Earlier quoted context omitted.

Taller buildings with complex and highly trafficked elevators still do this only using electronics. Employees swipe their badges at a podium which reads what floor they work on and indicates which elevator they should proceed to. The system can intelligently schedule the elevator for that person to use knowing where their destination is.

I'm in a building with a mere nine floors that has such a system (the only buttons in the elevators themselves are door open, door close and alarm). I imagine that the technology will increasingly appear in the smaller buildings as their elevators are built or refurbished.

Whenever I use those sorts of lifts I find it very unsettling - it's interesting, because floor buttons vs external destination buttons give me no more control over the lift, but as a user I become very anxious when my mechanism for "driving" the lift is taken away.

Re: So You Think You Can Program an Elevator

#83

Post by Animats »

phasmantistes wrote: post #22

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 doo…

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.

Re: So You Think You Can Program an Elevator

#86

Post by MzHN »

lfowles wrote: post #68
Cshelton wrote: post #23

Earlier quoted context omitted.

This is awesome, I'm closing it now though as well. This is how teaching should be...this exercise isn't at all about programming and more about how to think. This can be simplified into a drag and drop block language and given to grade school kids as a really good exercise. Many programmers in the professional world today would really struggle with this because they never learned to actually think, they just "progra…

This would be a great Blockly[0] demo [0]: https://developers.google.com/blockly/?hl=en

Indeed. Example of a similar game using Blockly, with the option to switch to JavaScript:

http://slushsmackdown.com

Re: So You Think You Can Program an Elevator

#87

Post by est »

noir_lord wrote: post #4

Very similar immediately playable JavaScript version. http://play.elevatorsaga.com/ Which I'm now closing as I lost too much time to this the first time I saw it.

Somehow I find this API counter-intuitive and painful to use.

- Why currentFloor() is a function not a property?

- Why both goingUpIndicator() and goingDownIndicator() instead of .direction property?

- Why name destinationDirection() instead of currentDirection?

- Why only floor_button_pressed but no in-door button press event?

I gave up.

Re: So You Think You Can Program an Elevator

#88

Post by dwd »

Cshelton wrote: post #23
noir_lord wrote: post #4

Very similar immediately playable JavaScript version. http://play.elevatorsaga.com/ Which I'm now closing as I lost too much time to this the first time I saw it.

This is awesome, I'm closing it now though as well. This is how teaching should be...this exercise isn't at all about programming and more about how to think. This can be simplified into a drag and drop block language and given to grade school kids as a really good exercise. Many programmers in the professional world today would really struggle with this because they never learned to actually think, they just "progra…

My kids played this first time around, they would have been grade 5 or 6 at the time and got through to level 7 before hacking the level selection and trying random levels to see which ones their approach worked with.

Re: So You Think You Can Program an Elevator

#89

Post by seivan »

seivan wrote: post #54
arnarbi wrote: post #14

This was was posed as the the first homework assignment in my first undergrad CS class (15 years ago). I don't think a single person managed to do it. It's a classic example of a problem that you think is appropriate to throw at new programmers but find out it goes terribly wrong because the hard part is designing a suitable state machine first. If you just start coding without a full model that covers all the edge c…

Don't go for a FSM. GKRuleSystem[0] to the rescue! Or any other Fuzzy Logic(?) framework. Or maybe a behaviour tree, which is how I would have (tried) to design it with. I hope I get something like this on an interview, instead of "reverse binary tree" like questions. This actually seems like a fun problem to solve. Knowing my defect brain, it would put a lot of effort into this because it's kinda fun. Also because I…

Not sure why I am being downvoted here. A FSM would make things very hard to read compared to a BT. The fact that you would have to use a stack to pop events shows that it might not be the best suited use.

Re: So You Think You Can Program an Elevator

#90

Post by friendzis »

neil_s wrote: post #30
phasmantistes wrote: post #22

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 doo…

THIS. 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 sa…

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.

Post reply on HN