Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

scribble

  • Loading branch information...
commit ba940d6edb8e4199c2865ab7c443ae27dffe8766 1 parent 1b21fc2
@marekdusio marekdusio authored
View
68 report/problemanalysis.tex
@@ -0,0 +1,68 @@
+p1.some actions/plans are conflicting if they use the same resources at the same time
+
+p2.doing some actions/plans can prevent other actions/plans from being successful if carried out in wrong order
+
+p3.reaching a specific resource may require moving several other boxes "out of the way" or asking other agents to move away
+-----picture of HANOI
+
+p4.there are cases where a single agent cannot solve the above mentioned problems alone
+
+challenge
+-find a solution
+-find an optimal solution
+-find the solution in a short time
+
+hence we have 2 solutions - forward planning and reverse planning
+why forward planning
+-we expect a backwards planner to be able to solve these problems
+-we were interested in how good a forward planner can be in this task
+-we want the forward planner to have limited capabilities of looking ahead
+---we want to only compute a certain amount of steps which take us closer to achieving a goal
+---we expect this to be less costly than computing everything at once
+-forward planning can decompose the problem of solving all goals to small problems-per-goal
+-we expect it to have a problem with ordering goals properly
+-we expect it to be fast in problems where ordering is not that important
+-we expect A* to be sufficient. and since we chose not to work on POMA levels, there are no pros of choosing D* for FOSA and FOMA solving.
+-forward planning for more than one agent can decompose the problem of solving all goals of all actors to per-actor planning
+---with a limited lookahead we only plan 2-3 things ahead and it is easy to compute the plan (A* called a few times)
+---computing more goals at once could increase optimality of the plan but will take longer and be more complex to compute and it may introduce more conflicts in a FOMA environment
+-forward planning is expected to do poorly in cases where goal sorting is important
+-we do not expect forward planning to produce optimal results
+-we do not expect forward planning to be smart about both box and goal selection order
+
+
+FOMA
+-we want actors to work together
+---agree on goals/boxes they solve
+---agree on paths they use
+-we expect a stripped version of the communication specification protocol to be sufficient for this approach
+-we see problems with this approach
+---requests that can conflict with each other
+------we expect to break the conflicts using an external solver
+---overhead when we lock too long paths
+------we suspect it is not a major issue that would prevent us from solving the map
+------we expect to pay extra actions for this (overhead)
+
+Heuristics
+-we assume that a good enough heuristic will be choosing the closest box for a given goal to solve
+-we assume that a good enough heuristic will be not-considering unreachable boxes to be
+-for problem3. the heuristic of choosing the goal position for blocking box
+---moving the blocking box to the first available free position is problematic
+------example of this (hanoi with A blocking)
+---given what we have seen we expect 'moving the box away' to the furthest available position to be easy to compute, not produce problems, not be always optimal
+
+
+we expect that partial ordering of goals would mitigate some of the ordering issues in forward planning
+in order to deal with some of the cons of our approach, we use partial ordering of desires
+-we want to partially order goals to mitigate the issues with forward planning choice of goals
+
+we expect to compute partial orders of tasks by analysis of structure of the map
+-we expect to improve forward planning by introducing ordering
+---we expect to be able to decide on the order of two goals when two are in a narrow coridor with a dead end
+------example of a narrow corridor with a dead end
+-we expect not to be able to resolve all of our ordering issues
+-we expect not to be able to order all of the tasks
+-we expect to be able to compute it only once - and be rigid
+-we expect this to be cheap to compute
+
+%generally build up to a conclusion why we pick things we did pick and why it was a good choice
View
24 report/results.tex
@@ -0,0 +1,24 @@
+%things we anticipated that should go well but did not
+-we underestimated the problem of moving boxes out of the way
+-we underestimated the problems of simplifying the foma communication protocol
+-we overestimated the power of our simplifications
+
+%things that went as we expected them to go
+-partial ordering solved some of the problems but not as many as we hoped, it needs further work to be as good as expected
+-claiming resources worked as expected hence rendered complete protocol not to be necessary
+-we're not good at putting boxes at goals in appropriate order where levels have a common pattern of group-of-close goals
+
+%things that went better then expected
+-heuristic of choosing the goal position for blocking box and 'moving the box away' to the furthest available position
+---the results for competition levels were better than expected in case of the common 'hanoi' pattern
+
+%other results
+-our results were biased for the competition levels
+---we have tried to mitigate this bias by deliberately creating maps where the planner would be sub-optimal
+-we have some problems to solve certain FOMA maps where agents fail to request help from other agents
+-we have recignized some issues with FOMA since multi-body resolving is not working flawlessly yet
+-due to unidentified bug of the planner, we may end in a situation where we ignore the partial ordering of the goals
+
+
+
+
View
45 report/solution.tex
@@ -0,0 +1,45 @@
+forward planning
+
+
+why bdi
+-bdi facilitates distinction between own goals and other agents' requests
+-facilitate FOMA communication
+-to keep track of the reason why we are doing a certain plan (there is an intention)
+BDI differences
+-only goals as desires
+-we use priorities for desires to make the agent choose different goals if plans for certain goals are impossible to find
+
+
+FOMA (solution-wise)
+-we use stripped version of the communication specification presented during the lectures (our requests)
+ +we anticipated a small subset of this protocol would be sufficient
+ +a full protocol is not necessary for solving problems in this domain
+ -we have identified several issues using this setup/approach
+__/ Requests for Conflicting intentions: how we are able to resolve agent conflicting intentions by using requests
+ \ Requests for Satisfying requirements of a plan (freeing area of boxes for another agent to be able to solve his goal)
+ +limited number of agents involved in a conflict (an actor will only request blocking actors to move away of positions, not all actors on a map)
+ -not necessarily optimal
+ -two requests may conflict (as described below)
+---Meta communication: how we resolve two conflicting requests
+ +simplification of the protocol, instead of conflict resilving through agreement we use a "higher body" to decide for the agents
+ -not necessarily optimal
+---Multi body: how we solve action conflicts where intention and request conflicts cannot be resolved - a minor piece of multibody planning
+ +cheap solution for a minor problem (fairly cheap for 4 steps ahead)
+ -does not scale
+---Claims: claiming goals and boxes, reserving map nodes
+ +simplification of the protocol, solves the problem of two agents wanting to solve the same thing, skips the "agreement" - first agent to claim wins
+ -not necessarily optimal
+ -reserving map nodes may block other agents
+ +reserving map nodes simplifies forward planning when an actor knows it can or cannot go through
+
+
+partial ordering of desires
+
+
+map classification:
+-(breadth-first search three times, walk the areas, neighbour checking), in the order of 5 breadth-first searches
+-how we use this to create partial orders
+
+
+pros and cons
+
Please sign in to comment.
Something went wrong with that request. Please try again.