HeRoSwarm: Fully-Capable Miniature Swarm Robot Hardware Design With Open-Source ROS Support

Michael Starks, Aryan Gupta, Sanjay Sarma O V, and Ramviyas Parasuraman M. Starks and S. OV are with the College of Engineering, University of Georgia, Athens, GA, USA.A. Gupta is with the School of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta, GA, USA.R. Parasuraman is with the School of Computing, University of Georgia, Athens, GA 30602, USA.Corresponding author email: [email protected]

Abstract

Experiments using large numbers of miniature swarm robots are desirable to teach, study, and test multi-robot and swarm intelligence algorithms and their applications. To realize the full potential of a swarm robot, it should be capable of not only motion but also sensing, computing, communication, and power management modules with multiple options. Current swarm robot platforms developed for commercial and academic research purposes lack several of these critical attributes by focusing only on a few of these aspects. Therefore, in this paper, we propose the HeRoSwarm, a fully-capable swarm robot platform with open-source hardware and software support. The proposed robot hardware is a low-cost design with commercial off-the-shelf components that uniquely integrates multiple sensing, communication, and computing modalities with various power management capabilities into a tiny footprint. Moreover, our swarm robot with odometry capability with Robot Operating Systems (ROS) support is unique in its kind. This simple yet powerful swarm robot design has been extensively verified with different prototyping variants and multi-robot experimental demonstrations.

I Introduction

A collection of independent miniature robots can be used as a sandbox for researching and testing swarm intelligence algorithms and multi-robot system applications such as pattern formation, self-organization, cooperative decision-making, etc. [1, 2, 3]. Recently, modular swarm robots have utilized commercial off-the-shelf (COTS) hardware designs instead of custom designs that require special access or resource to produce a robot.

The key design goals for the swarm robot hardware are to create a compact robot that includes an array of fundamental sensors, independent computing, precise self-localization, autonomous charging capability, and robust multi-level software control [4, 5]. In terms of software control and programming, it is ideal for making it compatible with the Robot Operating System (ROS) [6], which is a widely-used middleware framework in academic and commercial research robot platforms. This enables integration with any other robot platforms or simulators that are ROS-enabled. Having all these features in a single swarm robot platform would be highly desirable and valuable in analyzing and testing various sensing and control algorithms.

Refer to caption — Figure 1: HeRoSwarm Robot Design - Exploded View Showing the Features.

Most of the current swarm robot platforms [7, 8, 9, 10, 11, 12] lack one or more of the outlined design goals and features. For instance, the Robotarium multi-robot testbed [13, 14] is a swarm algorithm simulator-hardware resource. The focus is on remote access and democratization of swarm robot experiments, while it lacks access to robot-level sensing data at the control interface. Among the ROS-supported platforms, Mona [15], WsBot [16] and the SMARTmBot [17] stand out, but they either lack high-power computing or onboard odometry modules.

To fill these gaps, in this paper, we propose the HeRoSwarm robot platform, which possesses the below unique features integrated with the ROS middleware framework. We open source the hardware design and software codes in GitHub¹¹1https://github.com/herolab-uga/heroswarmv2. The key features and modules of the proposed HeRoSwarm design are as follows (see Fig. 1 for an overview of the design features):

•

Sensing Multiple sensors such as proximity, RGB, sound, Inertial (IMU) altitude, and humidity and pressure measurements to capture local information;
•

Communication Explicit data communication modalities such as Wi-Fi and Bluetooth;
•

Computing High C1-level [18] computing through a Raspberry Pi Zero-based computing module that can support ROS and advanced programming;
•

Motion Multi-level motor control with onboard wheel odometry aided by a microcontroller;
•

Power Dedicated power management with different recharging variants such as inductive wireless charging or magnetic coupling.

