jharwell / prism Goto Github PK

This is necessary so that the overal # of blocks available for robots to find in
the arena stays the same as blocks are placed onto the structure. The easiest
way to do this is to place a CLONE of the block onto the structure, giving it a
new unique ID in order to make debugging easier.

This avoids needing the arena map to maintain a pool of MORE blocks than are
actually available in the arena, and adding blocks to the pool whenever one is
removed due to block placement. This also should allow the redistribution
governor to work exactly the same as it does in FORDYCA.

Given my formulation of multiple construction lanes, I need to develop rigorous
invariants describing the set of structures possible to provably build in such a
way. One of the most important pieces of this is the frontier set, which is the
set of allowable blocks for a robot to place, given the current state of the
structure.

Some ideas of necessary properties of frontier set regarding eligibility:

• All lower layer support blocks must be present. For a cell which will contain
  a cube, this means the 9 lower layer blocks.

• At least 2 manhattan adjacent blocks must be present on the same level for a
  cell to be eligible for membership in the frontier set.p

• Every cell in set is "accessible", meaning it has empty square manhattan
  adjacent to it. Formally, all vertices in the subgraph of unoccupied cells in
  the set are manhattan connected to each other.

• A cell cannot be added to the frontier set if it would cause any non-member
  cell to only have a single manhattan connected neighbor, unless there are only
  2 unoccupied cells remaining on the structure.

Would be really awesome if the frontier set would be provably a matroid, so that
I could have robots choose the best block from it each time and be guaranteed a
near-optimal/optimal construction solution.

After the structure has been parsed and found valid, it should be further
scanned to see if ramps need to be added, and if so, they should be.

Ideas:

• After loading, go one layer at a time, bottom up, verifying that each block at
  each level is accessible.

• For each block adjacent to lower layer, which by definition has already been
  made available, verify it is accessible, and add blocks to make it that way it
  if is not.

Restriction: All protruding towers must be at least 2x1 (i.e. no single block
towers), in order to still have provable constructability via the frontier set.

Once I have parsed the graph structure from the input file, I need to validate
that the graph is valid (i.e, that it is provably constructable). There are two
types of validation that need to be performed:

• Spec validation. This only happens at the start of simulation, in order to
  verify that the parsed structure is actually constructible.

• Construction validation. This happens each block placement (or maybe each
  timestep?) to verify that none of the invariants/properies have been violated.

This are different checks of potentially different computational complexity,
though it it hard to know at this point HOW different, and whether or not this
will need to be one class or two.

Some properties to check:

• No holes in structure (topology might come in handy here in specifying when
  holes are allowable).

• Structure has an even # of columns (each pair forms at out and back path L to
  R that are the construction lanes for parallel construction).

• For cells containing cubes, the degree must be at least 5. If it is 5, then at
  least 1 neighbor must be a ramp.

• For cells containing ramps, the degree must be 5.

• Structure has 3 smooth faces; only the back side opposite the construction
  lanes entry/exit points can have irregularity in order for path algorithms to
  work.

By biasing robot allocation probability to a certain lane (say the middle), so
could control the shape of the generate structure, so that if you were trying to
build a ramp (for example), it would grow outward and upward from the center in
a much more "natural" way. This would result in much more imprecise and
therefore more biomimetic construction, and would be excellent for "time to
objective" scenarios where total structure completion is not necessary
(e.g. building a ramp or a bridge to somewhere).

Timothy pointed out that in many construction applications, having some sort of
scaffolding or elevator which the robots will be able to traverse to move
between levels of an in-progress structure is common. This is not something I've
ever seen in the literature, and so would be a novel research direction. It
would also mean that you would not need ramp blocks at all, and that structure
specifications would not require traversability checking.

Possible directions with this:

• How many simultaneous elevators available for use? i.e., will robots have to
  wait to go up or down?

• How long to transport between floors? Is it dependent on the distance?

Robots need to be able to drive up ramps. How steep of a ramp, and what settings
to use, etc, need to be verified before the project can move forward.

Needed for #15.

This would be a view/slice of the structure3D object (read only I think), which
robots could maintain a collection of as their imperfect representatin of the
structure, and would be used for allocation. Would be used by the
structure/structure builder to collect more precise metrics about construction
so I can get an idea about the effect of different lane allocation policies.

