#garfield Logs

Jan 29 2012

02:31 mortenmj morning rue_shop
02:32 mortenmj rue_mohr
02:35 rue_mohr hey
02:35 rue_mohr !time
02:35 tobbor My watch says its 00:32 Sun Jan 29 2012
02:36 rue_mohr :)
02:36 mortenmj mine says 9:32
02:36 mortenmj rise and shine
02:36 rue_mohr hah, I'm good for a few hours
02:37 mortenmj your call. if you'd rather look at this in the morning, that's okay
02:37 rue_mohr I'm ok
02:37 rue_mohr when I go down I'll be down for about 8 hours
02:37 mortenmj great. so, we were looking at the state machine for the elevator car
02:37 rue_mohr yes, how are you with what you have so far?
02:38 mortenmj well, i think your example is overengineered. you have the states idle, up, down, openWait, paused. considering that openWait and paused have no information about our travelling direction, we need to store that information in memory, which means that up and down can be reduced to a single state, say «moving»
02:39 mortenmj then, considering that door transitions are instantaneous, we don't really need openWait either
02:39 mortenmj i think this machine would be equally valid if it only had «idle», «moving» and «paused»
02:39 mortenmj counterpoint?
02:39 rue_mohr I dont think they would be happy if your state machine just has moving and stopped :)
02:40 mortenmj i don't think they'd be happy if it had states that aren't necessary, either
02:41 rue_mohr how did they introduce you to state machines?
02:41 rue_mohr code wise
02:41 rue_mohr have they supplied you with an exampel of what they call a state machine?
02:42 rue_mohr I have 2 examples of work I have done I could show you
02:42 mortenmj not in this subject, but last semester we had one called digital and computer design
02:42 mortenmj where we modelled digital logic as state machines
02:43 rue_mohr your familiar with grey code? where only 1 bit changes at a time in a count sequence?
02:43 mortenmj yes
02:44 rue_mohr are you familiar with optical encoders that use 2 bit grey code?
02:44 mortenmj no
02:44 mortenmj not immediately, but i migh have encountered them
02:44 mortenmj i might have encountered something like that used to measure angle. it might have been 2 bit
02:45 mortenmj or more
02:46 mortenmj probably more. something like this: http://www.eetimes.com/ContentEETimes/Images/Design/Prog%20Logic%20DL/Gray-Codes/gc-01-08.jpg
02:46 rue_mohr internet problem
02:47 mortenmj anyway. if we store information about our direction in memory, we only need three states (in my opinion). however, i think our direction should be encoded in our states. which gives us more than the 5 you proposed
02:47 mortenmj do you agree that's a good solution?
02:47 rue_mohr please wait a sec
02:47 mortenmj sure
02:49 mortenmj but then again, is the direction we're gonna go next really a quality of the system? i'm not absolutely convinced it belongs in our states either
02:49 mortenmj so perhaps what you had makes good sense
02:50 rue_mohr ugh, the text paste sites I use are down
02:50 mortenmj http://fpaste.org/
02:51 rue_mohr isp has 16% packet loss right now...
02:52 rue_mohr http://keeganmann.wordpress.com/2011/01/02/quadrature-encoder-circuit/
02:52 rue_mohr see that for a sec
02:55 rue_mohr http://fpaste.org/8t00/
02:55 rue_mohr that is a C state machine that decodes the signals from it, and return the position difference
02:55 rue_mohr thats the memory table method..
02:55 rue_mohr my internet connection is dieing
02:57 mortenmj i take it you're suggesting i gray code my states?
02:57 rue_mohr no I'm just showing you one kind of C state machine
02:57 rue_mohr I'm gather my other example
03:00 rue_mohr the other way is with a switch or if-else set, but I cant find the codes I used that method in
03:00 mortenmj i've seen both methods, so it's okay if you can't find it
03:01 rue_mohr ok, so, what do you feel you want to implement as a state machine currently?
03:01 mortenmj which machines we should have to control this system? the one for the car, obviously. *maybe* a separate one for the door, but it isn't necessary. that could be one machine
03:02 rue_mohr ok, look at the problem this way
03:03 rue_mohr the only reason you use a state machine is becuase the outcomes of the same inputs are partly dependent on previus circumstances
03:03 rue_mohr in the case of the car, its direction after leaving a floor is dependant on what was called for before it stopped
03:03 rue_mohr it can go up, down, or remain idle
03:05 rue_mohr if the outcome could be determined from the inputs alone, you would just need a simple lookup table or something equivilent
03:05 mortenmj right
03:05 rue_mohr the history memory is what makes it a state machine
03:06 rue_mohr the door dosn't satisfy the requirements to be a state machine
03:06 rue_mohr agree?
03:07 mortenmj i disagree that memory is a requirement to call something a state machine. a classic state machine is memoryless. i do agree that a modern state machine is usually an extended state machine, that has memory.
03:07 mortenmj the door absolutely satisfies the requirements to be a classic state machine, but it doesn't have to be one
03:09 rue_mohr hmm
03:10 rue_mohr tell me about how you would set up the door as a state machine
03:10 mortenmj https://developer.opencloud.com/devportal/download/attachments/54821038/225px-Finite_state_machine_example_with_comments.svg.png
03:10 mortenmj like that
03:12 rue_mohr just trying to work out how that does and does not fit into the definition I use for a state machine
03:12 rue_mohr ah, because its latching
03:12 rue_mohr hmm
03:13 rue_mohr your familiar with RS and T flipflops?
03:14 rue_mohr [R Q]
03:14 rue_mohr [S /Q]
03:14 rue_mohr and
03:14 rue_mohr [T Q]
03:14 rue_mohr [ /Q]
03:14 mortenmj yes
03:15 rue_mohr the T flipflop is what I refer to as a state machine, the same event causes a different output depending on previous circumstances
03:15 rue_mohr your saying the RS flipflop is also a state machine, which I dont completely agree with, but will not disagree with
03:16 rue_mohr yoru door is analogous to a RS flipflop
03:16 mortenmj a state machine for a T flip flop doesn't require memory
03:16 mortenmj just more states
03:16 rue_mohr the T has two states, on and off, but the same event makes it switch between them
03:17 mortenmj which means it has four states
03:17 rue_mohr that requres memory of the previous state
03:17 rue_mohr 4?
03:17 mortenmj hm, maybe not four. let me see...
03:17 rue_mohr 2
03:17 mortenmj it's probably not relevant. either way, you would model the T flip flop without memory of previous state by using more states
03:18 rue_mohr the same transition condition leads to be being on or off depending on its previous state
03:18 mortenmj that is what a classic state machine does
03:18 mortenmj a classic state machine has *no* memory
03:18 mortenmj any information about previous state is given by its current state
03:18 rue_mohr odd, I call that a lookup table
03:19 mortenmj a machine that remembers its past state is called an extended state machine
03:19 rue_mohr ok, our terminology dosn't match, thats ok
03:19 mortenmj yeah, it's not very important
03:20 rue_mohr this helps me understand how you want to do this
03:20 rue_mohr shall we walk thru the situations from idle?
03:22 rue_mohr I can solve this, but not the way you would like
03:24 rue_mohr you can if-else this
03:25 rue_mohr the only reason I would refer to the method as a state machine is because you re-enter the function to derrive the next action instead of the function progressing as the actions occur
03:25 rue_mohr does this make sense?
03:26 rue_mohr I had one of my robotics students do that this morning
03:26 rue_mohr for operating a stepper motor
03:27 mortenmj we can walk through it from idle
03:28 mortenmj how would you solve it?
03:28 rue_mohr from idle, a button is pushed to call the elevator to a floor
03:28 rue_mohr so far I'd use a large memory table with entries programed based on rules
03:28 rue_mohr again, its less suitable for larger numbers of floors
03:29 mortenmj i think i should do something that scales easily
03:29 rue_mohr lets go thru the events so I can get this in my head
03:29 rue_mohr I do to
03:29 mortenmj ideally, it should support an arbitrary number of floors
03:29 mortenmj adding an extra 10 floors should be easy
03:29 rue_mohr yes
03:29 rue_mohr so, from idle
03:30 rue_mohr lets say a floor button is pushed from within the elevator
03:31 rue_mohr the car moves towards that floor
03:31 rue_mohr which is either up, down or not at all if the person pushes the button for the current floor
03:32 rue_mohr when thats complete, the door opens
03:32 rue_mohr wait, and close,
03:34 rue_mohr two major branch points, a) instead of a button within the elevator, a lobby button is pushed
03:34 rue_mohr b) while the elevator is moving it comes to a possable floor-stop
03:36 rue_mohr the lobby buttons can almost be treated like the car floor buttons, but if the elevator is going in the wrong direction it wont stop for that floor
03:37 rue_mohr which is jsut part of the evaluations that are made as the car passes a floor
03:37 mortenmj agreed
03:38 rue_mohr :) I'm glad this isn't a 4 way traffic intersection machine
03:38 rue_mohr I see something like this
03:41 rue_mohr if (obstruction) { disable_motors(); was_obstruction = 1; } else if (was_obstruction == 1) { enable_motors(); was_obstruction = 0; }
03:41 rue_mohr oops there should be a return after was_obstruction = 1;
03:42 rue_mohr that gets the obstruction stuff out of the way
03:43 rue_mohr so this would be in a fn like ElevatorUpdate()
03:43 mortenmj i don't envision i'll have any problems programming this
03:43 mortenmj my difficulty is with designing the machine properly
03:43 mortenmj implementing it is easy
03:44 mortenmj and we're getting way ahead of ourselves
03:44 mortenmj how to implement it isn't relevant at all at this stage
03:45 rue_mohr the only thing what I just drew for a state machine (no pic yet) dosn't work is cause it dosn't decide what to do ...
03:46 rue_mohr you said you reduced it down to 1 state for the car?
03:46 mortenmj what? no
03:46 rue_mohr what states do yo uhave for the car
03:47 mortenmj no change since what we discussed yesterday
03:47 rue_mohr yoru yesterday is my today :)
03:48 rue_mohr so the car can be idle, going up, going down, waiting open
03:48 rue_mohr ....
03:48 rue_mohr you wanted to use idle, moving, or waiting?
03:48 mortenmj it was a suggestion. an idea
03:49 mortenmj i wanted to know what you thought about it, but you still haven't told me
03:49 rue_mohr its your project, I'm not here to do it my way :)
03:49 rue_mohr without going thru and coding it, I would say I'd use a lot more states that you are
03:50 mortenmj i agree
03:50 rue_mohr beacuse I would use the states for maintaining status
03:50 mortenmj i don't think «idle», «moving» and «paused» would be an appropriate machine
03:50 mortenmj but i don't see how your suggestion would either, because it logically reduces to those three
03:50 mortenmj this was your suggestion: http://eds.dyndns.org/~ircjunk/images/elevstate2.jpg
03:51 rue_mohr your argument about combining moving-up and moving-down into one state is valid
03:51 mortenmj that has two superfluous states, and reduces to «idle», «moving» & «paused»
03:51 rue_mohr lets try to apply that
03:52 mortenmj you just said it wasn't a good design
03:52 mortenmj why would you want to run with it?
03:52 rue_mohr I have to code it to prove or disprove it now
03:52 rue_mohr it can be done either way
03:53 rue_mohr we can have 3 takeoffs from idle, one for a call upwards, one for a call downwards and one for a call to the current floor
03:53 mortenmj i think we should have pausedClosed and pausedOpen
03:53 mortenmj in addition, i think direction should be part of the state
03:53 rue_mohr ok
03:53 mortenmj which means «idle», «up», «upPausedClosed», «upPausedOpen», «down», «downPausedClosed» and «downPausedOpen»
03:54 mortenmj do you think that's wrong in any way?
03:54 rue_mohr ok
03:54 rue_mohr I think that it can all be made to work
03:54 mortenmj what do you think is the best way?
03:55 rue_mohr there is not enough information to weigh the options yet
03:55 rue_mohr I think that the differences will become aparent when you have to account for people waiting at lobbies for elevators to come by
03:56 rue_mohr if somone presses down on the 2nd floor, and the elevator is going from the 1st floor to the 3rd floor, it should not stop on 2 and pick up the person waiting on 2
03:56 rue_mohr thats where the extra states may become helpfull
03:58 rue_mohr http://fpaste.org/0r5D/
03:59 rue_mohr it seems logical to me to start with the least nunmber of states you could require and expand on them as required
04:02 rue_mohr http://fpaste.org/Td76/
04:02 rue_mohr I'v left out data types
04:02 mortenmj i do not understand why you're messing with code right now
04:02 mortenmj it's not helpful
04:03 rue_mohr I want to code in our current states and see what functionality is missing
04:04 rue_mohr posting image of a state fragment
04:06 rue_mohr http://eds.dyndns.org/~ircjunk/images/elevstate3.jpg
04:07 rue_mohr it says
04:07 rue_mohr idle -> floor button pushed -> move to floor -> open door -> wait-> close door ->
04:07 rue_mohr above move to floor is
04:07 rue_mohr -> maybe stop -> open door -> wait ->close door ->
04:09 rue_mohr my normal process is to work out all the inputs and outputs of the required machine, and then map all the rules between them, anthing that requires the same inputs to create a different output situation uses what I call a feedback state, which is a memory system
04:10 rue_mohr 2am, I'm sorry, I'm losing my ability to think
04:11 mortenmj all right. we can look at this tomorrow, if you'd like
04:11 mortenmj thank you very much for your help
04:11 rue_mohr if you can merge the operation of the button panels the machine becomes quite small, and mapping the input situations to the output situations becomes easy
04:12 rue_mohr I feel I'm failing you on this one,
04:17 mortenmj i think the buttons would just be three arrays. on for the buttons inside, one for the up-buttons outside, and one for the down-buttons outside
04:18 mortenmj and say if we're passing a floor going up, we check if a request for that floor is set in the internal button array or the external up-button array
04:19 rue_bed yes
04:19 mortenmj that should be very easy
04:20 rue_bed floor 1 <-> floor 2 <-> floor 3 <-> floor 4 :)
04:21 rue_bed tada, state machine :)
04:21 rue_bed cant go from floor 1 to floor 3 witout having visited 2
11:10 e_bed stret
11:11 rue_bed mortenmj, made any conclustions you like about how you want to do it?
15:06 mortenmj rue_bed: no, i haven't had time to think about it
15:09 mortenmj but i like the idea with idle, up, upPaused, upPausedOpen, down, downPaused and downPausedOpen
15:31 rue_mohr ok