Infrastructure and Construction Robot Swarm

A self-organizing and directing robotic swarm for autonomous or teleoperated construction, inspection, and maintenance

Similar projects worth following
Infrastructure and construction robots are a group of modular robotic agents that can work cooperatively to automate various tasks such as construction, inspection, and repair. Each robot is capable of multiple functions, as capacities can be modified through the installation of different attachments on the unit. Each base unit is designed to be low cost to minimize the time and monetary investment and protect against significant losses due to the failure of a single robot. A group of robots can be teleoperated to increase the efficiency of skilled operators or can be given basic directives to automate simple or repetitive tasks.

Problem A: Infrastructure

  • U.S. infrastructure is currently rated as subpar and is continuously degrading (Graded D+ by ASCE)
  • Part of the issue lies in the extreme costs of repairs necessary across the nation (estimated $4.59 billion by 2025 to fix)
  • This massive increase in spending would cause a drag on the economy ($3.9 trillion GDP loss by 2025)
  • Too many problems, too expensive, takes too long

Problem B: Disaster Relief Management

  • Disasters are difficult to recover from and each disaster has unique requirements and problems that need to be addressed
  • Disasters are inherently unpredictable and so disaster preparation would require addressing all possible problems before it occurs, a prospect that can be prohibitively expensive
  • It’s also expensive to be reactionary and ship required relief materials for every disaster only after the disaster has occurred
  • Loss of life is worse immediately following the disaster before the relief supplies can make it to their destination
  • Massive, repeated shipments can be problematic due to bureaucratic and logistical delays

Problem C: Construction and Landscaping

  • Building homes and structures is expensive and time consuming
  • Machines for construction are expensive and have high specialization sometimes requiring many different machines for a single project
  • Cheaper, mass produced materials result in low levels of customization and customer satisfaction also requiring expensive shipment to the destination
  • Heavy earth moving machinery is often needed for landscaping projects which can be expensive or difficult to acquire
  • Using heavy machinery can be difficult and requires additional skills; alternatively hiring professionals only makes the work more expensive

Problem D: Non-Terrestrial Construction

  • Sending up satellites is limiting in both space and weight
  • After the heavy costs associated with initial construction, there are currently no options for repairs in the case of damage
  • Space junk is a problem without a good method of deorbiting debris
  • Expensive and restrictive to need to send all materials to construct a habitat on another planet
  • Materials to build habitats exist on planets but no machines currently capable of utilizing them or constructing habitats


  • Teleoperated robots!
  • Remote operated requiring skilled workers or semi-autonomous task completion
  • Perform checking and eventually construction that’s more cost effective
  • Makes workers more efficient and amplifies their capabilities
  • Increase in safety with cheap, expendable robots performing dangerous work
  • Flexible function using modular attachments means each robot is capable of many different actions
  • Small size means robots can work concurrently in the same location, reducing multiple phases of a project into a single, incremental step
  • Swarm methodology for a group of robots means tasks can be accomplished much quicker
  • A combination of a large swarm and the modularity means specific tasks can be dynamically allocated due to shifting requirements


Tier 1

  1. Robot with modular attachments that enable it to serve various functions
  2. Cheap base model that can be produced in quantity and has basic motion, communication, and sensor capabilities
  3. Assignable roles so that broken robots can easily be replaced by spare units or units can be re-assigned based on need
  4. Teleoperation with visual data so that users can get direct feedback about the status of the project’s target
  5. Limited physical intervention required by users
  6. Ability to direct movement and basics tasks to be performed by the robots

Tier 2

  1. Modular attachments can be swapped autonomously
  2. Dynamic role allocation so that the robots automatically determine the best distribution to get a task done efficiently
  3. Coordinated motion so the robots can be given simple direction to accomplish group behavior

Tier 3

  1. Machine learning can automatically flag problematic inspection data
  2. Augmented reality data so that the users can see the project target and the current progress side by side
  3. Advanced autonomy with the...
