mikevezina / massim2019 Goto Github PK

Currently, we use transitions between blocks to plan the sequence of requirements. For example, we iterate through all requirements and build a sequence based of whether or not the next block is immediately west, east, or south of the previous requirement.

Another alternative would be a different planning algorithm (I'm thinking GraphPLAN).

The only issue with using GraphPLAN is that it introduces overhead and is potentially too expressive for what we need.

Will look into this further.

We can detect unexplored areas of the map, even without knowing map boundaries, but using the knowledge that the map is rectangular. We can estimate bounds based on obstacle walls we have seen. Even if this estimate is incorrect, it at least pushes the agent into unexplored territory.

One of the main challenges with the simulation is that the perceptions of other teammates does not tell us which other teammate it is. For example, let's say we have three agents {A1, A2, A3} at locations (0,0), (0,1), and (0, 2) respectively.

Agent A1's perceptions for entities are as shown (for A2 and A3):
thing(0, 1, entity, "A") (only tells us the team of the entity, but we have no idea this is A2)
thing(0, 2, entity, "A")

A2's Percepts (the first is A1, the second is A3)
thing(0, -1, entity, "A")
thing(0, 1, entity, "A")

A2's Percepts (the first is A1, the second is A2)
thing(0, -2, entity, "A")
thing(0, -1, entity, "A")

Solution 1. There is one trivial solution, which is to ask all teammates if they have a thing perception with negative coordinates. i.e:
A1 asks team if anyone has thing(0, -2) (A3 will answer)
A2 asks team if anyone has thing(0, -1) (A3 answers, A2 and A3 can conclude that they see each other)

This doesn't work well if we have more than one pair of agents with the same relative X, Y components (in this case, all pairs of agents will register each other as the perception even if they are not in the range of perception). This is easily demonstrated with a team of 4 or more agents.

Solution 2. The second proposed solution would be to take a "signature" of perceptions that are seen by each perceived agent. For example, if Agent 1 and 2 perceive each other, they calculate a signature of all terrain and things within their shared perception range. They can use this signature to verify each other.

We must use the following assumptions:

1. Two agents can not occupy the same space (satisfied by simulation limitations)
2. There must be at least 2 terrain spaces or things used within the signature.

If Assumption 2 doesn't hold, it is still likely that we encounter the same issue as proposed solution 1. For example, consider two pairs of agents outside of each others perceptions and that both pairs shared perception range consist of only empty spaces or one terrain block placed in the same relative location. This would result in generating the same signature. We want to have a minimum of two terrain or entities to decrease signatures clashing.

Solution 3: During the first few steps of the simulation, we can establish authentication between two agents by associating a unique block to each agent.

For example, let's say the server utilizes two types of blocks: {b0, b1} but have 4 (or less/more) agents that we need to authenticate. Since there are two unique blocks (b0 and b1), we can tell each agent to attach to the block. I.e. tell agent A1 to attach to block b0 and A2 to attach to b1.

Any teammates that perceive these agents can authenticate A1 and A2 based on the blocks that will also be perceived. Once these two agents have been authenticated by the rest of the team, we then assign the blocks to the next two agents. This is more time consuming than the previous methods and could potentially be a waste of simulation steps (if the agents spend too much time looking for blocks to attach or waiting for all team agents to authenticate).

Once we have authentication:
Once a pair of agents are authenticated, they can permanently keep track of each others positions even while they escape immediate perception. This allows us to communicate dispenser locations, etc. between agents. The main point of authentication is to properly identify each teammate so that the locations can be shared between each agent.

Another thing to note: once one (or more) pairs of agents are authenticated with each other, we can communicate this to any agents that are authenticated in the future.
An example:
A1 authenticates A2.
A2 leaves perception of 1.
A1 authenticates A3.
A1 can extend A2's authentication to A3, so that A2 and A3 can authenticate each other without being in each others perception. This is done by sharing A2's absolute position once A3 is authenticated.

Final Note: Once we have authentication between two or more agents, it becomes possible to coordinate movements, provide navigation between agents, communicate object positions, etc. This allows us to perform some of the higher-level functionalities, but without proper agent authentication, each agent is basically limited to it's own mental notes and perceptions (which won't get them very far).

The agents can see all attached blocks in its perception (even if the block is attached to another agent). This means that we can't rely on the "attached" perception to tell us which blocks are/aren't ours.

I.e. if we have two blocks attached at (0,1) and (1,1), and agent A3 located at (3,1) has one block attached at (2,1), the attached perceptions are:
attached(0,1)
attached(1,1)
attached(2,1).

We need to keep track of which blocks are attached upon success of the attach or connect command.

• Detect and avoid clear events
• Detect agent disabled

Agent aligns and requests block from dispenser even if the desired block is already attached

The attach perceptions provided by the simulation are not reliable (we can perceive other nearby agent attachments, and we might interpret these as our own attachments).

If we pay attention to which blocks we explicitly attach and detach, and share this knowledge with other agents, this might improve this.

Note that when agents connect two blocks, they get dragged around with each other. We need to detach an agent before we start moving.

One way of selecting the best task can be done by utilizing internal actions. This way we don't have to filter tasks and requirements in AgentSpeak.

Use Jason to invoke action handling, rather than percept filtering.

Should probably create a separate issue for each of these, but I just needed to do a quick mind dump. Here are a few edge cases I still need to consider, and some additional notes:

1. Being spawned/placed in a box (no exits)

• Need to use clear action, or wait for a clear event to occur (although the former should be done, and not the latter).

2. Being disabled (by a clear event, or other agent)

3. Evade clear events within the radius of an agent (unless it is that agent's clear event)

4. Better path navigation. I think the best way to do this is have some kind of localized steering/navigation that is done within Jason, and use a long-term (or bigger scale) navigation system implemented in Java (A*, etc.).

5. Larger patterns, if an agent is the one receiving the block (aka the one holding the pattern), they should be the one responsible for making sure the next block location isn't blocked.

6. Better task selection. Look at which dispensers are closest,

7. If enemy agent is blocking location (aka dispenser), maybe "poke" them with a clear action so that they can move for us ;)

8. Better exploration. I was thinking maybe trying to detect map borders using detected obstacles.

Wouldn't this be great to have implemented by the time the contest comes around? I think it's feasible but there is other stuff that needs to be completed first.

The agent must be able to strategize about how it creates the complex block patterns. When strategizing, we must take into account the following:

1. Attached blocks can not move to cells with block dispensers. For example, if we have an attached block at relative position (0,1) and a block dispenser at (1,1), we can not move east. In contrast, the agent is free to reside on a cell with a block dispenser.

2. We can only attach blocks to our self, we cannot attach a free block to a block that has already been attached to us. As of right now, I think this means we technically can't create patterns with a single agent if it requires more than one block.

As the code base grows, it's becoming increasingly difficult to trace which components are causing issues. There needs to be some investment of time and effort into Jason testing for plans and rules.

Currently, we use Dijkstra shortest path for navigation. This works well for just the agent on its own.
As soon as we have multiple attachments that can be rotated and that block the agents navigation, Dijkstra does not work as well. Currently, if we can not navigate the dijkstra shortest path, we attempt rotations until our attachments do not block us anymore. This is not always feasible and we need a better solution.