The low-cost design uses COTS components (within a total cost of $100) to ease replication by peer researchers. The HeRoSwarm platform will be a novel addition to the available swarm robot alternatives with its feature-rich design, compact size, and ROS compatibility. With these contributions and features, we expect that the HeRoSwarm robot will be applicable to wide use cases, including education and research on the basics of sensing, control, robotics, multi-robot systems, and swarm intelligence algorithms.

II Related Swarm Robot Platforms

Many swarm robot designs were proposed in the literature (e.g., [7, 19, 10]), which primarily focused on specific applications or capabilities such as modularity for self-assembly [20], wheel-track mobility for rough terrains [21], vibration-based drive for tiniest footprint [22]. Below, we analyze some closely relevant robot platforms used in the swarm robotics [4] research domain.

Georgia Tech’s GRITSBot [14] is designed to be low-cost, compact robots that can be used to study swarm behavior. The GRITSBots’ drive train is made of two stepper motors and subsequently forgoes wheel encoders and instead counts the change in the wheel’s position through the stepper motor. There is not a readily available option to make the GRITSBot ROS enabled, and its onboard computing is a single microcontroller that is used to receive control commands and read the data from the 6 IR sensors that make up the sole sensor array on the robot. The GRTSBots have a way to charge autonomously with two extending contacts connecting to a metal charging strip.

The Kilobot [10] is a markedly different swarm solution. These robots have the absolute minimum onboard computation necessary to carry out the programmed task; instead, a central computer controls all the robots in the swarm. The drive train for the Kilobot is made of vibration motors that allow to robot to slide across the work surface. The sensor included on the Kilobot allow for collision avoidance and ambient light sensing.

Khepera IV by Webots [9] is another research and educational robot platform. Each Khepera robot has a Linux core running on an ARM processor, and its sensor array includes eight infrared sensors for object detection, four line-following Infrared sensors, 5 Ultrasonic sensors for long-range object detection, a 3-axis accelerometer, a 3-axis gyroscope. The Khepera also has a microphone, a speaker, and a color camera. The capabilities of the Khepera are expandable through its KB-250 bus. The Khepera robots have a diameter of 140 mm and house a larger battery for approximately 7 hours of operation. By footprint, Khepera robots are larger in size than the HeRoSwarm Robots.

WSBots [16] are ROS-enabled miniature robots that can be used to model industrial environments. These robots are made to have capabilities that mimic tools used in an industrial environment. They feature wireless charging and lifts similar to that of a forklift. The WSbots lack extensive computing power due to the low-power computing unit used to achieve the small size and the absence of any environmental sensing. The WSBots were developed to explore a subset of problems in the swarm and multi-robot system space, limiting some capability to mimic the tools used in industry.

A recent swarm robot design with a similar name HeRo2.0 [23], has ROS compatibility and wheel encoders. While it has an array of proximity sensors, the robot is equipped with an ESP12 as the sole control unit to handle the motor control and network communication for the robot with the ROS middleware at a server. HeRo2.0 is a capable swarm research platform but lacks high-level compute capabilities comparable to HeRoSwarm, preventing resource-intensive expansion such as onboard computing with ROS.

None of the existing swarm robots offer the sensing and computing capabilities that HeRoSwarm possesses in the same small form factor. They either possess good individual functionality or function as a multi-robot system, but the absence of an integrated solution can hinder their adoption. The available platforms do offer expansion options that are not possible with the current implementation of the swarm robot hardware. HeRoSwarm also differs from the other robot designs in terms of the integration of various critical hardware for a fully-capable swarm robot that can function both as a single robot and as well as a multi-robot platform. Open-source software support adds further novelty to HeRoSwarm design. Fully functional prototypes of the HeRoSwarm robot designs are shown in Fig.2.

III HeRoSwarm Hardware Design

With the HeRoSwarm (robot size 7cm x 7.3cm x 5.3 cm), users will have access to additional functionality, such as sensors and control granularity, while maintaining ease of use. Below, we describe different aspects of the robot design. See Fig. 3 for an overview of the integration of hardware modules as well as software elements. In Fig. 4, we present the connection schematic between the various modules.

