Progress Review 11

Fleet size: 5 robots!!

Perception

  • Perception subsystem is now integrated with rest of system
    • Increased resolution 
    • Cameras need to be focused and calibrated after every run
  • Was having issues running two templates on the Kheperas: turns out we had to update the Khepera libraries
  • Tested in real life, able to detect and report agent position

MRSLAM

  • Better speed profile for each robot: linear speed increase instead of step function
  • Laser Scanner non-blocking read update
  • Tuning loop closures
  • Ignore out-of-order data sequences from agents
  • Erroneous scans from a robot getting added to the map
    • Out of order sequences
    • Sensor data is suspect
  • Sensitivity of loop closures varies with features in the environment

Navigation

  • Lazy Traffic Controller repulsion
    • Was still having issues of agents colliding into each other during IRL testing (likely due to latencies and localization inaccuracies)
    • Added additional repulsion force to original velocity obstacle output velocity commands
    • Should help with agent-agent collisions
  • Perception Search behaviour
    • Turn in place + pause at coverage tasks

Task Generation

  • Two problems:
    • A single random tree gets heavily pruned as the map changes
    • Cannot keep a track of which rooms are visited which rooms aren’t if the tree keeps changing
  • Problem breakdown:
    • Can the tree transform along with the map?
    • Can we grow multiple trees instead of one single tree?
    • Can we disable trees instead of pruning them?
  • Solution:
    • Divide and conquer:
      • grow multiple RRTs, one per pose-graph node
      • This way the RRTs will be smaller and can be optimized along with pose-graph updates
      • Avoid pruning
    • Survival of the fittest:
      • Generate coverage tasks on the RRTs, maximizing coverage while minimizing # of tasks needed
      • Iterate through each RRT and filter out nodes that are within a radius of an already established coverage task
      • Intertree filter then filters out overlapping coverage tasks between different trees
      • Final coverage tasks are then returned
      • Once a coverage task is visited, it is no longer updated and cannot be changed.

Rest/API

Rest/API

Task Allocation

  • Geofence based on estimate of search area
  • Task allocation now has two types of tasks, what is their relative importance? 
    • Coverage Tasks
    • Frontier Tasks
  • Do two coverage tasks have same importance?
  • Do two frontier tasks always have same importance?
  • The Naive task allocator treats all the tasks the same only based on distance

FVD Sneak Peek:

  • An information theoretic approach to allocating tasks during search and rescue
  • What is the information utility of each frontier task? Of each coverage task? How do they compare with each other?
  • Can we exploit information utility to speed up search for victims in a search and rescue scenario?