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

31–40 of 118 posts

Re: So You Think You Can Program an Elevator

#32

Post by wodenokoto »

clarkmoody wrote: post #15

A project during my graduate work was to solve this problem. You can read my write up, which includes pseudo-code for the best algorithm I found[1]. Long story short: a simple, rules-based algorithm defeated my best efforts at having multiple elevators working together to coordinate their action. [1]: https://clarkmoody.com/Moody_AgentBasedElevatorControl.pdf

This looks really funny. Is it a spoiler if I haven't done the posted link yet? If so I'll read it later :)

Re: So You Think You Can Program an Elevator

#33

Post by tn13 »

When I was teaching assistant at University for Real Time Safety Critical Systems class this was one of the star assignments in the class.

Instead of writing just a dummy program we built an actual elevator using servo motors and asked students to code using different logic

1. Single elevator 2. Double elevator 2. Double elevator with various kinds of optimizations (reduce the energy used v/s reduce the time for each passenger).

All had to be done using embedded C on an ATMEGA processor.

Then we let students do the exact same coding using Esterel where you essentially represent everything as the state diagram.

It was so much fun for bother teachers as well as students because when you deal with real hardware suddenly the scope of problems goes beyond merely getting the logic right.

Re: So You Think You Can Program an Elevator

#34

Post by southphillyman »

This was one of my white board exercises during the interview for my current job. I found it interesting because it seems very easy when the question is asked but it allows for a lot of communication between the interviewer and interviewee as the edge cases are fleshed out.

Re: So You Think You Can Program an Elevator

#35

Post by nosequel »

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…

Same exact thing, about 16 years ago for me. He presented it (I think) to see who procrastinated on the project, knowing it'd take way longer than it sounded.

Re: So You Think You Can Program an Elevator

#38

Post by platz »

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?

Re: So You Think You Can Program an Elevator

#39

Post by smaddox »

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?

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.
Post reply on HN