I'd like to learn more about Timed Automata to verify real-time systems. Currently, I'm trying to get myself familiar with a tool called UPPAAL.
I drew some simple graphs and added different properties. The entire model is supposed to represent a production cell system where different mechanical units pass a block to each other.
I've modelled the block (BlockCycle), 2 mechanical units (Feeder, FeederBelt) and 2 sensors which sense the arrival of the block.
Even though I thought my system would make sense, it gets deadlocked:
The target states of this transition violate the invariants. This is not a problem, as long as you intended your model to behave like this.
(No I didn't. ;P)
I can't seem to find the reason for the deadlock, though. The tool points me to the BlockCycle model but I didn't specify any invariant there. In fact, all the transition requirements are fulfilled so the transition (from Pos7 to Pos8) should definitely be taken.
Below you'll see how the systems evolves and finally gets stuck (error message pops up).
Labels:
green : property check (e.g. FB_Running means FB_Running == true )
dark blue: property updates/assignments
dark red: locations (e.g. Pos7 or Pos8)
The BlockCycle model with the respective transition in question:
My Question: Why does the system deadlock even though there are still transaction which could be taken.
Edit1: When I remove the invariant property of Sensor7's location Active (called BlockAtPos[7]) the deadlock is resolved. So I guess, since there is no synchronization between Sensor7 and BlockCycle for the last transition before it deadlocks, that would cause to a contradiction (BlockAtPos[7] becoming false while the sensor has not yet the chance to take the InActive transition) and thus violating the invariant.
Note: You can find my UPPAAL code/file here: pcs.xml.
Related
What is the difference between active and passive constraints in the ECLiPSe CLP language? And how/when can I use one or the other?
The distinction refers to the way the constraints are used during execution. Active constraints (may) directly affect the variables present in them, whereas passive constraints will not. Consider a small, trivial example of both structures:
% Active
f(a,X) = f(Y,b)
% Passive
2*X < 3*Y+2
In the first example, when either X or Y becomes instantiated, the 'constraint' can trigger and immediately evaluate (and if valid, unify) both sides = active behaviour.
In the second example on the other hand, both sides are dependent on each other and thus it doesn't matter whether X or Y becomes instantiated first, the evaluation will have to be delayed until both sides' variables are instantiated = passive behaviour.
(Note that I tried to answer without using any constraint/language-specific syntax, since the concept of active/passive constraints can generically be applied to all constraint logic based systems. Also note that some languages like ECLiPSe provide global constraints reasoning over finite integer domains and may actually make some behaviour active/passive to our needs. However, being outside the scope of this question, no further behaviour is considered to keep things simple.)
Hope this helps!
So I've been messing around with Project Tango, and noticed that if I turn on a motion tracking app, and leave the device on a table(blocking all cameras), the motion tracking goes off in crazy directions and makes incredibly wrong predictions on where I'm going (I'm not even moving, but the device thinks I'm going 10 meters to the right). I'm wondering if their is some exception that can be thrown or some warning or api call I can call to stop this from happening.
if you block all the camera, there is not features camera can capture.
so motion tracking may be in two stages:
1. No moving,
2. drifting to Hawaii.
either ways may happen.
If you did block the fisheye camera, yes, this is expected.
For API, There is a way to handle it.
Please check life cycle for motiontracking concept
For example for C/C++ :
https://developers.google.com/project-tango/apis/c/c-motion-tracking
if API detected pose_data as TANGO_POSE_INVALID, the motion tracking system can be reinitialized in two ways. If config_enable_auto_recovery was set to true, the system will immediately enter the TANGO_POSE_INITIALIZING state. It will use the last valid pose as the starting point after recovery. If config_enable_auto_recovery was set to false, the system will essentially pause and always return poses as TANGO_POSE_INVALID until TangoService_resetMotionTracking() is called. Unlike auto recovery, this will also reset the starting point after recovery back to the origin.
Also you can add Handling Adverse Situations with UX-Framework to your app.
check the link:
https://developers.google.com/project-tango/ux/ux-framework-exceptions
The last solution is by write the function handle driftting by measuring velocity of pose_data and call TangoService_resetMotionTracking() and so on.
I run a filter on the intake that tries not to let obviously ridiculous pose changes through, and I believe no reported points whose texel is white nor any pose where the entire texture is in near shouting distance of black
I'm working on a game (using Game Maker: Studio Professional v1.99.355) that needs to have both user-modifiable level geometry and AI pathfinding based on platformer physics. Because of this, I need a way to dynamically figure out which platforms can be reached from which other platforms in order to build a node graph I can feed to A*.
My current approach is, more or less, this:
For each platform consider each other platform in the level.
For each of those platforms, if it is obviously unreachable (due to being higher than the maximum jump height, for example) do not form a link and move on to next platform.
If a link seems possible, place an ai_character instance on the starting platform and (within the current step event) simulate a jump attempt.
3.a Repeat this jump attempt for each possible starting position on the starting platform.
If this attempt is successful, record the data necessary to replicate it in real time and move on to the next platform.
If not, do not form a link.
Repeat for all platforms.
This approach works, more or less, and produces a link structure that when visualised looks like this:
linked platforms (Hyperlink because no rep.)
In this example the mostly-concealed pink ghost in the lower right corner is trying to reach the black and white box. The light blue rectangles are just there to highlight where recognised platforms are, the actual platforms are the rows of grey boxes. Link lines are green at the origin and red at the destination.
The huge, glaring problem with this approach is that for a level of only 17 platforms (as shown above) it takes over a second to generate the node graph. The reason for this is obvious, the yellow text in the screen centre shows us how long it took to build the graph: over 24,000(!) simulated frames, each with attendant collision checks against every block - I literally just run the character's step event in a while loop so everything it would normally do to handle platformer movement in a frame it now does 24,000 times.
This is, clearly, unacceptable. If it scales this badly at a mere 17 platforms then it'll be a joke at the hundreds I need to support. Heck, at this geometric time cost it might take years.
In an effort to speed things up, I've focused on the other important debugging number, the tests counter: 239. If I simply tried every possible combination of starting and destination platforms, I would need to run 17 * 16 = 272 tests. By figuring out various ways to predict whether a jump is impossible I have managed to lower the number of expensive tests run by a whopping 33 (12%!). However the more exceptions and special cases I add to the code the more convinced I am that the actual problem is in the jump simulation code, which brings me at long last to my question:
How would you determine, with complete reliability, whether it is possible for a character to jump from one platform to another, preferably without needing to simulate the whole jump?
My specific platform physics:
Jumps are fixed height, unless you hit a ceiling.
Horizontal movement has no acceleration or inertia.
Horizontal air control is allowed.
Further info:
I found this video, which describes a similar problem but which doesn't provide a good solution. This is literally the only resource I've found.
You could limit the amount of comparisons by only comparing nearby platforms. I would probably only check the horizontal distance between platforms, and if it is wider than the longest jump possible, then don't bother checking for a link between those two. But you might have done this since you checked for the max height of a jump.
I glanced at the video and it gave me an idea. Instead of looking at all platforms to find which jumps are impossible, what if you did the opposite? Try placing an AI character on all platforms and see which other platforms they can reach. That's certainly easier to implement if your enemies can't change direction in midair though. Oh well, brainstorming is the key to finding something.
Several ideas you could try out:
Limit the amount of comparisons you need to make by using a spatial data structure, like a quad tree. This would allow you to severely limit how many platforms you're even trying to check. This is mostly the same as what you're currently doing, but a bit more generic.
Try to pre-compute some jump trajectories ahead of time. This will not catch all use cases that you have - as you allow for full horizontal control - but might allow you to catch some common cases more quickly
Consider some kind of walkability grid instead of a link generation scheme. When geometry is modified, compute which parts of the level are walkable and which are not, with some resolution (something similar to the dimensions of your agent might be good starting point). You could also filter them with a height, so that grid tiles that are higher than your jump height, and you can't drop from a higher place on to them, are marked as unwalkable. Then, when you compute your pathfinding, as part of your pathfinding step you can compute when you start a jump, if a path is actually executable ('start a jump, I can go vertically no more than 5 tiles, and after the peak of the jump, i always fall down vertically with some speed).
I want to model an HTTP interaction, i.e. a sequence of HTTPRequest/HTTPResponse, and I am trying to model this as a transition system.
I defined an ordering on a class State by using:
open util/ordering[State]
where a State is simply a set of Messages:
sig State {
msgSet: set Message
}
Each pair of (HTTPRequest->HTTPResponse) and (HTTPResponse->HTTPRequest) is represented as a rule in my transition system.
The rules are expressed in Alloy as predicates that let one move from one state to another.
E.g., this is a rule generating an HTTPResponse after a particular HTTPRequest is received:
pred rsp1 [s, s': State] {
one msg: Request, msg':Response | (
// Preconditions (previous Request)
msg.method=get &&
msg.address.url=sample_com &&
// Postconditions (next Response)
msg'.status=OK_200 &&
// previous Request has to be in previous state
msg in s.msgSet &&
// Response generated is added to next state
s'.msgSet = s.msgSet + msg'
}
Unfortunately, the model created seems to be too complex: we have a dozen of rules (more complex than the one above but following the same pattern) and the execution is very slow.
EDIT: In particular, the CNF generation is extremely slow, while the solving takes a reasonable amount of time.
Do you have any suggestion on how to model a similar transition system?
Thank you very much!
This is a model with an impressive level of detail; thank you for sharing it!
None of the various forms of honestAction by itself takes more than two or three minutes to find an instance (or in some cases to fail to find any instance), except for rsp8, which takes quite a while by itself (it ran for fifteen minutes or so before I stopped it).
So the long CNF preparation times you are observing are apparently caused by either (a) just predicate rsp8 that's causing your time issues, or (b) the size of the disjunction in the honestAction predicate, or (c) both.
I suspect but have not proved that the time issue is caused by combinatorial explosion in the number of individuals required to populate a model and the number of constraints in the model.
My first instinct (it's not more than that) would be to cut back on the level of detail in the model, in particular the large number of singleton signatures which instantiate your abstract signatures. These seem (I could be wrong) to be present either for bookkeeping purposes (so you can identify which rule licenses the transition from one state to another), or because the modeler doesn't trust Alloy to generate concrete instances of signatures like UserName, Password, Code, etc.
As the model now is, it looks as if you're doing a lot of work to define all the individuals involved in a particular example, instead of defining constraints and letting Alloy do the work of finding examples. (Using Alloy to check the properties a particular concrete example can be useful, but there are other ways to do that.)
Since so many of the concrete signatures in the model are constrained to singleton cardinality, I don't actually know that defining them makes the task of finding models more complex; for all I know, it makes it simpler. But my instinct is to think that it would be more useful to know (as well as possibly easier for Alloy to establish) that state transitions have a particular property in general, no matter what hosts, users, and URIs are involved, than to know that property rsp1 applies in all the cases where the host is named examplecom and the address URI is example_url_https and whatnot.
I conjecture that reducing the number of individuals whose existence and properties are prescribed, and the constraints on which individuals can be involved in which state transitions, will reduce the CNF generation time.
If your long-term goal is to test long sequences of state transitions to test whether from a given starting point it's possible or impossible to arrive at a particular state (or kind of state), you may need to re-think the approach to enable shorter sequences of state transitions to do the job.
A second conjecture would involve less restructuring of the model. For reasons I don't think I understand fully, sometimes quantification with one seems to hurt rather than help performance, as in this example, where explicitly quantifying some variables with some instead of one turned out to make a problem tractable instead of intractable.
That question involves quantification in a predicate, not in the model overall, and the quantification with one wasn't intended in the first place, so it may not be relevant here. But we can test the effect of the one keyword on this model in a simple way: I commented out everything in honestAction except rsp8 and ran the predicate first != last in a scope of 8, once with most of the occurrences of one commented out and once with those keywords intact. With the one keywords commented out, the Analyser ran the problem in 24 seconds or so; with the one keywords in place, it ran for 500 seconds so far before I decided the point was made and terminated it.
So I'd try removing the keyword one from all of the signatures with instance-specific individuals, leaving it only on get, post, OK_200, etc., and appData. I would also try doing without the various subtypes of Key, SessionID, URL, Host, UserName, and Password, or at least constraining their cardinality in the run command.
We have a flex app that will typically run for long periods of time (could be days or weeks). When I came in this morning I noticed that the app had stopped running and a white exclamation point in a gray circle was in the center of the app. I found a post about it on the Adobe forums, but no one seems to know exactly what the symbol means so I thought I'd reach out to the SO community.
Adobe forum post: http://forums.adobe.com/message/3087523
Screen shot of the symbol:
Any ideas?
Here's an answer in the post you linked to from an Adobe employee:
The error you are seeing is the new
out of memory notification. It is
basically shielding the user when
memory usage gets near the system
resource cap. The best course of
action here (if you own the content)
is to check your application for high
memory usage and correct the errors.
If you don't own the content, it would
probably be best to contact the owners
and make them aware of the issue you
are seeing.
He also says this in a later response:
Developers can use the
System.totalMemory property in AS3 to
monitor the memory usage that the
Flash Player is taking up. This iwll
allow you to see how much memory is
used, where leaks are and allow you to
optimize your content based on this
property.
I work for a digital signage company and we have also came across this error, however, it is not only memory leak related because it can be caused by utilizing the vector code on that page provided. We have also noted that it occurs without any kind of memory spike whatsoever, and sometimes appears randomly. However we noticed that when we replicated the bug with the vector error, it was saying it was an out of memory error - which clearly was not the case.
In our internal tests we noted that this bug only occurs with flash player 10.1 and up, flash player 10 does not seem to have this issue. Further, there seems to be a weak connection between the error occurring and the use of video. I know this might not be too much help, but just thought you should know it is not only a memory leak related issue. I have submitted this bug to Adobe, and hopefully they resolve it soon.
This can occur when using a Vector.int which is initialized using an array of a single, negative int. Because of the way you initialize the vector class with code such as:
Vector.int([-2])
The -2 gets passed to the vector class as it's initial length like Array(5) would be. This causes an error somehow (and is not checked and raised as an exception).
I have also noted the issue repeating when passing negative values to length of a Vector.
A possible explanation would be that the vector tries to allocate the length its been given immediately.
Since the negative value is being forced into a uint, the negative value autumatically translates to a very large positive value. this causes the Vector to attempt allocation of too much memory (about 4GB) and hence the immediate crash.
if you pass a negative value to the length of an Array nothing happens, because apparently it does not attempt to allocate the length. but you can inspect the value and see that it is a very large positive number.
This explanattion is pure conjecture, I did not hear it anywhere. but it is consistent with as semantics and the meaning of the exclamation mark.
This said, I have search our entire code base for the use of the setter "length" and could not find it used with a Vector. Still, we are experiencing very often crashes of this sort - some of them are caused by actual high memory consumption (probably leaks) but other times it just happens when the memory is relatively low.
I cannot explain it. perhaps there are other operations that can potentially lead to allocation of large amounts of memory other the the setter "lenght"?