Mobile Thermostat Log

Log for 2/10/2016

I’ve known since the end of the fall semester 2015 that I would be doing an independent study with Dr. Gonzalez during the spring semester of 2016 to finish my Master’s in Robotics. The question was: what is the project? Initially, I was interested in using computer vision to recognize when a plant was fully grown or to categorize different types of cells and fungi under a microscope. But after talking with Dr. Gonzalez, it seems like these projects would be too far out of my scope of knowledge to complete in a single semester. Other proposed ideas included an underwater mobile robot and a seed planting mobile robot. However, Dr. Gonzalez suggested a mobile thermostat robot. The robot would sense environmental data (temperature, humidity, barometric pressure) and move around the room periodically (every few hours) to gather more data about a given room’s environment. The preferred method of locomotion for this robot was using legs instead of wheels. To be honest, I’m not sure why Dr. Gonzalez prefers legs over wheels in this case yet.

This was decided on January 27th and after getting approval from my advisor, I’m all set to work on the project. Since the 27th, I’ve been researching methods of using legs to move a small mobile robot, ways to wirelessly communicate to an external processor (whether that is a mobile phone or a PC), and trying to figure out the best way to go about motion planning. The following table shows my locomotion options and the pros and cons of each.

Locomotion Method	Pros	Cons
Klann Linkage	Relatively simple mechanical complexity, requiring very little kinematics design. Only two motors required (continuous rotation), minimizing the total power consumption of the robot during locomotion.	Accurate knowledge of relative position requires additional sensors.
Jansen Linkage	Medium mechanical complexity. Only two motors required (continuous rotation), minimizing the total power consumption of the robot during locomotion. Self-contained platform module could hold all electronics.	Accurate knowledge of relative position requires additional sensors.
Spider 3-link legs	More accurate control over speed and position, as well as more flexibility. Opportunity to design control system and kinematics of 3-link arms.	Each servo requires ~0.3 amps for full torque and there are 12 servos for 4 legs: a total of 3.6 amps during locomotion. Designing a control system and kinematics of a 3-link arm adds to mechanical complexity. Requires accurate knowledge of each servo’s position.

Each method has 3-D printer plans available online. I would have to do only slight modification to each. Generally, you want to be able to forget about the existence of the thermostat in your room, so minimizing power consumption of the mobile thermostat is a major objective so the user doesn’t have to think to recharge the robot as often. For this reason, the Klann or Jansen linkage systems outweigh the spider robot.

The point of this project is not to design a clever mechanism to allow for a small walking robot, so I’ll be using the pre-designed plans available on “Instructables” for the chassis of the system. I’ll be able to focus my attention on the other parts of the project (i.e. the electronics, software, and algorithms). The “Instructables” includes CAD files so I can 3D print the chassis and order other necessary parts.

Log for 2/14/2016

With the chassis and main motors for the system chosen, I must also decide on the computer that I’ll use to run the system. The robot will have to do motion planning and localization (possibly with SLAM), data interpretation, and wirelessly transmit data. From my own experience, I can think of two feasible options:

1. Use an on-board computer with an ARM processor (e.g. Raspberry Pi or Beaglebone Black) to do all of the processing and decision making. Wireless transmission will only contain environmental sensor data and robot position.
2. Use an on-board microcontroller with considerably less processing power (e.g. Arduino) and wirelessly transmit all pertinent data to an external ARM processor or to a PC to do the heavy processing. The on-board microcontroller will only interpret received data and transmit all sensor data. An external processor will do all processing for motion planning and data interpretation.

Like with the decision on the method of locomotion, I must consider the battery life of the robot. Any on-board processor that uses an ARM processor or anything more “heavy-duty” will use much more power. For example, the Raspberry Pi models’ idle current draw is between 200-420 mA, depending on the model. The exception is the Raspberry Pi Zero, which can idle at 65 MA. However, the processing for motion planning will require the on-board processor to run much higher than idle. The current draw at full processing for any Raspberry Pi will be greater than 1 A. In contrast, an Arduino Uno will idle at ~50 mA and additional current draw scales by ~20 mA with each additional I/O pin. Considering power consumption on the mobile robot, option 2 will yield better results.

Using option 2 may result in less power consumption, but relying on wireless communication for a data transfer, including motion planning, may prove to be a disadvantage. I have very limited experience with wireless protocols, so as I develop the system, I’ll have to do more research to find ways to ensure all data transfers correctly. No matter the wireless protocol, I’ll have to write some program for the external processor to interpret the data.

Log for 2/15/2016

The project proposal should be finished and reviewed this week by Dr. Gonzalez, so I’ve selected components to add to the budget. I’ve decided to use Wifi for wireless communication between the Mobile Thermostat and the external PC. I finished the project proposal in addition to the budget. I included the main objectives, the methodology, and the expected challenges. I plan to discuss the project with Dr. Gonzalez on Wednesday, Feb. 17th.