Read more »

  • Robot Localization

    Keith Elliott04/14/2018 at 21:26 0 comments

      One of the biggest problems with precise motion in robotics is localization. Encoders are only so accurate and tend to drift over time. Absolute positioning systems like GPS have error margins measured in meters. The solutions to this is often complicated (e.g. SLAM) or expensive (e.g. RTK GPS). As a cheap and simple alternative to this, I'm going to attempt to use incremental trilateration to enable the robots to determine their own position relative to their siblings.

      Why It's Important

      An accurate map of where the robots are is critical for proper planning of their movements. Without it they could get in each other's way or fall off of a cliff! It's also necessary for them to perform tasks that require precise motion such as moving debris or laying brick. While the robots will also be teleoperated and have an onboard camera, it's hard for the human eye to properly determine depth and estimate measurements from a 2D image.

      The most common method for robot positioning is using encoders to measure the distance the wheels have traveled by counting rotations. There are some caveats to this method, however. If a wheel slips the encoder's accuracy will suffer and it will think it's traveled farther than it has. Over time the encoder's measurement will drift farther and farther from reality. This problem will only be exacerbated by the rough and slippery terrain that these robots will eventually be operating on. However, with incremental trilateration the robot will recalculate an absolute position every time it moves. This absolute measurement won't be susceptible to location drift.

      Incremental Trilateration

      The method I'm proposing for robot localization is based on trilateration, which is the same method GPS satellites use to determine position. This method, however, will be able to attain greater accuracy with cheaper and less complex hardware. Rather than the speed-of-light radio signals that GPS satellites use for trilateration, I plan on using much slower sound waves to do the same calculations. This makes it possible to do signal detection and calculation with a relatively slow microcontroller instead of high speed DSPs and custom silicon. I also plan on having an IR blast in the beginning to synchronize all of the robots before each sound pulse is sent. This sync signal will provide a trigger to the robots acting as base points so that they don't always need to be waiting for sound pulses.

      Incremental trilateration consists of four steps:

      1. Movement
      2. Sync Transmit
      3. Signal Transmit
      4. Calculation

      Initial Conditions

      For this method to work the robots need to start off at set points. This means that the robot master and two of the robots need to start at known locations. Trilateration requires the knowledge of three base points for calculating the fourth point and so absolute positions of the three base points need to be known.

      Steps 1-3


      The animation above covers the movement, sync transmit, and signal transmit steps of the process. The big square and two smaller circles on the sides represent the base station and two of the robots at known points.


      In this step the robot that's currently active moves, either towards a target or to explore. In the example above the robot in front moves along the Y axis from its position directly in front of the base station to an indeterminate position in front and to the right of where it was before.

      Sync Transmit

      The expanding, red circle sent out from the robot represents a sync signal that will be sent from the robot at an unknown position to the three other robots at known locations. In my planned implementation this will be a 40Khz IR signal. Once the three receiving robots receive this signal they know to start counting and waiting for the signal transmit. It should be noted that I'm ignoring the travel time of the IR pulse because the speed of light is so fast that it can be considered insignificant over the small distances that the robots...

    Read more »

  • ICRS: Robot Swarm Design

    Keith Elliott03/28/2018 at 02:07 0 comments

    Before diving into the nitty-gritty of the robot design I wanted to take a moment and lay out a brief description of the network and base robot architecture. Below is a block diagram and description of both the network topology and the configuration of the robots.

    Network Topology


    The pure swarm approach for a fully modular network would involve a mesh network with with no centralized control source. Instead of doing this I'm opting for a robot swarm with central control node, much like how a bee hive has a queen. And, since robot dancing has not reached bee levels of communication, I'm going to leverage existing technology and use WiFi. This will make it easier to use existing single board computers (e.g. the Raspberry Pi) for robot control instead of making a homebrew control board. Having all of the robots on a single WiFi network will also make it easy to remote login to the individual robots for telepresence control.

    I also plan on having a single, central node to handle the complex control and collate all of the data provided by the individual swarm robots. This central point will also have the WiFi access point. Having a single master may seem counter-intuitive for a robot swarm but it will make development and control much easier. A powerful central computer can do complicated operations such as image processing and parsing the most efficient paths for each robot to take. The central node can also handle delegation by directing each robot to assume a role in heterogeneous swarms when different tasks need to be handled by the robots. Another benefit of making a single master node is debugging. Having the central node keep track of all of the data will make it easier to access the swarm's status and provide a clear picture of how the system is operating.

    Base Robot Configuration

    I've tried my best to limit the robot's base design (i.e., the components that will be common between all robots no matter their role or attached modules) to the very minimum. The block diagram above is what I came up with.

    Each robot will have three core modules built in to the base design: one for power control and distribution, one for motor control, and one for localization. The only exception will be the central node which won't have the motor control module. The modules will all report to a central CPU. Each of these modules will be intelligent with its own microcontroller for real time control and calculations. Having a microcontroller for each module abstracts away the processing required for each module and lets the CPU retrieve processed data and send commands without having to manage every single component.

    I decided on using a full SoC rather than just a microcontroller to help speed up development and to potentially allow for some image processing and other calculations to be done locally. The Pi Zero W seems like the best bet for this at the moment due to its native camera support and on-board WiFi (and the large support community is a huge plus!). Using a full Linux system will also make software design easier without requiring constant retrieval and firmware flashing every time the software changes. It will be simple enough to remote in to each robot for control and status update over SSH.

    I plan on defining the interface and functionality of each module in the next few posts. I also want to outline and explain my method for robot localization in detail. That will be my next post.

View all 2 project logs

Enjoy this project?



malvasio.christophe wrote 03/23/2018 at 08:16 point

if you switch for a no-country view of construction in oceans and our moon to begin it will be the best

i plan a low cost (nothing burned) launcher for moon colonisation by bots ;)

also i made to power bots

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates