Plex Bot

I love robots! Humanoid robots are my favorite. Sine I was little I loved the idea of a toy that you could play with while at the same time it looked like a human. Emulating the human form is the goal of humanoid robots. It would be a lot easier to make a four legged robot that is already balanced than making a humanoid robot balance. If I push on the robot it falls over. The challenge with these robots are also an opportunity. The pathway to making robots that interact with humans on a human level lies through humanoid robots. As science fiction movies point out, the future of robots is humanoid. I think this is the case not because of a superiority of the human form over all others absolutely, but one of personal preference.

This bring me to the Plex Bot. Right now he only has legs which technically makes him a biped robot and not truly humanoid. His shoulder joints are in place of arms, which makes him humanoid in thought. The design of the robot is a copy of PlanMini v5. This robot is from thingiverse user Shin Wei Chiou who did most of the hard design work of making the robot look and operate the way it does.

Step 1: Plex Bot, Design

All of the design files are available on Thingiverse. I modeled all of the parts in OpenSCAD, which allows for a lot of changes to be made in the future. If I wanted to use another servo then it would be relatively painless.

Let's start with the servos. Each servo has a backplate that helps support the weight of the leg. A bearing mounts onto the backplate in line with the servo horn. From there each servo has a box that the backplate attaches too. This is the main reason I redesigned the whole thing; my servos were too big and would not fit the original models. OpenSCAD allows for the design to be parametric so I could change the servo size in the future with minimal work.

The servo has two brackets coming off of each side, one attached to the servo horn and one attached to the backplate. Because OpenSCAD is parametric, all of the joints that connect the servos together are longer copies of the original size. This makes it very easy to change the sizes for each joint. I want the robot to be as small as possible for weight just as much as aesthetics. This leads to making some joints that can move forward a full 90 degree and backward only 40 degree. This is fine for a robot and for humans. Most of our joints do not use 180 degree of movement so the robot does not need to either.

Step 2: Plex Bot, Parts

Right now the robot is not complete. I want things like a head that has the ability to see objects around it. Robots also need the ability to tell their orientation in space to which an accelerometer and gyroscope would become useful. The parts list that is currently on the robot is what is listed.

• 10 Turnigy TG9e micro servo
• Adafruit 16 channel PWM I2C driver
• Teensey 3.1
• 8x2 Character LCD (from eBay)
• 7x4x2.5mm Bearing MR74ZZ

• M2 screws 5mm

Choosing Each Part:

Servos:

The TG9e is a very cheap servo. $2.34 is great because the final robot needs at least 16 of them. I say at least because I broke 5 of them while building the robot and programming it. I would recommend getting more than you need when they are this cheap. In retrospect, I might have chosen the HXT900 as it has more torque and better longevity. The legs require 5 servos per leg, 10 servos total. The arms need 3 for each arm, 6 servos total. Overall that is 16 servos. I want one servo to be on the head so 17. Don't forget to get spares, I would get more than 20 if you plan on building this robot.

A more robust robot would have better servos. These servos are pretty bad and I only recommend them because they are so cheap and small.

Servo Driver:

This is not a servo shield. The IC that is on this is on the board is meant to drive LEDs at 12 bit resolution. It will work for driving servos but I do not like it. Sending signals to the board requires I2C rather than controlling the pins directly through the microcontroller. This means more work to get the system up and running. The biggest problem driving the servo using something meant for LEDs. Servos require high and low pulses that it reads to determine the position you want it to move to. You set the board to output at 60hz and then send it a signal between two variables, servo min and servo max. The min and max are the pulse length that will be on and determine how far the servo moves. Overall this is not too bad but it is a lot of steps. I would like to use an Arduino Mega board that has the ability to drive many servos without the need of a separate board. However, this would take a lot of compute time on the 8 bit microcontroller.

Microcontroller:

The Teensey 3.1 is only $20. It is a 32 bit microcontroller with a lot of I/O. I choose this board because it is very versatile. It has multiple SPI and I2C ports, lots of analog inputs, and many PWM pins to use. The clock speed for the board is 96 Mhz which leaves the Arduino in the dust, at 16 Mhz. All this becomes important when I connect new things to the Teensy. Connecting a 9 DOF accelerometer and gyroscope is easy and the board has the processing power to use the data. I can connect SR04 module and the LCD without worrying if the code will slow down. All of this on top of the many more things are the reasons I am not using the Teensy for like its ability to play sounds natively at 12 bit resolution.

