System Implementation

The locomotion subsystem, was designed to make straight line movement in both the forward and sideways directions easy.  This was achieved through the use of 4 Mecanum wheels that were all individually actuated by 12V DC motors.  By actuating the Mecanum wheels in specific speed-and-direction combinations, the robot could move in any direction in the XY-plane or rotate around its center.  The wheels were purposefully placed with multiple goals in mind: having a large wheelbase and track width (for stability), having the vacuum slots outside of the wheels for maximum vacuum coverage, and having the wheels split between the main body and back foot to make driving while extended across steps possible.  The DC motors were controlled using Cytron motor drivers.  The Mecanum wheels were attached to the motors using custom manufactured couplings.  The motors were attached to the frame using custom designed and printed mounts that provided the maximum ground clearance possible.

The climbing subsystem, was designed to facilitate a train-like design, allowing for a front and back foot to be actuated in specific ways to lift and lower all three parts of the system. This was done with a stepper motor attached to a leadscrew on both the front and back of the middle section. With this stepper motor attached to the leadscrew via a flexible shaft coupling, the leadscrew could be rotated, which moved a lead screw nut up and down the leadscrew, providing the desired vertical motion. The leadscrew was also secured at the bottom by a rotary bearing, constraining it from moving around too much during actuation. The lead screw nut was contained within a nut housing which was attached to the front and back feet, and also attached to the feet was a linear slider which was 3D printed to be able to slide along a vertical piece of 80-20 aluminum. This linear slider constrained the motion of the front and back feet to only move vertically with minimal angular differences. WD40 was applied to the vertical piece of 80-20 to allow for easier sliding. The final part of the system which is not seen in the figure is the limit switch, which was attached above the linear slider and allows for the system to calibrate itself and return to the same initial positions prior to running. This system functions generally by allowing the front foot of the robot to lower onto a stair before both leadscrews are actuated to move the feet down, effectively lifting the middle of the robot, before lifting both feet up again once the middle of the robot is on the next stair.

The sensing subsystem consisted of a suite of HC-SR04 ultrasonic rangefinders, limit switches, and an IMU.  The set of 10 ultrasonic sensors were used for detecting and localizing on the stairs.  The front facing sensors (1, 2, 3, 10) were all used for determining when the robot had fully moved forward onto a step.  The sideways facing sensors (4, 5) were used for determining when to stop left and right motions across a step.  The cliff sensors (6, 7, 8, 9) were used for determining when a foot had made contact with a step and for detecting the step edge while descending.  The limit switches were used for calibrating the vertical position of the feet.  The IMU was used for yaw control and controlling the robot’s rotations (e.g., 90° or 180° turns).

One notable aspect of this subsystem was the on-off toggling of the ultrasonic sensors.  Given the large number of ultrasonic sensors used (10), it was not possible to read all of them using hardware interrupts and reading them all using delays would slow down the main loop below 10 Hz.  To solve this, we would only read from up to 4 ultrasonic sensors at a time; the 4 sensors that were read were determined based on the robot’s current state.  The different sensor combinations used are enumerated in Table 5.

The power subsystem was critical to allow for a single rechargeable battery to power systems on-board, so that the device could be untethered during operation and simple to charge. The main power supply is a 4S 6000mAh 70C battery. This would allow for about 10 minutes of run-time (at nominal current draw - 37A), and about an hour of run-time without the vacuum running. The power distribution board (PDB) was toggled on and off with a switch, and included three voltage regulator circuits. Two 20A voltage regulator circuits produced the 12V power rail, and the other circuit provided the 5V power rail. Three relays were included to control power supply to the stepper motors, DC motors, and vacuum, though after rework we only used the vacuum relay. An onboard ADC gave us the capability to measure the voltage coming off the battery. JST connectors were placed on the 5V and 12V power rails, as well as ground, to allow for reliable power connections for all components. The power outputs to each motor driver, the Jetson, the Mega, and the vacuum were fused for downstream protection in the case of a short.  

Stairbot had a dual computer system with a higher level and lower level control architecture. The communication between the two control architectures was implemented with a UART communication channel at 115200 baud rate with a custom comm protocol.  The dual-architecture system is visually depicted in Figure 10.

Lower Level Controls

The lower level controls running on the Arduino Mega were in charge of receiving actuator commands from the higher level controls and executing those commands to control the LED lights, DC motors, and stepper motors. At the same time the lower level controls collected all the sensor data at a set frequency of 10Hz and sent it back to the high level controller. Sensor data came from a suite of ultrasonic sensors, limit switches, and an IMU. Apart from “listen and do” behavior, the low level controls also had some set autonomy behaviors that could be executed from the high level controller. For example the “Lift Middle Section” was implemented as autonomy behavior wherein the lower level controller was in charge of the duration of the command execution and also the speed of execution. Separately the low level controller also maintained an “error flag” as a general health status indicator passed on to the high level controls for visibility into the functional status of the low level controls.

High Level Controls

The high level controls were implemented as a smach state machine in ROS [7] for modularity, reuse of states, ease of changing behaviors and visibility of the state of the robot during operation. The high level controller powered the autonomy of the Stairbot, taking sensor data from the low level controller, making decisions on what to do next, and then controlling the actuators. The high level flow of the state machine is illustrated in Figure 11. The sensor data from low level control was available to all ROS states as ROS topics and all states communicated with the low level controller using ROS services. In the diagram, many states were common to multiple autonomy behaviors; for example, MoveLeft/MoveRight were common to both climbing and descending so they could be reused. Also smach_viewer allowed us to monitor execution of states in real time during autonomous operation. The high level controller also communicated state of operation to the user by changing lights on the LEDs.