III-A Sensing Component

Unlike other swarm robot designs, HeRoSwarm is designed to have direct ROS-level access to a multitude of sensors and odometry through the integrated Feather Sense BLE board that houses various sensors along with an onboard microcontroller. The sensors included are the LSM6DS33 - 6 degrees of freedom accelerometer and Gyroscope that can determine the orientation of the robot; the LIS3MDL - a magnetometer that can also be used to determine the orientation of the robot; the APDS9960 - a light sensor that outputs color, proximity, and gesture data; and a BMP280 that measures temperature, altitude, and barometric pressure. The Sense board is also able to measure the humidity and process audio from a microphone. Additionally, each of the robot’s wheels is equipped with a Hall Effect Quadrature Incremental Encoder that is connected to the Feather Sense.

III-B Computing and Communication

The Broadcom BCM2835 SOC on the Raspberry Pi Zero runs a ROS-supported robot controller on top of an Ubuntu OS. This places the robot’s design at the C1 computing level, as per the study in [18]. While the Feather Sense is equipped with a Bluetooth module, the Raspberry Pi Zero W is equipped with an 802.11n Wi-Fi module. The HeRoSwarm robots are connected to the same wireless network that hosts the Central Server to send and receive information from the active ROS nodes. Communication between the Feather Sense and Pi can be achieved through I2C and UART ports. The addition of a Raspberry Pi module is optional, which is a feature of our modular design. Hence, the availability of ROS support is also based on the addition of a Pi module.

With ROS, the robot has a list of topics that exposes control of the robot and sensor data to the robot driver node (see Fig. 3, Right). The robot’s driver subscribes to a velocity topic that needs linear and angular velocity inputs, or the robot can be controlled through a position control node. The robot publishes all the sensor data on different topics at configurable publish rates depending on the application.

III-C Motion Control

Each HeRoSwarm robot is equipped with two brushed DC motors used to control the position and orientation of the robots. The robots are powered through a boosted power to provide the 5 volts needed to power the Raspberry Pi and DC motors. The motors are controlled by two PID controllers on the sense board through a motor driver that sets the linear and angular speed of the robot based on the data from Pi zero. The robot follows a differential drive kinematics with linear and angular velocities calculated as

v_{R}=r.\frac{\phi_{right}+\phi_{left}}{2},\;\omega_{R}=r.\frac{\phi_{right}-\phi_{left}}{d_{w}},

(1)

where $r$ is the radius of a wheel, $\phi$ is the wheel velocity applied to left or right motors, and $d_{w}$ is the distance between the centers of the wheels.

The velocities (inputs) received through the ROS framework are converted to independent wheel speeds by solving the inverse kinematics from Eq. (1). The velocities of the wheels are applied using a PID controller.

In addition, the built-in wheel encoders on the geared DC motors connected to the Feather Sense board are also used to track the robot’s position (odometry) and velocity using the motor’s encoders to know the robot’s position in its coordinate frame. The odometry is updated every iteration of the Feather Sense main loop. The wheel encoders provide the number of ticks corresponding to the wheel rotations. The difference between the new and old wheel ticks is adjusted by varying the PWM frequencies. Here, an angle $\Delta\theta$ per tick can be computed from $\Delta T$ of ticks as

\Delta\theta=A.\Delta T,

(2)

where A is the angle rotated per tick. Thus the angular velocity of the motor,

\omega=\frac{\Delta\theta}{\Delta t}=A.\frac{\Delta T}{\Delta t}

(3)

and the corresponding linear velocity at each wheel is computed as

v=r.A.\frac{\Delta T}{\Delta t}=D_{T}\frac{\Delta T}{\Delta t}.

(4)

Here, the factor $D_{T}$ is the meters traveled by the wheel per tick which is pre-calibrated. The angle rotated by the robot in the $\Delta t$ interval is computed as $\Delta\Theta_{R}=\omega_{R}\Delta t$ . Also, the robot travels in a circle of radius $R$ , computed as

R=\frac{d_{w}}{2}\frac{(v_{right}+v_{left})}{(v_{right}-v_{left})}.

(5)

The change in left and the right motor ticks are based on

\begin{split}\Delta T_{right}&=\frac{2\frac{v_{R}}{D_{T}}+\frac{\omega_{R}}{A}d_{w}}{2R}\\ \Delta T_{left}&=\frac{2\frac{v_{R}}{D_{T}}-\frac{\omega_{R}}{A}d_{w}}{2R}\\ \end{split}

(6)

Finally, the position update of the robot with respect to the global coordinate system in the HeRoSwarm testbed can be obtained from the following equations.

$\displaystyle X(t+1)$	$\displaystyle=X(t)+\|v_{R}\|.cos(\frac{\Delta\Theta_{R}}{2}).(2Rsin(\frac{\Delta\Theta_{R}}{2})$	(7)
$\displaystyle Y(t+1)$	$\displaystyle=Y(t)+\|v_{R}\|.sin(\frac{\Delta\Theta_{R}}{2}).(2Rsin(\frac{\Delta\Theta_{R}}{2})$
$\displaystyle\Theta(t+1)$	$\displaystyle=\Theta(t)+\frac{2D_{T}}{R}\Delta T$

III-D Power Management

The robot consumes an average of 0.9W in idle mode and up to 1.5W when in motion. This brings the run time to 1-3 hours on average use with a 2000mAh battery capacity (LiPo 3.7V). The power is regulated using the Adafruit Powerboost 1000c. Each robot is equipped with a LiPo battery that powers the PowerBoost. The battery voltage is measured using the Feather Sense board and is used to track battery life. The battery data is monitored by the ROS node on the Raspberry Pi to activate the auto charge routine. The robots can be charged via multiple means: 1) using the micro-USB port available on the back of the Powerboost, 2) using the small copper plates with a magnetic coupling on the front and back of the robot, and (optionally) 3) using an induction coil to wirelessly charge the robot.

IV HeRoSwarm Software Architecture

The HeRoSwarm ROS workspace contains the Robot Controller, Camera Server, and Robot Messages packages needed for the multi-level controller. The purpose of the HeRoSwarm packages is to allow full user control of the swarm and the individual robots while being easy to use and integrate into current projects. The workspace uses standard topic names allowing integration with any ROS-enabled robot using standard topics and seamless integration of robots to form heterogeneous swarms [24]. ROS allows for the use of the Publisher-Subscriber and Service-Client message architectures, facilitating communication between nodes on the same network. ROS also provides a way of distinguishing nodes with the same name through namespaces; appending the name of a robot to the node prevents duplication and erroneous control by distinguishing the nodes. The following sections detail the design for each package in the HeRoSwarm workspace and how they integrate to control the HeRoSwarm Robot platform.

The Robot controller is a lightweight Python package that is deployed on the HeRoSwarm Robots. The controller exposes all of the features of the Robots to the ROS environment, including sensor data and odometry, in addition to position and velocity control. The controller is able to publish data from any of the sensors available on the Adafruit Feather sense board when the topics are activated. The odometry data gathered from the motor controller is published in the robot namespace to the Odom topic to allow users to read and track the robot’s position in its frame. The Odometry data is stored in the ROS Odometry message format for ease of use with other ROS nodes. The position controller takes a tuple containing a position in the global frame that the robot should navigate to. The robot velocity can be controlled through the cmd_vel topic; the linear velocity along the X-axis and rotational velocity along the Z-axis can be set independently for full control of each robot. The controller also creates topics for monitoring the battery level.

The Camera Server is a key node in our HeRoSwarm ROS package. It provides tracking of the robot’s position and orientation, the location of the charging stations, and creating the global position frame. The position of a robot is determined using an AprilTag [25] attached to the robot frame. The positions of all robots on the table are published on a global position topic. Each robot in the frame has a thread responsible for publishing its position data in the appropriate namespace and tracking the robot’s odometry. The robot charging stations also use AprilTags to denote their position. The available charging stations are tracked by the camera server and assigned to the robot upon request from the low-battery service. The camera server is intended to run on a computer with a sufficient processing power for fiducial recognition, relieving some of the computational burdens from the swarm robots. Global position tracking is intended for evaluating the performance of swarm intelligence algorithms.

The multi-level control scheme gives the user freedom in deciding the granularity of their algorithm. Through the standard set of ROS Topics published by each robot, the user can monitor the state of the robot, set and get the robot’s velocity and position, as well as have access to the onboard sensors. Each robot has its namespace, where it publishes and subscribes to a standardized list of topics to communicate with other controllers and robots. The Robot Controller includes a python class that neatly wraps the ROS functionality to facilitate swarm-level control. The wrapper class allows users to control the swarm as a collective rather than an individual robot. The number of robots used is determined by the user and can be changed asynchronously in the control loop; this allows users to add or remove robots at will to mimic any number of scenarios. The control loop steps at user-defined intervals to iterate through actions at different time scales. The wrapper can gather and return sensor data as well as the position data asynchronously of the control loop. The data is stored in a M x N matrix where N is the number of active robots and M is the tuple holding the data. The methods of the wrapper class can facilitate deployment onto the HeRoSwarm platform.

V Experimental Validation

We made several prototypes of the HeRoSwarm robot design. Validation of the current design requires independent validation (unit testing) of all the implemented features before the whole system can be used. Below, we present the important results pertaining to the odometry and motion control, as they are unique to our robot.

V-A Localization

As described in Sec. IV - Camera Server, a camera-based overhead position tracking system is used as ground truth to compare the robot’s odometry and obtain state information of all robots in the system.

Each robot has a unique Apriltag that is used to locate its position in the global frame. The tag is pasted on the top plate of the robot chassis. Three tags are used to mark the axis of the operation field and are used to transform the robots into the global frame. Using Apriltags to mark the boundaries of the global frame allows for resizing the field to accommodate different experiments. The tabletop testbed hosting the swarm robot platforms has a size of 2.5 x 1.75 meters. To characterize the camera position system error, points were marked and measured on the board to find their position relative to the axis tags. An AprilTag was placed on each point, and the calculated position was recorded. Figure 5 shows the measured position and the position reported by the camera server. From the gathered data, the average error of the camera-based positioning system is 0.8 cm, meaning a reasonable sub-cm accuracy for using it as ground truth in robot tracking and performance evaluations.

The nRF52 on the Adafruit Feather Sense board calculates the robot’s odometry. This information is passed to Raspberry Pi zero computer for publication on the Odom topic. To validate the accuracy of the odometry, the robot was driven along a defined path, and the camera position and the odometry position data were recorded. Figure 6 shows the position captured by the camera and the reported odometry. The camera position was shifted to originate at the starting position of the robot. The mean absolute error in odometry is 6.3 cm (with a standard deviation of 4.1 cm). The max error was observed to be 12.8 cm w.r.t. camera-based position. This shows the high odometry accuracy of the HeRoSwarm robots, which will play a crucial role in the evaluation of algorithms that do not rely on global positioning. This accuracy can be further improved with the integration of odometry with IMU sensor data [26], which will be an avenue for future work.

V-B Motion Control

Testing of the robot’s motion control began by comparing the linear and angular velocities to the set velocities and finding the top speed. From the data gathered, the HeRoSwarm Robots have a max speed of 28 $cm\phantom{.}s^{-1}$ . To ensure desired performance, the max linear and angular speeds are set such that when combined, the rotational speed of the wheels is below its maximum. We obtained a mean error of 4 cm/s in ten trials, showing promising results.

VI Demonstration with Multi-Robot Setup

To holistically demonstrate the overall capability of the robot, we successfully implemented and tested three different multi-robot algorithms as detailed below.