Before I can ever get to full 3D construction, robots need to be able to know
when they can/cannot place a ramp block on a given cell. Right now, the
preconditions are such that a ramp block can and will be placed anywhere a cube
block can, which is incorrect.

I would rather not rely on structure query to say "what should go here?", and
instead adopt a stygmergic approach where different states the robot discovers
the in-progress structure in will enable/disable certain placement behaviors.
However, this stygmergic approach will also not allow robots to create anything
other than smooth structures (i.e. no irregularities which can be handled by
topological constraints). This can be refined/expanded to maybe use structure
query as an option in the future, where robots know the full spec of the
structure they are building, and/or maintain a map of the in progress structure
as they discover it.

Stygmergically ramp blocks can only be placed:

• Level 0 if the are at the boundary of the ingress/egress face (robot's WILL
  have to know the orientation, bounding boxsize, and anchor point of the
  structure they are building)
• Higher levels if the robot encounters a smooth back face of the construction
  lane AND placing a ramp block in a given cell would result in a continuation
  of the smooth ramp at level Z - 1.

As part of this, I will need to handle:

• Robots picking up a ramp block, allocating a lane, only to find there is
  nowhere in that lane that the block can currently be placed. They will need to
  abort their placement via an event (which needs to be tracked via metrics so I
  can know how much work is being "wasted").

• Once all structures have been completed, All robots should be sent an event
  which tells them to stop moving and disables all their sensors/actuators so
  that the simulation will finish as fast as possible since nothing more
  interesting is going to happen.

• This should still probably be a switch in the XML input file though...

I need to come up with a data structure (probably some variant of boost::graph,
or based on stuff in there) in order to efficiently store and access the
in-progress representations of the structure by both robots and loop functions.
I might need to figure out a more minimal representation for robots, as if each
robot needs to keep the full data structure in memory, I am going to run out of
memory for large swarms trying to build large things.

• Max degree of each node is 9 + 9 + 8 = 26.
• Min degree of each node = 1.

This should already be supported by the loop functions/structures manager, but
I'm not sure if everything is 100% there yet. Besides implementation details,
the main research considerations are:

• How will robots allocate a target structure? Will they do that BEFORE they
  allocate a lane, or will they take BOTH the structure itself and its lanes
  into consideration? (e.g. a weighted sum).

• How will robots with/without memory fare with multiple independent targets (as
  distinct from interdependent targets which form composite structures)?

• Need an executable which will link with libsilicon, take the name of an ARGoS
  input file as an argument, and return/print if the structure(s) defined in the
  input file are valid.

• Also need a test suite (set of input files really, and maybe a python script
  to run the validator on each of them)which REALLY tests all the different
  imaginable cases/corner cases for the validator, in order to iron out bugs in
  it.

• Will help to refine necessary invariants for provable structure completion.

I think using voronoi diagrams to do smarter construction lane path planning
would allow for less rigorous paths that robots MUST follow for the algorithm to
work, and make it more robust to robot failures, sensor errors, etc.

Voronoi diagrams are crude, according to non-swarm roboticists, but I think they
will work just fine formy use case.

It is possible to use magnetic blocks in ARGoS (as in they are supported by the
simulator). The precise dynamics of how to drop blocks on top of other blocks in
order to ensure that they will stick together needs to be investigated. Ideally,
I would incorporate this into the building process, so that while robots might
not use actual physics when picking up blocks (for now), when the drop them, the
block which they are carrying (which is currently out of sight in the
simulation) will materialize over the drop zone in front of the robot and fall
into place, providing some level of realism.

Use a picture as the floor of the arena and modify my algorithm to build a wall
along a river (for example) the dimensions of which are totally unspecified, and
the result of stygmergy. This would be an EXCELLENT way to combine the rigorous
nature of my algorithm with more traditional SR heuristics. From Allwright2014.

This would probably be a precursor to #43.

There should be separate handlers (and therefore possible penalty
configurations) for block pickup and block place.

This would be an action class invoked by the loop functions intended for use in
initial SILICON bring up and debugging. It should take in a validated
structure3D object, and then invoke ARGoS AddEntity() as needed to actually
create the structure.