Other:

The LCD fits into this category. The LCD is very useful for debugging the code; when the Teensy is connected to the positioning program the serial port is no longer able to debug. So we can debug with the LCD. It also will make a good UI for selecting different programs to run.

The bearings I use are small and can be found on amazon or ebay.

The screws are tiny. They need to be small for the size of this robot. I get my screws from Mr. Metric in the US.

Step 3: Plex Bot, Coding

All of the code is hosted on GitHub.

I think this is the most interesting part of creating the robot. I have seen a lot of arduino code for robots. Most of the code is very stupid. I do not mean this in a mean way to the code or the creator; the code is just not very versatile. I could attach 10 servos directly to my microcontroller and bang out the command to them in the most direct way possible. This way of doing things is nice because it is simple. It is easy to understand what is going on and easy to use.

Arduino is based in C++ which means objects are inherent in the language. Objects make a program nicer to use. Rather than attaching the servo and calling that each time I want to move a joint I create objects that do so much more.

The class that handles servos is rServo for robot servo. This declares where the servo is. It also takes care of moving the servo to different positions. The class also has constraints on how far it will let the servo move. For example, the ankle has a range from -15 to 25. This is a physical limit to the range of the servo and is also software constrained to prevent damaging the robot. The class also handles an offset for the servos. The horn is not always at 90 degree where we want it to be. Adjusting this in software allows for the robot to be perfectly straight even though at the center of the servo it would not be. One last feature of the class I never used was the timing. Each servo has a min and max pulse timing that can be changed. This would only be used if there was an oddball servo that needed a different value than normal.

Controlling each servo on its own would be a pain. This is why the leg class exists. Leg creates 5 rServo objects and is in charge of moving that leg and assigning offsets. This allows for an array of 5 to be sent to the servo and that is translated into movement of those 5 servos. Each leg also knows if it is the right or left leg. This is important because the values of some servos need to be mirrored. The code for the legs looks something like this:

Leg right = Leg(rLegAddress, true);

right.leg({0,10,15,0,0});

Step 4: Plex Bot, Movement

Making the robot move is as simple as changing the position and updating the servos. Making the robot walk is a lot more complicated. Posser is an application that is part of the ROFI project. It gives the user a GUI for posing the robot and creating action steps. Before using this application I wrote each step in a spreadsheet and copied that into the code. Visual feedback was terrible because I needed to reflash the code every time I wanted to move the servo. Poser allows me to make changes to a step and see that change in real time. This is very important when balancing a robot. I can also adjust the speed of each movement in Poser. all this makes walking a lot easier.

This is about my 5th attempt to make the robot walk. It finally moved without falling over. The stuff on the bottom of the feet is Gorilla Tape, the big brother of Duct Tape. PLA is has a lower coefficient of friction than the more rubbery tape. This makes walking a lot less like a duct on ice.

Step 5: Plex Bot, the Future

The biggest thing I want to add to the robot are the arms and head. It doesn't feel whole without them. The robot also needs better space management. All of the components do not fit inside of the shell I created. The robot still needs room for a battery to make it mobile. Once the body of the robot is done than I will move on to upgrading the rest of it.

The robot needs to have wireless control. I plan on adding Bluetooth and controlling it with a PS2 remote.

The robot needs to balance and respond to outside input. This would involve connecting the 9DOF board I have to the robot. It is not that simple though. In order to work well the those raw data values need to be converted into values that the robot can work with and then it has to know how to respond to changes that are not expected. If it is falling backwards than it should move forward. But what moves forward? The hips or the ankle can move but how much and which direction. All these question involve lots of states that the robot could be in and how it needs to react to those. If I want the robot to do push-ups then it would be in a different state than being standing and walking. I would do an inverse kinematic calculation for where the limbs should be and use that to position the robot through a series of stages. Even at 96 Mhz I don't know if the Teensy would be able to compute that or if the code for that is feasible for me to create. I think adding the gyroscope to the standing routine would be useful and simple.

I plan on adding a rotary encoder for a GUI like that of the RAMPS board.

The robot needs some status LEDs and switches for turning battery power on and off.

The head of the robot would do well with a SR04 to give basic spatial feedback and allow for autonomous navigation.