VI-A Multi-Robot Rendezvous

We implement a typical rendezvous algorithm from [27]. The rendezvous problem here is to make the robots gather together quickly without a specific destination goal point, starting from their random initial positions. The rendezvous looks to control the robots such that the distance between the robots nears zero.

\lim_{x\to\infty}(x_{i}-x_{j})=0,\forall i,j=1...N

(8)

Here, $x_{i}$ is the position of robot $i$ . From the initial state of the robots, the controller finds the central. The velocity ( $\dot{x}$ ) with which each of the robots needs to move would be toward the center point of the robot’s neighbors.

\dot{x}_{i}=\sum_{j\in N_{i}}(x_{j}-x_{i}),

(9)

where $N_{i}$ is the neighboring robot to robot i. Each iteration of the algorithm further minimizes the distance between the robots, bringing them closer to the center.

The stop condition for the controller is bringing the robots as close together as possible. In the end, all the HeRoSwarm Robots will be as close together as the collision avoidance algorithm allows. Moving one of the robots will cause the others to reorient and minimize the position. Fig.7 shows the position (state) of the robots at different time instants during the rendezvous process, showing a successful demonstration of the rendezvous algorithm with the HeRoSwarm robots.

VI-B Multi-Robot Audio Signal-aided Rendezvous

To further demonstrate the integration of sensors with motion control, we extend the rendezvous strategy in Eq. (9) with sensor information. We use the microphone sensor on the Sense board to give us the intensity of the audio signal. In this demonstration, we follow the below equation.

	$\displaystyle\dot{x}_{i}=\sum_{j\in N_{i}}(x_{max_{j}}-x_{i}),$		(10)
	$\displaystyle max_{j}=\operatorname*{arg\,max}_{j\in N_{i}}S_{j}.$		(11)

Here, $S_{j}$ is the sound intensity value of the microphone sensor on the robot, and $x_{max_{j}}$ is the robot’s position that has the maximum audio signal intensity. So, all robots move toward the robot that is close to the audio source.

The Lobar pickup pattern of the mic makes them highly direction-sensitive, meaning the robot closest to the mic does not necessarily detect the highest volume. Fig. 8 shows the successful outcome of this demonstration, showcasing the utility of HeRoSwarm’s sensor package and the sensor-motion integration in our ROS framework.

VI-C Mutli-Robot Formation Control

We implemented the muti-robot formation control algorithm from [28], which extends the rendezvous control algorithm by constraining their relative positions to lie within a formation shape. In this example, we used five robots that were commanded to group together and form a pentagon with a side length of roughly $.25$ meters. Assume $\zeta_{i}$ defines a coordinate of robot $i$ within a specific formation shape containing all the robots. Then the formation control problem extends the rendezvous control in the below equation.

\displaystyle\dot{x}_{i}=\sum_{j\in N_{i}}(\chi_{j}-\chi_{i}),\text{ where, }\chi_{i}=x_{i}-\xi_{i}.

(12)

We tested this algorithm and the results are shown in Fig. 9, demonstrating another strong integration of HeRoSwarm capability in tightly coordinated control tasks.

VII Conclusion

We proposed a new swarm robot platform called HeRoSwarm, which integrates full functional capability in terms of sensing, motion, computing, communication, and power management. The simple design with COTS components, robust sensor package (with a multitude of sensors), and onboard computation facilitate the implementation of complex and distributed algorithms. The robot’s ROS-supported software architecture expands the accessibility and enables integration with the ROS software ecosystem. The unique onboard odometry gives real-time data on the position of the robots to different levels of control.

The HeRoSwarm robot has a huge potential in swarm robotics and related applications, as its functionality exposed in the robot hardware and software design gives the user flexibility to implement any desired multi-robot and swarm intelligence algorithms (e.g., [29, 30, 31]). While the HeRoSwarm has met its primary design goals, it continues to undergo improvements to expose more features and additional hardware and software functionalities (compatibility with ROS2 for instance). We validated the robot’s odometry and motion control and demonstrated the sensor-motion and swarm system integration through multi-robot experiments.

