Hardware Experiments

Our hardware experiments demonstrate that our system can accomplish a complex physical task using physical SMORES-EP robot modules. The robot is required to clean the top of a table, operating in the environment shown in Figure 42. To do so, the robot must first move a waste bin from its initial location (labelled “Pickup”) to a target location next to the table (labelled “Dropoff”). Then, the robot must climb to the top of the table and explore the surface. Whenever it encounters an object, it must react appropriately: if it is garbage, it should push it off the table and into the waste bin, and if not, it should notify a human to remove it.

This experiment showcases the seamless translation of behaviors from the VSPARC simulator to hardware, and the ability to use the LTLMoP high-level planner to create mission plans that can be directly executed by the modules. AprilTags tracked by an overhead camera provide information about the position of modules and objects in the environment, serving as sensory feedback for the high-level planner.

This experiment also demonstrates how the design library is continually expanded as users develop designs to address new tasks. While the library encompasses a wide range of functionality, it is by no means complete: when a high-level specification was first created for this experiment, the mission planner reported that it could not be satisfied using exist- ing elements in the library. Consequently, two new configurations (the swerveLifter and

snake7 configurations) were created, and low-level behaviors were iteratively developed to fulfill the needs of each component of the task. Once these configurations and behaviors were made available in the library, the high-level planner was able to successfully synthesize and execute controllers to accomplish the tasks.

Moving the Waste Bin

The robot begins its task in region Start1, and must move the waste bin from Pickup to

Figure 41: Environments for Scenarios 1 (top) and 2 (bottom) in the simulator.

the robot must travel to the edge of the table (Start2), where it can begin the next phase of the task (exploring the tabletop).

The waste bin is a box supported by four legs, making it impossible for any design less than two module-heights tall to push it. This constraint rules out most car-like configurations in the library. The 10-module distance over which the bin must be transported imposes a workspace requirement that rules out all stationary manipulators. Consequently, the

swerveLifter configurations was designed to meet all the criteria. TheswerveLifter uses four SMORES-EP modules as powered caster wheels, allowing omnidirectional movement (sometimes called swerve drive). It can also raise and lower, enabling it to lift and carry objects by driving underneath them.

The high-level description of this phase of the task is shown in Specification 1, and Figure 44 shows how the robot completes it. The task is reactive: the robot waits until it senses the waste bin before beginning thepickup action (Line 3 of Specification 1). Once the waste bin appears (i.e. the AprilTag marking it comes the camera view), the robot lowers itself, drives beneath the waste bin, and carries it to the Dropoff region. It then moves back out from beneath the waste bin, and executes a series of omnidirectional driving behaviors to travel to the edge of the table.

Specification 1 Moving the Wastebin 1. carry is set onpickupand reset on false

2. dropped is set ondropand reset on false

3. dopickupif and only if you were sensingwasteBin

and you are not activatingcarry

4. dogoToTable if and only if you are activatingdropped 5. dodropif and only if you were activatingcarry

and you are not activatingdropped

Table Exploration

With the waste bin in place, the robot begins the second phase of the task: cleaning the top of the table. The robot needs to climb to the tabletop, explore, and react to what it finds. The snake7configuration was designed to be capable to do this. As shown in Table 5, the

snake7configuration can use its climbup and climbdown behaviors to ascend and descend ledges up to 3 module-heights tall. However, it is unable to lift its entire body up to the tabletop, and even if it could, it would be too large to effectively explore. Instead, the robot reconfigures, detaching the front module of the snake to act as amodule1configuration that can use its EAP behavior differentialDrive to explore the tabletop, and its spin, and

pushbehaviors to clean.

Specification 2 provides the high-level task description, and Figure 45 shows the robot completing the task. The robot begins in the snake7configuration, positioned at the edge of the table in the groundregion. An AprilTag is fixed to the front module of the snake, allowing the mission planner to determine its location at all times. Sensing that it is in the

ground region, the snake7 executes climbup (line 8 of Specification 2). After climbing, the mission planner senses that the head of the snake has reached the dock region at the edge of the tabletop, and executes the undock behavior to detach the head module from

the snake (line 6), allowing it to operate on its own as a module1.

The module then usesdifferentialDriveto visit two regions of interest on the tabletop (loc1and loc2). differentialDriveis an EAP behavior that allows the robot to explore its environment in a continuous fashion. The driving behavior and its parameters are the same as the driving behavior presented as an example in Section 7.4.3: two parameters specify the left and right wheel velocities. The controller function is a potential field path planner that maps the robot’s current position (sensed via AprilTag) to a desired linear and angular velocity, which are converted to wheel velocities.

When it reaches loc1, the robot senses a coffee mug (marked with an AprilTag), and responds by executing aspinbehavior to notify a nearby human that it should be removed (line 1). When it reaches loc2, it senses a piece of trash, and it correctly responds by performing a push to move it off the table and into the waste bin. Having fully explored the table, the module returns to the dock point and re-attaches to the body of the snake (line 5). The snake then executesclimbdown to descend back to the floor, completing its mission.

Specification 2 Cleaning the Tabletop 1. if you are sensingmugthen dospin 2. if you are sensingtrash then dopush 3. loc1visitedis set onloc1and reset on false

4. loc2visitedis set onloc2and reset on false

5. dodockingif and only if you were in dockand you are activating (loc1visitedandloc2visited)

6. doundockif and only if you were in dockand you are not activating (loc1visitedorloc2visited)

7. doclimbdownif and only if you were indockand you activated (loc1visitedandloc2visited)

8. doclimbupif and only if you were ingroundand you are not activating (loc1visitedor loc2visited)

9. infinitely often do docking

Challenges

In general, the hardware experiment was successful, with the high-level planner successfully executing library behaviors to complete this task. While running the experiment, several notable challenges were encountered. During the first phase (moving the waste bin), achiev- ing accurate steering with theswerveLifter proved difficult. The swerveLifter steers by aligning four caster wheels in the same direction, a process that is sensitive to encoder cal- ibration errors across modules. Recently, more sophisticated calibration procedures for the SMORES-EP encoders have been developed, and encoder performance has been improved [93].

During the second phase of the experiment (exploring the tabletop), careful initial posi- tioning was required for the open-loop climbUp behavior to succeed - in several trials, the snake was started too close to the ledge, causing it to collide with the corner of the table and break. This problem could be alleviated by developing an EAP behavior allowing the robot to autonomously drive to the appropriate distance before beginning to climb.

rollingLoop.backward rollingLoop.forward rollingLoop.forward

backhoe.pressButton doubleDriver.turnAndDrive stairClimber.climb

Figure 43: Simulated Demo

In both phases of the experiment, limited magnetic connector strength between modules presented a significant challenge. The swerveLifter configuration had to be constructed with a passive cube in its center in order to perform its raising and lowering behaviors without breaking. During descent from the table, bending forces experienced at the center of thesnake7configuration would sometimes cause connections between modules to break. The limited strength of the magnetic connectors can be viewed as a trade-off for ease of reconfiguration. Connection and disconnection between the head and body of the snake takes very little time, and the forgiving area-of-acceptance of the connector [92] makes it possible to dock the head of the snake to the body even though the exact position of the body is not known (only the head module had an AprilTag). Autonomous docking succeeded about 25% of the time. This performance could be improved by applying more recently developed techniques for autonomous self-reconfiguration with SMORES-EP.