• Should have an option for a maximum # of blocks to place per timestep or
  something, so I can generate some nice time lapse videos of structures being
  built.

Construction in irregular environments would be VERY interesting in and of
itself, and also of interest to many organizations like DARPA, or SR companies
because then you are talking about more realistic outdoor environments where
problems to which SR systems would realistically be applied would live.

• Would require a (possibly) COSM feature to create the raised "floor" of the
  build area from an XML spec. This could be in COSM because having part of the
  arena be irregular is a general purpose idea not specific to construction.

Would enable my construction algorithm to handle:

• Gap filling on irregular but generally flat surfaces

• Turning an irregular block hill into a scalable ramp (under some constraints
  of course).

• Filling a valley.

In such cases, the structure can potentially just be specified by a bounding
box/shell, because the actual dimensions would be determined by the environment
in a stygmergic way.

From Allright2014.

Sometimes the robot picks the correct direction to traverse the arc around their
chosen construction target, but not all the time. This is probably a simple
trigonometric sign error in the ct_approach calculator.

My construction algorithm could be used to create a set of incident arches to
create a tunnel! The arches could effectively be ramps, so automated ramp
generation would not be required (helpful though).

Blocked by #29.

From Linsey2012.

Because you need to be able to allocate a construction lane immediately upon
block pickup (the other option being to wander around until you enter the
construction area, but that will lead to congestion and traffic regulation
nightmares), robots need a perception receptor so they can receive information
from the loop functions about construction target specs so they have this info
when they need it.

I think it is OK for robots to know the bounding box and anchor for all
structures that they are building in the environment.

Ideas on input specification:

• Probably XML, because that's what I use for everything else.

• Specify bounding box in XYZ, then specify each layer.

• For each layer, would want a shorthand in XML to say "X by Y
  rectangle". Otherwise, I would want a list of X,Y points comprising the layer
  or line segments in X or Y consisting of multiple points each, that comprise
  the layer.

Create a construction/building oracle, similar to the foraging one created for FORDYCA.

Where possible, I should switch to this because it makes the code more understandable, just as fast, and less prone to accidental int -> float or float-> int conversion.

OK with only 1 robot, but with multiple robots you need to keep the ones that
are exploring for blocks out of the nest, so they don't interfere with other
robots. Only an issue until the first level of blocks is created.

Could best be accomplished with a new exploration strategy which combines CRW
with polar force to push the robot away from a specified point (center of
nearest target).

Should be able to test/run construction experiments without foraging. The
FSM/controller for this will just be a subset of the FCRW-BST FSM. When a robot
leaves the structure and finishes the egress FSM, it should just signal that it
has done so and the arena gives it another block (magically).

Needed for #15.

Should take into account:

• Which lane is closest to where the robot is when it picks up a block.
• How recently the robot visited each of the construction lanes (use decaying
  pheromones for this I think).
• How complete each lane is.

Possible policies:

• greedy: Choose the lane which is the most complete/has been visited most
  recently (weighted combination), so you can be confident you will be able to
  complete your task.

• social_good: Choose the lane which is the least complete.

• round_robin: Choose each possible lane in sequence, regardless of how complete
  they are thought to be/how recently they were visited.

• explore: Choose the lane which you have visited least recently.

Basic temporal variance will be needed for block pickup/drop; will need to pull core into COSM so that it can be used here.

Needed for #15.

This would be a combination of the "Acquire free block/free block to nest" FSMs
from FORDYCA, which would have to be pulled into the foraging subtree of COSM,
and the builder FSM from #19.

Instead of having to pass the nest as a standalone XML tag, the location of the
nest should be set by where the structure is. That will make SIERRA simpler, as
well as making it easier to group several structures into under a single nest if
they are related/form a "composite" structure (that WOULD have to be specified
in the input file somehow).

I think it should be possible to mix and match 2D and 3D physics engines, as
long as they do not overlap, but this needs to be verified

Unsurprisingly, most of the gathered metrics (when they are non-zero, that is),
look to be totally incorrect, which is to be expected in an initial
implementation.

To be expected--this is just one of several bring-up bugs

Need to set up the XML parsing of all the different modules from COSM/FORDYCA
(pulling stuff into COSM as needed) that I think I'm going to need. Stuff like:

