Problem Description

In 2011, 8 workers in the United States sustained fatal injuries whilst cleaning the exterior of buildings. These cleaners suspend themselves midair and work with soapy water, putting themselves at a high risk of falling. Hence, this project serves to minimize the number of injuries and fatalities of window cleaning by automating the process, eliminating the need for workers to put themselves at risk.


Aptly named RACER, this robot is fully automated. By placing the robot in a predefined location on the window, it will automatically sense the dimensions of the window and perform the cleaning without any human inputs. In addition, our robot aims to be faster than other available robotic window cleaners out in the commercial market.

System Requirements

Explicit Design Requirements


From the project specifications, there are several explicit requirements the robot has to meet. With regards to performance, the robot should fully clean one side of a window automatically, where the window size can range from 3' x 4' to 5' x 6'. More specifically, the robot must clean the entire surface of the window at a speed of at least 10 ft2 per min. In terms of cleanliness, the window will be visibly clean from a distance of 3 feet away with no streaks, moisture or residue left on the window after 30 seconds of completion. The robot should also be able to clean both glass and acrylic plastics without scratching or damaging the window surface.


The robot's physical structure should fit within a 2 ft2 footprint. However, the robot can have retractable parts and a variable aspect ratio as long as the robot maintains the aforementioned 2 ft2 footprint. The cleaning devices should not cross the vertical plane of the window - this space would generally not be available due to protrusions around the window border. Cleaning supplies should also be contained within the robot. There should not be any infrastructure installed external to the robot with the exception of tethers connecting it to an external compressor and/or power. In addition, the robot should not be operated from the ground.



Derived and Additional "Coolness" Factors


Additional factors are included into our robot to stand out from the designs from other teams. We have chosen to increase the speed of the robot by 50% (cleaning at least 15 ft2 per min) while maintaining the high cleanliness standards required. Also, the robot is also designed to minimize the use of cleaning supplies (water and cleaning solution) in order to reduce its weight. Finally, the robot will make use of electric ducted fans as the main form of adhesion, something the commercial market has not seen before.

Functional Architecture

To achieve the aforementioned design goals and requirements, our team devised a robot capable of adhering to a vertical surface and maneuvering within the boundaries. We derived six major functions that the robot must perform – adhesion, drive, boundary-detection, path-finding and cleaning. Figure 1 below depicts the overview of the major functions and the flow between them.



Figure 1: System's Major Functions and Flow

Controller

This subsystem is responsible for the interfacing between all the subsystems as well as executing the pathfinding. It receives information from the sensors subsystem and controls the adhesion, drive and cleaning subsystems according to the different states in the pathfinding.

Adhesion

This subsystem is responsible for ensuring that the robot stays adhered to the vertical window surface. This is a critical for the robot to stay adhered to the window to clean the window. The subsystem should not impede the robot’s ability to maneuver on the window.

Drive

This subsystem is responsible for ensuring the robot moves and turns accurately according to the pathfinding. It will alter its direction and speed of movement based on the inputs from pathfinding.

Cleaning

This subsystem is responsible for cleaning the window. Based on the locational and orientation information, the pathfinding will decide when to enable the cleaning subsystem.

Boundary Sensing

This subsystem is responsible for receiving environmental inputs from the robot’s surroundings. Based on the inputs from the sensors, this component will provide information regarding the robot’s location to the controller subsystem.

Orientation Sensing

This subsystem is responsible for receiving environmental inputs from the robot’s surroundings. With inputs from the sensors, this subsystem will inform the controller on the robot’s current orientation. This component acts as a source of feedback input, assisting the controller in compensating the robot’s course and turning.

Cyberphysical Architecture

The following architecture describes the flow of information between the different subsystems within our robot. As described previously, the following main subsystems in the robot’s physical architecture are depicted in Figure 2 below. The power supply will be distributed across the different subsystems.




Figure 2: Cyberphysical block diagram

Controller
The controller, an Arduino Mega, can be seen as the core component in our robot. It receives information from sensors on the robot, such as the current adhesive grip on the window surface and if the robot has reached some form of obstacle. Based on the information received from the sensors, the controller then sends signals to the drive subsystem and control the movement of the robot. Figure 3 below shows the software design of the pathfinding.



Figure 3: Pathfinding State Transition Logic

Adhesion
Our robot will employ two EDFs as the adhesive component. The EDFs create a vacuum between the robot and the window, hence allowing the robot to be held in place on the window. An advantage of using the EDF would include the ability to manipulate the fan speed via the speed controller. This allows us to change the adhesive force required at various stages of the pathfinding.
Drive
The drive subsystem consists of a motor driver and two independent sets of actuators and wheels. Based on inputs from the controller subsystem, the drive subsystem can then maneuver the robot around the window. With independent movement for each of the wheels, the robot will also have the additional flexibility to turn in place.
Sensors
The sensors component exists to interpret information from the current environment as well as the orientation of the robot. In this subsystem, there are two main components - orientation sensor and boundary detection sensor.

Boundary Sensing
The boundary detection component serves as the “eyes” of the robot. The IR sensors will provide feedback on the immediate surroundings of the robot, such as the distance to the nearest window boundary or obstacle.

Orientation Sensing
The orientation sensor consist of an inertial measurement unit (IMU) to detect the 3D orientation of the robot on the window. The controller uses this information to inform course compensation and turning accuracy.
Cleaning
The cleaning subsystem comprises of both active and passive cleaning mechanism. The passive mechanism is the cleaning pads placed below the robot. They will scrub the window as the robot is moving.

The active cleaning mechanism is a solution dispenser. The pump receives a periodic signal from the controller every few seconds to release small amount of cleaning solution. With the use of spray nozzles, the cleaning solution will be sprayed onto the window surface in front of the robot.

System
Description & Depiction

The system is modelled after a racecar, with a two-wheeled chassis and a suction fan mounted in the center. It utilizes a passive cleaning mechanism in which cleaning solution is sprayed in front of the robot and wiped by the microfiber cloth. Below is a 3D render of RACER.


Click and drag to move the 3D render!

Development

Figure 4 shows a snapshot of our development progress. We have iterated through 3 designs, improving on different sub-systems.




Figure 4: Snapshot of RACER development


Figure 5 illustrates the final design of RACERand its different sub-systems and components involved.



Figure 5: Overall System Depiction of RACER
Left: Front View of RACER. Right: Back View of RACER.

Design Trade Studies

Controller
A microcontroller is required to interface with the motors, sensors and cleaning mechanism. Given analog inputs and outputs required by motors and sensors, we have selected two primary options – Arduino Mega and TI MSP430 LaunchPad. Some advantages of Arduino Mega include a massive online community support and libraries which would accelerate our robot’s development. Furthermore, the Arduino Mega has a lot more I/O pins as compared to TI MSP430 which can be helpful given the number of sensors and motors we are using.

However, the TI MSP430 is much cheaper and has more flexible PWM controls as it uses a 16 bit timer rather than ATMega328P’s 8 bit timer. Furthermore, the TI MSP430 has a low power draw features which allow us to consider the possibility of battery-supported operation.

Given the complexity of our prototyping and possibly high I/O pins requirement, we have selected Arduino Mega as our microcontroller.
Boundary Detection
There are primarily three types of sensors – tactile, proximity and visual – that fulfill the function of detecting a window edge. We evaluated these sensors based on three criteria: accuracy, range and ease of implementation. Accuracy refers to the sensor’s ability to detect the window boundary; a sensor’s range is evaluated based on its maximum and minimum operational range; the ease of implementation is dependent on the ease of processing the information a sensor returns.

By requiring direct physical contact with an object to trigger a tactile sensor’s response, a tactile sensor is deemed to be more accurate than a proximity sensor. The increased accuracy allows for more precise movement at the boundaries of the window. However, a proximity sensor has greater range than tactile sensor and provides additional information (such as the distance between the edge and the sensor). This helps us in fine-tuning movements near the boundaries

Visual sensors have the advantage of increased range as well as an additional capability of differentiating between a window edge and unexpected obstacles. However, the implementation of visual sensor is more complicated than tactile and proximity sensors, severely discounting its effectiveness and efficiency.

Based on the comparison, we chose to utilize tactile and proximity sensors for our robot.
Path-finding
To meet the project’s requirement of cleaning the window completely, there are several methods the robot can utilize. Such methods include a more thorough method, as well as a “search-and-clean” path-finding algorithm.

For the first and more thorough method, the robot will run through the entire window, cleaning every point regardless of the current cleanliness. On the other hand, another algorithm the robot can employ would be searching the window for dirty spots before cleaning it. The primary criteria used to evaluate these options would be the time required for the robot to complete its task. As the project requires the robot to clean at least 10 ft2 per minute, we chose the first method. This ensures the robot is able to consistently cover the entire span of the window within a certain amount of time over several runs.

In comparison, the search-and-clean methods require the robot to detect dirty spots before cleaning up the window. To accomplish that, the robot will still have to run through the entire window at least once. Hence, the search-and-clean method is deemed to be slower as the robot have to take on the extra task of analyzing the window for dirt.
Grip
Several methods of generating grip to the window were investigated and analyzed for their advantages and disadvantages with regard to the objective task. Possible adhesion sources include the use of gecko adhesive pads, suction cups, vacuum fan suction, and magnets.

Gecko adhesives pads are a biologically inspired synthetic adhesive that creates adhesion via van der Waals intermolecular forces. Gecko adhesives are advantageous because of their property of being directionally controllable. However, the disadvantages of gecko pads in terrestrial applications outweigh the advantages because the max shear, normal, and moment loads are an order of magnitude smaller than that of suction cups.

Suction cups are a more appealing alternative for gecko pads because they are also fairly easy to actuate and toggle between ON and OFF states whilst offering significantly more adhesive strength. However, suction cups can create a suction that requires significant pull-off force to disengage. This is highly undesirable for a climbing robot where a large pull-off force could destabilize the robot, causing the entire robot to fall off on the window.

An electric ducted vacuum fan (EDF) offers similar advantages to suction cups, such as high adhesive strength and ease of actuation.A vacuum fan offers the potential to be much faster than a robot that employs suction cups. A robot with EDF can use a much simpler wheeled locomotion strategy while the fan runs continuously to create a constant normal force into the window plane for ‘grip’. However, the EDF is unable to generate as much suction force as a static sealed suction cup can. Hence, a disadvantage of this method is that the robot will have to be very light weight.

The final option considered was the use of magnets to create adhesion to the climbing surface. There have been previous climbing robots that make use of electro magnets to climb. However, this constrains the robot’s climbing surfaces to strictly ferromagnetic materials (glass is not a ferromagnetic material). Alternative methods employing magnetic forces would require magnets on both sides of the window which would introduce further complexity and reduce real-world practicality of operation.

Thus, with all things considered, it was decided that the EDF vacuum fan would be used as the source of creating grip.
Movement
There are two main options to enable the robot to move about the window – a wheeled chassis or by suction caps.

The chassis consists of 4 wheels each driven by independent small brushed DC gear motors. The 4 independent motors will enable torque vectoring to drive forward, backward, and turn in place. Alternatively, treads could be used to generate a larger contact area between the robot and the climbing surface for better steering control. The trade-off for treads would be increased weight in the drive mechanism. Thus, treads are not ideal for an application where weight is a critical factor.

If the suction cup grip method was chosen, then 4 suction cups could be used in a ‘+’ configuration where at least two suction cups will always be engaged to the wall surface at all times. The pairs of suction cups adhered to the wall will alternate and the pair of suction cups not adhered will be slid up, down, left, or right relative to the adhered pair using two rack and pinion mechanisms.

With the use of the EDF vacuum grip method, the locomotion method can be simplified to a basic wheeled chassis. A wheeled chassis complements the choice of EDF as the main adhesion method, and enables the robot to have better mobility around the window.
Cleaning
There are two components to the cleaning subsystem. The cleaning subsystem requires a method to dispense cleaning solution onto the window. Without the cleaning solution, the robot might find it tough to remove certain stains and marks. On the other hand, there are also two different ways our robot can dispense the solution: continuous- or timed-release of solution. Our team decided to choose the latter method, as it allows the robot to minimize the usage of cleaning solution. Hence, this method reduce the amount of solution to be kept on the robot, and consequently reduces the weight as well.

Our team have also narrowed down the method of cleaning to three choices – bristle brushes, spiraling multi-brush, and a passive squeegee. A passive squeegee would be the easiest to install, but the resulting cleanliness leaves much to be desired. Hence, the squeegee is ranked the worst of the three methods. Between bristle brushes and spiraling multi-brushes, the level of cleanliness is deemed to be comparable. However, the spiraling multi-brushes are harder to actuate as compared to bristle brushes. Hence, our team decided that our robot will employ the bristle brush as the main cleaning method.

System Implementation

All the sub-systems have been successfully integrated together. There are three main aspects to the system integration.

1) With the IMU's input, we are able to calculate the robot's orientation. Once the IMU senses that the robot is placed in the vertical position, the EDF will be activated to adhere the robot to the window.

2) The path-finding involves making a U-turn at the window boundary. Each turn is controlled by a combination of IR sensor, IMU and encoders. Figure 6 shows the transition between turning states in path-finding algorithm.



Figure 6: Path-finding State Transition Logic with Sensors


3) To compensate for the off-course error, the robot utilizes IMU for greater accuracy. The basic PID loop was altered to incorporate the pitch angle and self-correct its steering to counteract the random drift that occurs during movement. Note that since the robot is moving straight only in the east and west direction during path-finding, the motor feedback is isolated to these directions.



Figure 7: Flow chart of RACER motor PID loop using IMU

RACER will be controller via one microcontroller – the Arduino Mega. Figure 8 below shows a picture of the Arduino Mega.



Figure 8: Picture of Arduino Mega


The microcontroller will implement a pathfinding algorithm to allow the robot to clean the entire window. Currently, the microcontroller is able to implement a naïve method of cleaning the window by controlling RACER to zig-zag across the window from a corner to another corner. Figure 9 below shows the initial route RACER will take to clean the window, starting from the bottom left corner.



Figure 9: Old Implementation of a Pathfinding Algorithm


However, after extensive testing, our team came to the conclusion that the above pathfinding algorithm is not ideal. This is due to the wheels slipping whilst climbing upwards, leading to inaccurate readings from the encoders. Hence, we decided to change the starting position of RACER, as well as change the direction it will move. However, as seen in Figure 10 below, the “lawnmower” motion of RACER is kept the same.



Figure 10: New Implementation of a Pathfinding Algorithm


To prevent errors due to wiring disconnections. we have created the circuit schematic and designed a PCB board. Regarding the circuit, the arduino and motor drivers are powered via an external power supply. The rest of the components are powered via the 5V output from the arduino. The motors and EDF are also required to be connected to the PWM pins. We have added in switches and push buttons to as external controls for the various functionalities of the robot. Figure 11 displays the circuit diagram for all the electrical components.



Figure 11: RACER Circuit Diagram


Due to the space constraint from adding a second EDF to the chassis, there was insufficient space to put a breadboard or circuit board on the chassis. Hence, we came up with the idea to mount a circuit board on top of the Arduino, creating an additional layer on top of the Arduino while providing space for RACER’s circuitry. Figure 12 below displays the proposed method of mounting the solder-able circuit board on top of the Arduino.



Figure 12: Mounting of Circuit Board on Arduino


We would solder extension pins onto the circuit board before attaching the entire board to the Arduino. RACER’s circuitry will then be soldered onto the circuit board. Hence, by mounting the circuit in such a way, we are able to save space on the chassis while ensuring the integrity and stability of the circuit. Figure 13 shows the PCB circuitry design.



Figure 13: PCB design for RACER

The updated chassis concept uses two smaller EDF fans placed and centered at the front and back of the chassis. Two smaller EDFs are used because it was determined that a single smaller fan could not produce enough thrust to achieve reliable and robust grip throughout all driving maneuvers on the window.


The video below demonstrates how a prototype v2 of our robot with a single EDF is able to cling onto a surface.

The original 4-wheeled drive was reduced to a differential 2-wheel drive. Both wheels are centered on the chassis and the passive cleaning structure on the front and back of the robot serve to balance the robot from pitching about its central drive axle. The decision to use a centered two wheel differential drive versus the 4-wheel differential was based upon the initial test results with the 4-wheel system. During 4-wheel drive tests the robot had trouble with grip because the system was much larger and heavier. In addition, the main acrylic chassis base was slightly warping or deflecting under the load of the EDF thrust and wasn’t evenly distributed among the wheels leading to slip in some wheels. This slip introduced significant drifting problems and also posed challenges when attempting to turn accurately in place. Therefore, by reducing the the number of wheels from 4 to 2, the system was able to be reduced in mass significantly and turning became more robust and was able to be executed more rapidly and in a repeatable manner. Figure 14 below shows a prototype of the window cleaning robot, with its two distinct wheel system.



Figure 14: Picture Displaying RACER’s Drive Mechanisms

Orientation Sensing

The adhesive force acting on the window will primarily be controlled by a PID controller. The feedback signals will be provided by 2 main components: a force-sensitive resistor (FSR) and an inertial measurement unit (IMU).

The IMU provides extremely accurate readings of the sensor’s current position. For instance, the IMU generates readings such as its roll, pitch, and its bearings. With the different results, we will be able to figure out if the EDF is providing sufficient adhesive force. The figures below shows a possible position of the IMU (Figure 15, left), as well as a computer visualization of its position (Figure 15, right).



Figure 15: Real-life position of an IMU sensor (left); Computer Generated Position of the IMU sensor (right)

Boundary Sensing

The boundary detection will be achieved using both an infrared sensor (IR sensor).

The IR sensor is used to detect the any obstacles in the direction facing the IR sensor. The sensor transmit the data to the microcontroller through variations of voltages, and the microcontroller will have to decipher the corresponding distance of the obstacle. Figure 16 below shows linearization equation used to calculate the real-life distance of the obstacle from a voltage reading.



Figure 16: Power Trend-line for IR Sensor’s Analog to Digital Conversion

The cleaning subsystem will consist of 2 main mechanisms – dispensing of cleaning solution and the cloth extension.

The robot will periodically dispense cleaning solution via a pump and nozzle onto the window. The cleaning solution was decided to be dispensed periodically to save on solution (and hence reduce the weight RACER is supposed to carry), as well as to ensure a relatively dry environment for RACER to work in. The video below shows the motor pump dispensing solution using a plastic tube. A microcontroller will be used to send a periodic signal to activate the pump (not shown in the video).



Figure 17: Pump Control Mechanism


In addition, this system consists of two cleaning plates that extend below the robot and make contact with the window. These extensions are identical in design, with one at the front of the chassis and the other at the rear. The first extension will complete the majority of the cleaning, and spreading the cleaning solution across the width of the robot. The second extension mechanism will remove any excess fluid and dirt that the first leaves behind. These mechanisms are a thin piece of acrylic with industrial strength Velcro on the top side. The cleaning cloth is doubled up, and wrapped around the acrylic and attaches to the Velcro.



Figure 18: Depiction of Cleaning Extensions

The power harness, seen in Figure 19 below, comprises of three 3S batteries connected in parallel, an emergency switch, and a 9 volts power supply. The power supply provides power for the Arduino, motors, and pump. The wires from the power supply are fed through an emergency switch, allowing us to kill the power to the Arduino immediately in the event of an emergency. The wires for the batteries are combined together in parallel so that we can provide a longer runtime (more amp-hours) for RACER’s EDFs.



Figure 19: Power Subsystem for RACER

System Performance

RACER has three different coolness factors – speed, having a small robot footprint, and utilization of EDFs. In addition, RACER was able to meet and exceed many of the project specifications.

