I'm trying to build a table to describe the behaviour of the FSA for a coin change machine described below.
There is a slot that accepts a 50c coin and 2 buttons that a user can press to get a 20c or 10c coin as change.
As soon as the 50c coin is inserted the machine locks to prevent another coin from being added. When the user presses the 20c button the machine checks that the remaining value is sufficient then gives the user a 20c coin. If the remaining value isnt sufficient the machine "dies" (for simplicity). The 10c button works similarly.
The events of the machine are insert50c, give20c, give10c.
So, from my understanding this FSA has 6 states lets say 0,10,20,30,40,50. The states are represented by the value of money remaining to be returned. I've drawn a rough state diagram here but am i missing any transitions?
your statechart looks good. In the task it said " a user can press to get a 20c or 10c coin". I am missing this user interactions completely. What is if there is an amount of 10c and the user presses 20c?
So if the machine is only allowed to accept 50c for change and not 20c it's ok. Every coin change, money exchange machine has a Cancel button to break up. What is with this?
Related
I am curious how the user input is handled in micro-controllers in way that all other work is not blocked.
For instance, I have modern gas boiler - Vaillant, boiler is running his own tasks while I can scroll in the user menu, press buttons and so on.
How this is worked out from conceptual point of view?
Is there another micro-controller which handles user input and then it pushes selected inputs to main controller?
Or there is just some type of scheduller in main controller and it is scheduling so fast so it can handle user inputs AND background tasks?
How this is handled in general so user can play around with menu and so on without blocking the main task.
Thank You
This can be handled in many different ways and, depending on the complexity of the overall application, it can be as simple as a super-loop, or as complex as a multitasking based application with several independent tasks each doing their own thing (e.g., one doing key press detection, another dealing with serial comms, another updating the [G]LCD, etc.).
Your particular example can easily be handled with the super-loop approach, although a multitasker can also be used for (IMO) simplicity in coding.
For example, with the super-loop approach, each time through the loop you call a key press detection routine which checks if a key is pressed and counts time up to some maximum as long as the key press is still present. It does not block, it exits immediately. When the count reaches a minimum to accept the key (e.g., corresponding to about 50-100 msec) you return the key pressed and zero the counter (for auto key repeat), or save the key in a temporary buffer and return it only when the key is eventually released (if no auto key repeat is desired).
The display works in a similar way. The current screen is updated depending on which state the device is in. When the UP/DOWN key (for example) is detected, the index of the scrolling item changes up or down and the screen is redrawn with the new state.
There are certain situations that a multitasker is the only reasonable way to solve such problems if you don't want your app to become a un-debuggable mess of flags, and ifs. Dealing concurrently (and smoothly) with multiple interfaces (e.g., GPS, GSM, user terminal, key/LCD) is one such example.
BTW, interrupts for key presses are IMO an overkill unless you are in some battery saving sleep mode and need a hardware way to wake up. Human key presses are always too slow by comparison to CPU speeds and can be detected reliably by simple polling.
Most CPUs have some form of interrupts (even the PC).
Basically the interrupt tells the CPU to stop what it is doing and handle some realtime event. When the interrupt handler is complete the CPU will resume its original program.
More detailed information on interrupts is available on wikipedia
I'm programming a Pepper app with Choregraphe to make a conversation. This conversations have some different sorted states:
Hello (start of conversation)
ask for information
Specify the information
Goodbye (end of the conversation)
To start a conversation, people have to get close to the robot and the robot has to detect a face.
The problem is that if I am in middle of the conversation and the robot detect another face, it starts the conversation at the beginning. So I need to disable the event temporally, while the robot is in a conversation. Is there a way to do it?
These are the events output of Choregraphe:
At your place, I would program it as a finite state machine: you decide your detection and the way to switch from one state to another, in a simple way. Each processing of one state is stopped when you change state.
You can download a simple state machine here: http://protolab.aldebaran.com/public/the_3_templates.zip
you cannot disable them on that format, but if you use the "subscribe to event" box, there are start/stop inputs that you can use to enable/disable the box, i.e. subscribe/unsubscribe to the events.
At the end I visit this part of documentation and looked at Engagement Modes.
To allow a wider range of behaviors, ALBasicAwareness provides 3 engagement modes that specify how “focused” the robot is on the engaged person.
“Unengaged”: (Default mode) when the robot is engaged with a user, it can be distracted by any stimulus, and engage with another person.
“FullyEngaged”: as soon as the robot is engaged with a person, it stops listening to stimuli and stays engaged with the same person. If it loses the engaged person, it will listen to stimuli again and may engage with a different person.
“SemiEngaged”: when the robot is engaged with a person, it keeps listening to the stimuli, and if it gets a stimulus, it will look in its direction, but it will always go back to the person it is engaged with. If it loses the person, it will listen to stimuli again and may engage with a different person.
I have used FullyEngaged and the robot only focuses on the first person that enter the robot Zone 1.
This is done like this:
basic_awareness = ALProxy("ALBasicAwareness", ip_robot, port_robot)
basic_awareness.setEngagementMode("FullyEngaged")
basic_awareness.startAwareness()
I'm on a project using arduinos.This is my idea:
I have a squared signal that can slightly change. This signal gives me 58 pulses and then 2 empty spaces, indicating the cycle's beginning.
My objective is to generate another signal that changes according to this one.
My idea is to first get a sample of the signal for each X time, to get the number of pulses.After this, I want to read my cycle's start, to be able to know where my signal is every time.Then I'll generate my signal depending on that.
My problem is that I think I'll need a loop for getting my sample, which lasts as long as the pulse of the signal that I want to generate, or probably even longer, and another loop for detecting my start.
Is there any way of doing this with the same chip?Or my function is always gonna get stuck with the sample instead of generating my pulses?
Thanks!
yes it is possible, and there are a lot of way to solve this problem.
I would use a state machine.
In the first state, you are waiting for your "start", so you do a pulseln() on the input pin, if the pulase duration is good you'll increase a variable, if not reset that variable.
After that look at variabile value: if it is 56 you enter the second state.
In the second state you do what you have to do, and eventually fall back to state 1 (waiting a new "start") or enter another state.
As you can see, that approach is good if you have a finite (and relativly small) number of state, like a protocol. You can just use the code from state 1 if you need only to do something after the "start" and go backj to wait "start"
At the moment I am writing a turn based game for the iOS platform. The client is written in Objective-C with CocoaTouch, and the server is written in C++ for the Ubuntu Server OS. The server is connected to a MySQL database, in which it stores user & game data.
Right now I wish to implement a time-per-turn restriction, and this has to be done on the server side. When a user takes a turn, the next user will have a maximum of 24 hours to answer, otherwise I want the game to skip this user's turn and move on to the next player. I have some ideas about how to do this, but I am not sure if they are any good. What I've been thinking of is storing the date&time of the last turn taken as an entity related to the Game table on my SQL database. Then I'm thinking of launching a thread on the server which runs until termination, and looks up current time minus every game's last turn, say every minute or so. If it's been more than 24hrs since the last turn was taken, this thread allows the next player in the queue to take their turn, and skips the lazy player.
Does it sound over-complicated? Is there another, more simple way to do this? I know it's been done in many games before, I just don't know how. Thanks in advance!
I don't think you need any threads or background processes at all in this case.
What I see here is a simple algorithm:
When a user logs in to the game/match - check up the last turn ending time in the database,
If the elapsed time from the last turn ending time is greater than 24h, get the current time, substract the time from the database (obviously you need to convert both times into hours) and divide it by 24,
If the division yelds an odd number, it's the turn of the other player (player A)
If the division yelds an even number, it's the turn of the player B.
Set the database time to databaseTime+division*24
This algorithm can skip multiple turns. When player A finishes his move, and 48h passed, it's players B turn.
You probably just want a background process that has a schedule of "next actions" to take, a sort of priority queue you can work through as the events should be triggered.
A single process can handle a lot of independent games if you design the server properly. The architecture would pick up an event, load any associated data, dispatch accordingly, and then go back to waiting for new events.
C++ does have frameworks for this, but you could prototype it in NodeJS or Python's Twisted really quickly.
Please look at the reactor pattern (boost.asio, ACE). These frameworks are asynchronous, use an event-driven model and require no threads. Below is pseudo code on how you can solve it:
reactor.addTCPListener(acceptSock(), Handler::AcceptSock) // calls AcceptSock when accepting a new TCP connection
rector.addTCPListener(clientSock, Handler::ClientData) // calls ClientData when user is sending the server game stats (its move, status etc)
.
.
.
later on somewhere
.
.
.
for(set<Game>::Iterator it = games.begin(); it != games.end(); ++it) {
(it*)->checkTurn() // this call can be responsible for checking the timestamps from the ClientData function
}
Summary:
With the reactor pattern you will be able to have a non-blocking server that can do cleanup tasks when it is not handling IO. That cleanup can be comparing timestamps to switch/pass turns.
I'm having trouble wrapping my head around this, and I apologize if this question isn't very clear. But I'll try.
For the sake of this post, I'll simply my problem a bit. I'm writing a game of multiplayer Tic Tac Toe (not really, but it's close enough to count). There are only three actions any given player can make:
The current player is allowed to place a marker.
Either player is allowed to request an Undo. The other player can choose to allow or deny the request.
Either player is allowed to Resign.
I wrote a GameEngine class that keeps track of the game board, checks the validity of marker placement, and win conditions. I would like to write Player classes, such as TerminalPlayer (to play the game from a command line), NetworkPlayer (to accept moves from a server), and ArtificialPlayer (to make it play offline).
My problem is this: given that each Player can send commands at any time (placeMarker, requestUndo, Resign), how do I structure this game?
I can think of solutions that might work (put each player in a thread, and have the GameEngine monitor requests), but everything I come up with is so clunky and awkward. I feel like there should be a good pattern for this, but I can't find it.
Specifically, can you answer:
What is the pattern that solves this problem? Does one exist, or is this more simple than I'm making it?
If a Boost library (or something like it) has solved this problem elegantly, what's the name of that library?
Seems like a simple state machine would let you manage the game.
When some input is recieved to the server, you need to validate, based on the game rules, and decide weather to execute the input or discard it. As mentioned by Esteban, the game state would progress as a state machine, including state on which player is currently expected to take a turn.
Different pieces of input will be allowed at different states of the game,
If the possible states are:
Player 1 Turn
Player 2 Turn
Player 1 Request Pending
Player 2 Request Pending
Game Over
Then you have a list of actions, when they are allowed, and how they change the state.
Player 1 make turn:
Allowed states: Player 1 turn
New State: Player 2 turn
Player 1 Request Undo:
Allowed states: Player 1 turn
New State: Player 1 Request Pending
Player 2 Deny Request:
Allowed states: Player 1 request pending
New State: Player 1 Turn
Player 2 Resign:
Allowed states: ALL
New State: Game Over
If a player makes a move out of turn, simply discard it.
The concept you are looking for is called a game loop. The term is fairly Googleable for how generic it sounds. It is a simple forever loop that checks for input, steps game state and redraws the screen. For the network player I would probably run that in a separate thread and have it post events that the main game loop picks up.