• non-ARGoS visualizations
• block exploration strategy
• Task allocation/task executive
• rng seed
• output/metric config
• block selection matrix (maybe? This might be FORDYCA specific...)
• sensing/actuation
• Forces
• Arena map (need to make sure caches configuration is optional)

Simplest example would be to create a ramp, then deconstruct it. A necessary
precursor to being able to create interesting structures that do not involve
ramps in their final state, but that which would require ramps for robots to be
able to build them.

Duh. This was my first attempt, so it is natural that it fails spectacularly.

Once I have a frontier set for a structure, I need to develop a set of traffic
laws that will allow the swarm to traverse the structure and add blocks to it in
a way that preserves the frontier set's validity and does not result in robot
deadlocks using construction lanes.

• Odd lanes of ramp in Y are entry, even are exit for each construction lane.

• If a robot is right behind one which drops a block such that it is no longer
  on frontier-adjacent set of cells, then the robot needs to update its frontier
  set and its chosen drop location. BUT, it proceeds along the old frontier
  adjacent set path until it reaches the new one, then switches to the new set
  AFTER block drop.

• When proceeding along the lane, when a robot reaches the frontier adjacent set
  with an opening in front of them, put a block there, Otherwise execute a U
  turn to the exit lane. If there is an opening on the set behind the robot,
  place the block there. Otherwise move forward 1 cell and place a block on the
  cell the robot just vacated.

Right now, after a structure has been completed, the block placement validator
still allows robots to place blocks on virtual cells, even though said cells
have no spec, and should return as invalid, if not result in a segfault.

I think this is an easy fix.

Each time a block is added, a node is added in a graph with edges to the
already placed blocks in the graph to which it shares a face. Will give some
idea of how the structure is being beyond the high level summary metrics I have
now. The graph should be output as a graphviz file (boost can do this I think)
so I can (eventually) make movies out of it!

From Bonabeau2000.

Create a construction/building oracle, similar to the foraging one created for FORDYCA.

• Need to pull in bits from FORDYCA from the CRW foraging controller into COSM
  as necessary so that I can put CRW foraging as the first half of the initial
  controller. CRW foraging does not require memory, so I don't have to deal with
  pulling all the DPO stuff out of FORDYCA yet if I do this (plus its a good
  baseline).

• Second half needs (1) a way to identify and allocate a construction lane, (2)
  a transition to the nest from where the block was picked up that gradually
  brings it into alignment with the chosen lane via path following force, (3)
  the actual FSM for traversing the construction lane and placing a block.

Right now only single lane is tested; this obviously needs to be expanded into
working with multiple lanes.

Instead of having to query the ramp and cube block maps EVERY time you want to
get the spec of a cell (which if robots ever need to do this will quickly become
a huge bottleneck for larger structures), a static (cell loc, spec) should be
built during structure initialization, and then just indexed into after
that. Will make debugging easier too I think.

Right now only pi=0 is tested/works. Construction should work with all 4
cardinal orientations, even if pi=0 is the most commonly used one, because
making it work with all 4 will undoubtedly flush out some subtle or
not-so-subtle bugs in my implementation.

This could take one of several forms (which could also be combined):

• Robots remember if their last block placement attempt was successful, and if
  it was not, go and get the OTHER type of block, or alternatively, adjust their
  priority for computing the probability for what type of block to pickup (still
  use random walk at this point).

• Robots track the in-progress structure independently, and only query the loop
  function "master" structure for the spec of a given cell (or maybe they each
  have a copy of the spec ?). This could be done at various levels of
  granularity, each level affecting the allocated construction lane.

• Robots change their color to indicate what lane/subset of lanes they just
  successfully placed a block on, and other robots record what they see, and use
  that to choose their lane (still use random walk to forage).

Needed for #15.

Once the robot enters the nest (construction area) this FSM would take
over. Assuming that the robot is aligned with the ingress lane for its chosen
construction lane, it would be responsible for:

• Driving the robot up the ramp until it reaches the top or the end of the ramp
  is reached.

• Once the end of the lane/ramp comes in sight, performing the block placement
  FSM in such a way as to guarantee no deadlocks between robots, waiting for
  robots ahead of them as necessary.

• Driving the robot down the structure/ramp and out of the construction zone.