The project specifications stated that the window should be cleaned in under 3 minutes, or at a rate of 10 ft2/min. RACER was able traverse a clean window in under a minute.

RACER has a width of 8 inches and a length of 10 inches. This gives racer a total footprint of 80 inches squared, or approximately 0.56 ft2, almost 25% of the required 2 ft2.

Lastly, RACER utilizes EDF as its method of adhesion to window. The EDFs had a loud hum that sounded like a jet engine starting up, attracting attention of everyone within earshot. The EDFs also added a visual “coolness” to the design.

RACER was also able to handle any windows size between the 3’ by 4’ and 5’ by 6’ window size specified.

RACER was also easy to adhere to the window and begin testing in under 30 seconds. Through the utilization of the EDFs, suction to the window was quick and simple unlike the use of suction cups, which required pressure to be applied to the window. Three sets of switches were implemented to initialize the different components of RACER. These include an IMU calibration button, an on/off switch and a pathfinding initialization button. RACER also has a set of five LEDs that indicate when it is in these different stages, as well as when the robot finishes, the LEDs flash in a continuous cycle to let the user know that it has completed cleaning.

During the demo, RACER did not perform as well as expected. RACER only achieved a cleanliness of 16%, which is well under the specified 75%. RACER showed high speed while it moved; however, it was difficult to determine its speed because of the four failures and restarts of the system. RACER was able to adhere to the window effectively, but it was not able to retain the desired frictional force to the window; hence, RACER experienced a large amount of slippage while on the window. The low friction to the window by the accumulation of dirt on RACER’s wheels proved to cause large issues in its locomotion. The wheels slipped so much on the dirt that RACER would slide down more than it moved forward. RACER was also unable to complete a successful turn because of the slipping.

However, even though the slippage was a downfall, the cleaning done by the microfiber pads proved to be effective. RACER removed all the dirt that it passed with the wetted cleaning pads. A cleaning mechanism was implemented for the wheels, but it only increased the amount of the window RACER was able to clean from 16% to approximately 20%. Overall, the team saw this demo as a failure.

We have conducted an initial testing of the controller logic of all the sub-systems on the floor. RACER has successfully achieved all testing objectives as listed below:

1) Successful activation and coordination of all sub-systems

2) Precise detection of window boundaries

3) Controlled turning of the robot during U-Turns

4) Off-course compensation during straight paths


The video below shows a successful trial run of the robot conducting path-finding on the floor.



EDF has successfully generated sufficient output thrust to keep RACER adhered to the window. With the EDF activated, RACER is capable of moving on the window without losing suction.



During 4-wheel drive tests the robot had trouble with grip because the system was much larger and heavier. In addition, the main acrylic chassis base was slightly warping or deflecting under the load of the EDF thrust and wasn’t evenly distributed among the wheels leading to slip in some wheels. This slip introduced significant drifting problems and also posed challenges when attempting to turn accurately in place. Therefore, by reducing the the number of wheels from 4 to 2, the system was able to be reduced in mass significantly and turning became more robust and was able to be executed more rapidly and in a repeatable manner.

IR sensor: From tests in sensors lab, we managed to achieve accuracy in the IR sensor’s readings up to the centimeter. However, there is a great increase in noise signal when the closest obstacle or boundary is greater than 50cm. However, that does not affect our system as the maximum distance reading required is 30cm.


IMU: In addition, from another systems test, the inertial measurement unit (IMU) is able to calculate and transmit orientation and bearings up to 0.01° accuracy. This is far better than we expected, as we only require accuracy up to the degree.

Pump Control: The current motor pump for the cleaning solution is able to dispense solution with varying speed based on the input voltages. With increasing voltages (minimum of 6V, capped at 20V), the motor is able to speed up the rate of pump. However, since we have decided to control the frequency of the pump via the microcontroller, the solution dispenser can also be powered via a battery instead of a varying voltage source.