References

[1] M. Brambilla, E. Ferrante, M. Birattari, and M. Dorigo, “Swarm robotics: a review from the swarm engineering perspective,” Swarm Intelligence, vol. 7, no. 1, pp. 1–41, 2013.
[2] L. E. Parker, “Distributed intelligence: Overview of the field and its application in multi-robot systems.” in AAAI fall symposium: regarding the intelligence in distributed intelligent systems, 2007, pp. 1–6.
[3] Q. Yang and R. Parasuraman, “A game-theoretic utility network for cooperative multi-agent decisions in adversarial environments,” arXiv preprint arXiv:2004.10950, 2020.
[4] M. Dorigo, G. Theraulaz, and V. Trianni, “Swarm robotics: past, present, and future [point of view],” Proceedings of the IEEE, vol. 109, no. 7, pp. 1152–1165, 2021.
[5] G. Seeja et al., “A survey on swarm robotic modeling, analysis and hardware architecture,” Procedia Computer Science, vol. 133, pp. 478–485, 2018.
[6] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, A. Y. Ng et al., “Ros: an open-source robot operating system,” in ICRA workshop on open source software, vol. 3. Kobe, Japan, 2009, p. 5.
[7] F. Arvin, J. C. Murray, L. Shi, C. Zhang, and S. Yue, “Development of an autonomous micro robot for swarm robotics,” in 2014 IEEE International Conference on Mechatronics and Automation. IEEE, 2014, pp. 635–640.
[8] C. M. Cianci, X. Raemy, J. Pugh, and A. Martinoli, “Communication in a swarm of miniature robots: The e-puck as an educational tool for swarm robotics,” in International Workshop on Swarm Robotics. Springer, 2006, pp. 103–115.
[9] J. M. Soares, I. Navarro, and A. Martinoli, “The khepera iv mobile robot: Performance evaluation, sensory data and software toolbox,” in Robot 2015: Second Iberian Robotics Conference, L. P. Reis, A. P. Moreira, P. U. Lima, L. Montano, and V. Muñoz-Martinez, Eds. Cham: Springer International Publishing, 2016, pp. 767–781.
[10] M. Rubenstein, C. Ahler, and R. Nagpal, “Kilobot: A low cost scalable robot system for collective behaviors,” in 2012 IEEE international conference on robotics and automation. IEEE, 2012, pp. 3293–3298.
[11] F. Arvin, J. Espinosa, B. Bird, A. West, S. Watson, and B. Lennox, “Mona: an affordable open-source mobile robot for education and research,” Journal of Intelligent & Robotic Systems, vol. 94, no. 3, pp. 761–775, 2019.
[12] S. Wilson, R. Gameros, M. Sheely, M. Lin, K. Dover, R. Gevorkyan, M. Haberland, A. Bertozzi, and S. Berman, “Pheeno, a versatile swarm robotic research and education platform,” IEEE Robotics and Automation Letters, vol. 1, no. 2, pp. 884–891, 2016.
[13] S. Wilson, P. Glotfelter, S. Mayya, G. Notomista, Y. Emam, X. Cai, and M. Egerstedt, “The robotarium: Automation of a remotely accessible, multi-robot testbed,” IEEE Robotics and Automation Letters, vol. 6, no. 2, pp. 2922–2929, 2021.
[14] D. Pickem, M. Lee, and M. Egerstedt, “The gritsbot in its natural habitat-a multi-robot testbed,” in 2015 IEEE International conference on robotics and automation (ICRA). IEEE, 2015, pp. 4062–4067.
[15] A. West, F. Arvin, H. Martin, S. Watson, and B. Lennox, “Ros integration for miniature mobile robots,” in Annual Conference Towards Autonomous Robotic Systems. Springer, 2018, pp. 345–356.
[16] M. A. Limeira, L. Piardi, V. C. Kalempa, A. S. de Oliveira, and P. Leitão, “Wsbot: A tiny, low-cost swarm robot for experimentation on industry 4.0,” in 2019 Latin American Robotics Symposium (LARS), 2019 Brazilian Symposium on Robotics (SBR) and 2019 Workshop on Robotics in Education (WRE), 2019, pp. 293–298.
[17] W. Jo, J. Kim, R. Wang, J. Pan, R. K. Senthilkumaran, and B.-C. Min, “Smartmbot: A ros2-based low-cost and open-source mobile robot platform,” arXiv preprint arXiv:2203.08903, 2022.
[18] S. M. Trenkwalder, “Computational resources of miniature robots: Classification and implications,” IEEE Robotics and Automation Letters, vol. 4, no. 3, pp. 2722–2729, 2019.
[19] A. Testa, A. Camisa, and G. Notarstefano, “Choirbot: A ros 2 toolbox for cooperative robotics,” IEEE Robotics and Automation Letters, vol. 6, no. 2, pp. 2714–2720, 2021.
[20] H. Wei, Y. Cai, H. Li, D. Li, and T. Wang, “Sambot: A self-assembly modular robot for swarm robot,” in 2010 IEEE International Conference on Robotics and Automation. IEEE, 2010, pp. 66–71.
[21] M. Dorigo, D. Floreano, L. M. Gambardella, F. Mondada, S. Nolfi, T. Baaboura, M. Birattari, M. Bonani, M. Brambilla, A. Brutschy et al., “Swarmanoid: a novel concept for the study of heterogeneous robotic swarms,” IEEE Robotics & Automation Magazine, vol. 20, no. 4, pp. 60–71, 2013.
[22] M. Rubenstein, C. Ahler, and R. Nagpal, “Kilobot: A low cost scalable robot system for collective behaviors,” in 2012 IEEE International Conference on Robotics and Automation, 2012, pp. 3293–3298.
[23] P. Rezeck, H. Azpurua, M. F. Correa, and L. Chaimowicz, “Hero 2.0: A low-cost robot for swarm robotics research,” arXiv preprint arXiv:2202.12391, 2022.
[24] R. Parasuraman and R. Pidaparti, “Impact of heterogeneity in multi-robot systems on collective behaviors studied using a search and rescue problem,” in 2020 IEEE International Symposium on Safety, Security, and Rescue Robotics (SSRR). IEEE, 2020, pp. 290–297.
[25] E. Olson, “Apriltag: A robust and flexible visual fiducial system,” in 2011 IEEE international conference on robotics and automation. IEEE, 2011, pp. 3400–3407.
[26] M. Brossard and S. Bonnabel, “Learning wheel odometry and imu errors for localization,” in 2019 International Conference on Robotics and Automation (ICRA). IEEE, 2019, pp. 291–297.
[27] R. Parasuraman and B.-C. Min, “Consensus control of distributed robots using direction of arrival of wireless signals,” in Distributed Autonomous Robotic Systems. Springer, 2019, pp. 17–34.
[28] M. M. Zavlanos, M. B. Egerstedt, and G. J. Pappas, “Graph-theoretic connectivity control of mobile robot networks,” Proceedings of the IEEE, vol. 99, no. 9, pp. 1525–1540, 2011.
[29] O. V. Sanjay Sarma, T. V. Lohit, and S. Pugazhenthi, “Development and testing of a foraging strategy for low cost swarm robots,” in 2013 International Conference on Control, Automation, Robotics and Embedded Systems (CARE). IEEE, 2013, pp. 1–6.
[30] E. Latif, Y. Gui, A. Munir, and R. Parasuraman, “Energy-aware multi-robot task allocation in persistent tasks,” arXiv preprint arXiv:2112.15282, 2021.
[31] E. Latif and R. Parasuraman, “Dgorl: Distributed graph optimization based relative localization of multi-robot systems,” arXiv preprint arXiv:2210.01662, 2022.