I can build a PID controller in the Haskell FRP library netwire using loop from the ArrowLoop instance provided for Wires.
I can also implement switching between controllers or between a controller and a manual input using switch.
How can I implement bumpless transfer, for example using the "tracking" strategy explained here (or in any number of control engineering articles/books)? Another strategy might be acceptable if it has good performance, but the tracking approach is appealing for my application because it also address anti-windup.
I'm having trouble squinting at the block diagram hard enough to make it look like the type of two (or one?) loop applications.
There are two loops in each diagram. It's helpful when finding loops to redraw the diagrams so that all of the inputs enter the same sides of all of the elements, all of the outputs leave the same other sides, and, if possible, minimize line crossings. In these diagrams, inputs enter the bottom, left, or top of an element, and outputs leave to the right.
The overall system has one loop, feeding the output of the process into the subtraction for the error comparison:
The control system has one loop, feeding the final control output after selection of controller (the PID controller or the manual control) into the tracking PID controller. The overall output is the Output on the far right.
The tracking PID controller has two loops. One is the feedback loop for the derivative. The loop for the derivative could disappear inside another component. The other loop feeds back the output of the PID controller into the comparison between the PID controller's output and the control output actually controlling the process. Note that the order of the P,D,and I branches is different in this diagram to remove the line crossings
Notice that if the tracking PID controller had its own Output connected to Track, the difference from the first subtraction would be 0, and the integration branch would be unchanged by the addition of 0.
Related
I am new in doing an activity and currently, I am trying to draw one based on given description.
I enter into doubt on a particular section as I am unsure if it should be 'split'.
Under the "Employee", the given description is as follows:
Employee enter in details about physical damage and cleanliness on the
machine. For the cleanliness, there must be a statement to indicate
that the problem is no longer an issue.
As such, I use a foreach as a means to describe that there should be 2 checks - physical and cleanliness (see diagram in the link), before it moves on to the next activity under the System - for the system to record the checks.
Thus, am I on the right track? Thank you in advance for any replies.
Your example is no valid UML. In order to make it proper you need to enclose the fork/join in a expansion region like so:
A fork/join does not accept any sematic labels. They just split the control flow into several parallel ones which join at the end.
However, this still seems odd since you would probably have some control for the different inspections being entered. So I'd guess there's a decision which loops through multiple inspection entries. Personally I use regions only for handling interrupts. ADs are nice to a certain level. But sometimes a tabular text (like suggested by Cockburn) is just easier to write and read. Graphical programming is not the ultimate answer (unlike 42).
First, the 'NO' branch of the decision node must lead somewhere (at the end?).
After, It differs if you want to show the process for ONE or MULTIPLE inspections. But the most logical way is to represent the diagram for an inspection, because you wrote inspection without S ! If you want represent more than one inspection, you can use decision and merge node to represent loop that stop when there is no more inspection.
Trying to learn MCST using YouTube videos and papers like this one.
http://www0.cs.ucl.ac.uk/staff/D.Silver/web/Applications_files/grand-challenge.pdf
However I am not having much of a luck understanding the details beyond the high level theoretical explanations. Here are some quotes from the paper above and questions I have.
Selection Phase: MCTS iteratively selects the highest scoring child node of the current state. If the current state is the root node, where did these children come from in the first place? Wouldn't you have a tree with just a single root node to begin with? With just a single root node, do you get into Expansion and Simulation phase right away?
If MCTS selects the highest scoring child node in Selection phase, you never explore other children or possibly even a brand new child whilst going down the levels of the tree?
How does the Expansion phase happen for a node? In the diagram above, why did it not choose leaf node but decided to add a sibling to the leaf node?
During the Simulation phase, stochastic policy is used to select legal moves for both players until the game terminates. Is this stochastic policy a hard-coded behavior and you are basically rolling a dice in the simulation to choose one of the possible moves taking turns between each player until the end?
The way I understand this is you start at a single root node and by repeating the above phases you construct the tree to a certain depth. Then you choose the child with the best score at the second level as your next move. The size of the tree you are willing to construct is basically your hard AI responsiveness requirement right? Since while the tree is being constructed the game will stall and compute this tree.
Selection Phase: MCTS iteratively selects the highest scoring child node of the current state. If the current state is the root node, where did these children come from in the first place? Wouldn't you have a tree with just a single root node to begin with? With just a single root node, do you get into Expansion and Simulation phase right away?
The selection step is typically implemented not to actually choose among nodes which really exist in the tree (having been created through the Expansion step). It is typically ipmlemented to choose among all possible successor states of the game state matching your current node.
So, at the very beginning, when you have just a root node, you'll want your Selection step to still be able to select one out of all the possible successor game states (even if they don't have matching nodes in the tree yet). Typically you'll want a very high score (infinite, or some very large constant) for game states which have never been visited yet (which don't have nodes in the tree yet). This way, your Selection Step will always randomly select among any states that don't have a matching node yet, and only really use the exploration vs. exploitation trade-off in cases where all possible game states already have a matching node in the tree.
If MCTS selects the highest scoring child node in Selection phase, you never explore other children or possibly even a brand new child whilst going down the levels of the tree?
The ''score'' used by the Selection step should typically not just be the average of all outcomes of simulations going through that node. It should typically be a score consisting of two parts; an "exploration" part, which is high for nodes that have been visited relatively infrequently, and an "exploitation" part, which is high for nodes which appear to be good moves so far (where many simulations going through that node ended in a win for the player who's allowed to choose a move to make). This is described in Section 3.4 of the paper you linked. The W(s, a) / N(s, a) is the exploitation part (simply average score), and the B(s, a) is the exploration part.
How does the Expansion phase happen for a node? In the diagram above, why did it not choose leaf node but decided to add a sibling to the leaf node?
The Expansion step is typically implemented to simply add a node corresponding to the final game state selected by the Selection Step (following what I answered to your first question, the Selection Step will always end in selecting one game state that has never been selected before).
During the Simulation phase, stochastic policy is used to select legal moves for both players until the game terminates. Is this stochastic policy a hard-coded behavior and you are basically rolling a dice in the simulation to choose one of the possible moves taking turns between each player until the end?
The most straightforward (and probably most common) implementation is indeed to play completely at random. It is also possible to do this differently though. You could for example use heuristics to create a bias towards certain actions. Typically, completely random play is faster, allowing you to run more simulations in the same amount of processing time. However, it typically also means every individual simulation is less informative, meaning you actually need to run more simulations for MCTS to play well.
The way I understand this is you start at a single root node and by repeating the above phases you construct the tree to a certain depth. Then you choose the child with the best score at the second level as your next move. The size of the tree you are willing to construct is basically your hard AI responsiveness requirement right? Since while the tree is being constructed the game will stall and compute this tree.
MCTS does not uniformly explore all parts of the tree to the same depth. It has a tendency to explore parts which appear to be interesting (strong moves) deeper than parts which appear to be uninteresting (weak moves). So, typically you wouldn't really use a depth limit. Instead, you would use a time limit (for example, keep running iterations until you've spent 1 second, or 5 seconds, or 1 minute, or whatever amount of processing time you allow), or an iteration count limit (for example, allow it to run 10K or 50K or any number of simulations you like).
Basically, Monte Carlo is : try randomly many times(*) and then keep the move that led to the best outcome most of the times.
(*) : the number of times and the depth depends on the speed of the decision you want to acheive.
So the root node is always the current game state with immediate children being your possible moves.
If you can do 2 moves (yes/no, left/right,...) then you have 2 sub-nodes.
If you cannot do any moves (it may happen depending on the game) then you do not have any decision to make, then Montec Carlo is useless for this move.
If you have X possible moves (chess game) then each possible move is a direct child node.
Then, (in a 2 player game), evey level is alternating "your moves", "opponent moves" and so on.
How to traverse the tree should be random (uniform).
Your move 1 (random move of sub-level 1)
His move 4 (random move of sub-level 2)
Your move 3 (random move of sub-level 3) -> win yay
Pick a reference maximum depth and evaluate how many times you win or lose (or have a sot of evaluation function if the game is not finished after X depth).
You repeat the operation Y times (being quite large) and you select the immediate child node (aka: your move) that leads to you winning most of the times.
This is to evaluate which move you should do now. After this, the opponent moves and it is your turn again. So you have to re-create a tree with the root node being the new current situation and redo the Monte Carlo technique to guess what is your best possible move. And so on.
It is my first time doing a Petri net, and I want to model a washing machine. I have started and it looks like this so far:
Do you have any corrections or help? I obviously know its not correct, but I am a beginner and not aware of the mistakes you guys might see. Thanks in advance.
First comments on your net's way of working:
there is no arrow back to the off state. So once you switch on your washing machine, won't you never be able to switch it off again ?
drain and dry both conduct back to idle. But when idle has a token, it will either go to delicate or to T1. The conditions ("program" chosen by the operator) don't vanish, so they would be triggered again and again.
Considering the last point, I'd suggest to have a different idle for the end of the program to avoid this cycling. If you have to pass several times through the same state but take different actions depending on the progress, you have to work with more tokens.
Some remarks about the net's form:
you don't need to put the 1 on every arc. You could make this more readable by Leaving the 1 out and indicating a number on an arc, only when more than one tokens would be needed.
usually, the transitions are not aligned with the arcs (although nothing forbids is) but rather perpendicular to the flow (here, horizontal)
In principle, "places" (nodes) represent states or resources, and "transitions" (rectangles) represent an event that changes the state (or an action that consumes resources). Your naming convention should better reflect this
Apparently you're missing some condition to stop the process. Now once you start your washing will continue in an endless loop.
I think it would be nice to leave the transition graphics unshaded or unfilled if it is not enabled. Personally I fill it green if it is enabled.
If you want someone to check if you modeled a logic properly in your Petri Net then it would be nice if you include a description of your system logic in prose.
I am currently trying to understand arrows and FRP, and I came upon a question, which I cannot seem to map to FRP, namely how to model a road network.
I thought I could model a road network as Arrows, where each Arrow represents a road segment. It accepts streams of cars at locations and times and produces the same type, albeit with different locations and times.
So far so good. But this model does not take into account, that segments may get jammed. While each segment could well respond to heavy traffic and delay cars more and more, the more congested it gets, there would be no backwater effect, i.e. the jam would not propagate backwards to other road segments.
I suspect I am applying too much OO thinking here, instead of focusing on what needs to be computed, but I cannot get it right in my head.
How can I model a road network with Arrows such that backwater effects are taken into account?
The problem is that in arrows and in FRP the flow of information is in general unidirectional. Think of a FRP arrow like a piece of digital circuit. The output of a circuit element doesn't depend on what's connected to it - it just "offers" the output to whoever is interested. This is also described visually in Primitive signal functions in the Yampa overview:
Your situation is different. The state of a segment of a road depends on both the next and previous segments - cars are comming from the previous one, but if cars can't leave to the next one, they have to stay. It's just like a pipe with running water. If you close the pipe at its end, water stops, and the information about that propagates backwards through the pipe at the speed of sound in water.
So each road segment will need to have 2 inputs: One saying let's say how many cars can the following segment accept, and how many cars are coming from the previous segment (which should always be less or equal to the number of cars the segment can accept at the moment). This means that the FRP signal flow will be actually circular. For this you'll need loops, shown in the last image in the above diagram, which are captured by ArrowLoop type-class. Most likely you'll have a custom binding function for road segments that'll be internally creating the required loops. Note that there must be a time delay in a loop, to prevent it from diverging, which makes sense as it takes some time for cars to go from one segment to another.
(I'll perhaps expand the answer with an example, if I'll have more time.)
I'm making a chess game, rendered with OpenGL.
I'm not looking for somebody to tell me all of the answers, I would like to figure the code out on my own, but pointing me to the right concepts is what I really need. At this point, I'm not sure where to start. Here is what I've figured out:
An enumeration, TurnState, with the following values:
playerOneTurn
playerTwoTurn
Stopped
An enumeration, GameState, with the following values:
playerOneCheck
playerTwoCheck
playerOnecCheckMate
PlayerTwoCheckMate
InitializingGame
Tie
NormalPlay
An abstract class, Player, and a subclass, Computer.
A class, ChessGame, with the following fields:
Player p1, p2
TurnState turnState
GameState gameState
A class, Move, with the following fields:
*Piece
Location origin
Location destination
A class, Location, with the following fields:
row
col
*ChessBoard
A class, ChessBoard, with one method, isValid, which takes a Move and checks if the move is valid or not.
An abstract class, ChessPieces, with the following methods:
GetValue() // returns an int value of the piece (for scoring)
GetPosition() // returns the current position of a piece
getIsSelected() // returns a boolean, true if selected, false if unselected
move() // moves the piece in a way dependent upon what piece
And the following subclasses:
Pawn
Rook
Queen
King
Knight
As to the AI part of the chess game:
To get a chess AI, or any sort of turn based game AI, you will need to calculate the "value" of the game in a given turn (that's important) (i.e. you assign each piece a value and sum the values for player1 and player2 and then you do score = player1score - player2score, so negative values will benefit player 2 and positive ones, player 1, that's just a basic example and not a very efficient one, but it's the most basic way to explain what the "value" of the game would be).
After you can calculate that you need to be able to calculate every possible move of a player given a certain configuration of the board.
With that you will be able to build a decision tree in which you will have as the root node the current state of the game. The next "level" of the tree will represent every possible state you can get to from the current state (and so forth). It's important to notice that if you consider player1 possible moves in on level of the tree you will consider player two possible moves in the next.
Next thing to do would be:
suppose player1 is gonna make a move, he will look into in the tree until depth 5 (for a chess game you'll never look in the whole tree). So he will choose a move that will be optimized for him, that would mean: at each level he'll consider HIS best move or player2's best move (so he will work on the worst case scenario), so he'll move the the highest valued node in the next level of the tree.
To calculate a value of a node you do the following:
NOTE: considering root node is of depth 0, every odd depth node need to be maxValue for player1 and every even depth node minValue for player2.
You'll expand the tree to the max depth you define, for the node in the maxDepth you'll just calculate the value of the board (which I mentioned in the beginning of my answer), for upper nodes you'll do:
even node's value : minValue between all child nodes
odd node's value : maxValue between all child nodes
So basically you'll do the regression to find the value of a node based on the value of deeper nodes.
Well, that's the basic idea, from it you can research some other stuff, if you want you can PM me, I've done some work on this kind of search, and I just described the most basic idea here, for an efficient code you'll need lots of optimization techniques.
Hope it helped a little
First of all: Separate the two: AI and GUI/OpenGL. In chess it is normal to have the GUI and the AI (the "Engine" in computer chess lingo) in two different processes that's communicating with a predefined protocol. The two most popular protocols for this are UCI and WinBoard.
For the chess engine part, you basically need three thing:
A board/position representation
A leaf node evaluation function
A search algorithm
I suggest you read:
Chess Programming WIKI
TalkChess forum for computer chess
Study a open source computer chess engine, like Stockfish, Crafty or Fruit.
This may not be directly answering your question (actually what is your question?), but you mentioned you wanted pointers to the right concepts.
oysteijo is right, one of the concepts that is very important is separating parts of a program from each other.
For something like chess there exist many efficient and elegant representations of the state of a chess game. I would say that the MVC (model, view, controller) design pattern works quite well for a chess game.
Hopefully this will make some sense, if not I suggest you read up on MVC some more.
Your model is going to primarily involve the datastructure which stores the representation of state of the game, this is the chessboard. A piece can only be on one of 64 spots, and there are limitations on the types of pieces and how many there are and what each of them do. The model will be responsible for dealing with this stuff. It would also make sense to give the model the logic for determining the legality of any given move (i.e. the properties of the game which don't necessarily involve the state of any given instance of a game).
The view is where all of your presentation related code goes. All that OpenGL is going in here, as would a "debug" routine which might (for instance) print an ASCII representation of the chessboard to the console.
The controller might have some functions which interface with the user to process input. The controller is the part of code which manipulates the model ("move E5 to D3": a function in your controller might call model.moveKnight('D3')) and the view ("draw the board in glorious 3D": the controller might do something like calling openGLView.draw(model))
One of the primary goals that MVC helps achieve is the independence of parts of code that perform different tasks. If some change in your AI causes problems with a rendering algorithm, it is a frustrating and difficult position to be in. An experienced programmer would go to some great lengths to ensure that this couldn't happen.
You might be wondering at this point where your AI code fits into the picture. Well, it's really up to you. Use your best judgement. It could be a part of the controller. Personally I'd have it be a whole nother controller (chessAIController) which implements the AI algorithms, but it is just as easy to have all of it contained within the main controller.
The point is, it doesn't really matter how you actually organize the code so long as it is done in some kind of logical way. The reason that MVC is so widespread is that those 3 components are usually present in most software and it usually makes sense to separate them. Note they're not actually really separated... the controller often directly manipulates both the view and model. Restrictions such as not allowing the view to manipulate anything helps code to stay clean and intelligible.
When you have no structure or organization in a programming project it can be nearly impossible to avoid having huge routines which do a little bit of everything because there is really only one place in the code in which to build functionality upon. What this generates invariably is a tangled mass of spaghetti code that no language, no matter how high-level, can save you from. This creates code that just plain sucks because nobody else can understand it, and even you will be unable to understand it two weeks from the time it is written.