Cleaning Efficiency: Though initial testing of the microfiber cloth on the chassis, without using the cleaning solution, the cloth was able to remove a majority of the dirt from the window. After applying Windex to the window, RACER was able to remove all the dirt in the area the Windex was applied. Testing with mixing isopropyl alcohol with the Windex showed that mixing the alcohol into the solution provided for a quicker evaporation of the solution from the window.

To ensure that the power supply is capable of lasting the entire cleaning operation for the window, we decided to test how long the batteries could power the EDF. The batteries are capable of supplying power for at least 7 minutes of continous operation.


We have also tested the emergency switch to ensure that all power is cut appriopriately in emergency. It worked 100% and takes 30 seconds for the EDFs to wind down. We agreed that this meets our safety requirements.

Schedule

Week Date Milestone(s) Task(s) Presentor
2 19-Jan Design Conceptualization
Complete design concept proposal
Complete preliminary CAD sketch		 -
3 26-Jan Design Concept Proposal (M) Order parts (EDF + test rig)
Build mock-up design
Complete sensors lab		 -
4 2-Feb Mock-up Demo (M)
Sensors Demo (W)		 Create detailed software architecture
Create website template
Complete motor control lab
Experiment with EDF and Grip subsystem
Finalize CAD design		 Telson (Mock-up Demo)
Nicholas (Sensors Demo)
5 9-Feb Motor Control Demo (W) Integrate content into website
Begin fabrication of chassis, locomotion and grip subsystems
Begin writing locomotion and grip subsystem software		 Simon
6 16-Feb System Demo #1 (W)
Website Check #1 (F)		 Continue fabrication
Begin testing of movement on glass at different angles		 Foo Lai
7 23-Feb System Demo #2 (W) Complete prototype #1: Functional locomotion and grip subsystem with IMU feedback
Prepare for design presentation		 Joshua
8 2-Mar Design Presentation (M/W) Begin writing boundary detection subsystem software
Integrate sensors onto the chassis		 Team
9 9-Mar Spring Break
10 16-Mar System Demo #3 (W) Interface boundary detection software with locomotion software
Begin fabrication of cleaning subsystem		 Telson
11 23-Mar System Demo #4 (W) Complete prototype #2: Functional boundary detection
Begin writing cleaning subsystem software		 Nicholas
12 30-Mar System Demo #5 (W)
Website Check #2 (F)		 Updated final CAD design
Continue fabrication for revised subsystem
Finalized PCB design
<Integration and testing are delayed due to EDF damages> 		Simon
13 6-Apr System Demo #6 (W) Complete prototype #3: Functional cleaning subsystem
Finalize integration of circuits onto the chassis
Begin testing of entire system 		Foo Lai
14 13-Apr System Demo #7 (W) Continue testing and tuning of machine and system
Complete final product		 Joshua
15 20-Apr Final System Demo (W) Prepare for demo Team
16 27-Apr Final System Demo Encore (W) Begin writing final report Team
17 4-May Public Presentation (W)
Final Report (F)		 Complete final report
Complete website content		 Team
18 11-May Website Check #3 (M) Lab cleanup -
Weekly Update website content based on project progress
(M)/(W)/(F) refers to the day of the week the assignment is due.

Issue Log

Parts List

Video

Lastest Updates
__________

After a series of conclusive tests using the RACER platform under competition conditions, it became apparent that RACER was not able to execute near perfect runs in its current design. The major problem causing failure in adhesion and locomotion was the window dirt, which dirtied the silicone tires and significantly decreased the friction between the robot and window. Our team decided to go back to the drawing board and created a prototype of a completely new concept - CLIMBER. Developed in just under 2 weeks, this robot uses many of the same components used on RACER but in a different operating configuration.
__________

It's performance capabilities exceeded RACER and achieved an astounding first in a competition.

 

Picture Gallery

Photos of our team and RACER at various stages of the development.

Our team

We're a team of 5 from Carnegie Mellon University, comprising of

3 Mechanical engineers and 2 Electrical and Computer(ECE) engineers.

Documents

Documents for easy reference in order to track project progress and examine project details.

Viewing Permission. Viewing access are granted to authorized accounts only. Please email fchoo@andrew.cmu.edu for permission.