[WIP] Creating a Drawbot Controlled by a Myo Armband

Hello all!

A few months ago, we decided to try and tackle the idea of building an open-frame drawbot which only used a Myo band to control it. When we first set out on the project, we knew that it would need to be broken up into a couple different phases. Our first main phase was to try and wrap our heads around an open-frame design for our draw bot. This is a nonstandard setup, and we wanted to see what the benefits of this design were.

Second, we knew that building this prototype would only prove useful for ourselves. Our design and plan was to move our final frame into metal, and using an arduino, receive our position from the accelerometer and gyroscope built into the Myo band. That information would then be sent to the motors, and would replicate the user's motion. We knew that this would make our second phase break out into three main aspects:

1. programming from Myo to motors, through the Arduino
2. electrical design to translate our data into motion
3. mechanical design to create a reasonably sized frame that will facilitate our motion

Each member on our team felt most comfortable with a unique part of our design process, so we decided to break our work up among each person. We also kept up a blog during our entire design process to track our day by day thinking, as opposed to a more global look.

Our goal was to combine these two products in a way that we have not seen either used before. We set out to make a live relay between our Myo armband and our own version of a design inspired by Evil Mad Scientist's AxiDraw.

2 2 x 4 wood boards
1 Belt or chain measuring >= 65”
4 Wood nails
3 Gears with teeth that fit the belt or chain
4 3 x 8 vex perforated plates
30 ⅜” Rubber spacers
8 1” diameter washers
1 1” diameter wooden dowel 1’ long
8 Vex screws 1”
8 ½ ” Vex screws
8 2” Vex screws
8 ¼” Rubber spacers
48 Vex nuts
1 Small zip tie

We grabbed two 2x4’s and cut them down to equal lengths (33 ¼”)

Using a table saw we made a notch along side the narrow part of the boards ¼” deep and ⅛” wide in the middle

Cut the dowel into 4 2” pieces and drill a hole in the middle of the dowel about ¼” in diameter using a drill press

Ideally we would use two 7x7 pieces of vex perforated steel but all we had available to us were the 2x7 strips so we bolted them together in an “X” configuration

Stack 5 of the ⅜ ” rubber spacers and secure the corners of the vex plates to each other

Loosely secure the wooden dowels as shown in figure 1 so that they spin freely with about 2” of space between them use the picture to see where the gears should be positioned at this point we used washers but later found that tiny plastic vex gears work better.

Using the ½ “ vex screws, ¼” rubber spacers and 1”diameter washers secure the washers in an elevated position as shown in figure 1 ( we used green plastic gears because we couldn’t find the right washers) make sure the washers are able to spin easily and fit into the notches of the board.

Place a board on a surface and slide the carriage into the middle so that the washers hold the carriage above the board and on either side of the board nail the gears down so that they spin freely. Nail a gear to one end of the second board making sure it’s centered and slide it onto the carriage perpendicular to the first board.

Now the belt must be looped through the system as shown, pay careful attention to how the dowels are on the outside of the belt and how there is nothing in the center of the chassis that could hinder the belt while it is moving.

Now the belt needs to be fastened on the side of the board that doesn’t have a gear. We used an extra nail and zip tie to fasten ours. But the method used does not matter as long as the belt is anchored in that spot

That should be it, pull the belt in different combinations and see the different effects it has on the arm!

Once we completed our prototype, we were ecstatic. None of us were sure how the system worked prior to assembly. But, once our parts came together, we quickly discovered what we liked and how we would improve it when creating the final design. Our main complaints with the system to resolve were:

1. Scale
   1. Our prototype was massive and unwieldy, which made it prone to tipping over at the edge of our arms
   2. The carriage was much larger than necessary, and it had a lot of wasted space
   3. Our belt (a vex tank tread) was much larger than necessary, which introduced excess space between arms
2. Friction
   1. Our vex treads did not pass over the wooden dowel rollers easily at all points
   2. Plastic on wood made the carriage unwilling to move in many cases
3. Motorizing
   1. We needed to make the system power-able

With these things in mind, we drew our plans for the final design. We wanted the drawbot to be controlled with a Myo via an arduino, and we wanted to make the frame aluminum and smaller.

In order to do this, we took a percentage of our original prototype, and set out to work from that size. By using sheet metal that would be machined to have channels wide enough for a shielded bearing to pass through, we would have a light yet robust design that would have higher use tolerance.

Our prototype also allowed us, in only a few minutes, to determine how the motor rotation affected the head of our drawbot. This lead us to understand that our control design would be more simple than we had anticipated. Upon closer inspection, we figured out that the motor's movement is additive! This means that each motor has an independent desired effect upon our motion, but when we combine them together, they begin cancelling out.

For example, if considered like a coordinate plane, the motor laying in the negative x extremity will always tend to pull our drawer into the second and fourth quadrants. Conversely, the motor laying on the positive x extremity will always tend the drawer into the first and third quadrant. If we combine the motion of our motors, it will cancel the portions of directing that conflict, and will amplify the portions that agree.

While I worked fairly extensively in C a few years ago, I had no experience with lua or C++, and this meant I needed to spend an appreciable amount of time looking through documentation. I knew that the general task that I would be trying to accomplish was getting the position of the user in intervals of time and then passing it to the motors. I decided to break the task up for myself to better digest the parts that I would need.

1. Get Data from Myo (lua)

I knew that I needed to figure out a way to collect the information from the Myo. This was the first part of the challenge I wanted to approach. To do this, I wanted to have the user calibrate their canvas size before starting to draw. This would allow me to have a boundary to work from. I could then normalize the program between different users by simply taking a percentage of the maximum canvas as my data points to pass. I decided to have a scripted event that would do a getOrientation check every half of a second, as it would allow the checks to never perform a wild jump that you would need to guess from (for instance, if the user was swinging wildly back and forth).

This made the first roadblock I hit. I discovered a very large limitation of lua, and that it would not allow me to wait before continuing the script. The only way to perform this action was to either pause the CPU (which would pause it globally, even holding the system clock), or to use OS specific commands. In my example code, I left in the original OS check that I performed (commented). This was after doing a large amount of research in lua's documentation, and was done by checking the system path formatting. This was when I decided I needed to look at the documentation for projects that had been published prior. I realized immediately how much time I wasted, and was immediately lead to the platform variable. With it, I was able to implement OS specific waiting commands almost immediately, as opposed to the days it took me to cobble together my previous solution.

It was around this time of design that work on the electrical aspect began, and I suspended work on this aspect of the code. The intent being to learn how our motors interfaced with the arduino.

2. Working Around the Arduino (C++)

As work with our breadboard became increasingly more complex, I learned that the arduino was incapable of multithreading. This was a large wrench in my original code design, and after reading more about the limitations presented with our controller, I found out that I would need to program in how the arduino would switch between the two. This became the focus of my efforts as our deadline approached. I had to scrap large portions of my original script as they were designed to write data to a file synchronously with the motor controller reading the file. This was to allow for a queuing function to make sure that even if the user was ahead of our drawer, it would not ruin the project.

I decided that the queuing function should be saved, if not implemented the same way as before. In order to do this, I created a vector of arrays. This allowed me to not only keep the spirit of my previous design relatively intact, it also meant I didn't have to keep track of my place in the file for either reading or writing. Instead, now all I needed to do was simply add a new value into my vector if the user was moving (preliminary testing was less than 1% of canvas size difference in both x and y from last recorded position resulted in no recording of data). I could then take the oldest value in my vector and in one fell swoop, send it to the motor control, write it to our file, and then remove it from my vector. This cleaned up a lot of my concerns about having a constant IO stream running.

While I have taken an electronics class in the past, and worked a fair amount with arduinos. I have never dove deep into making the arduino receive information from an outside source (myo), I only have experience outputting information through the arduino. However, I took to wiring the motors on our drawbot, and working on code for them to be able to work with the myo code.

Materials that I used:

2 x Stepper motors

1 x Breadboard

1 x Arduino (Uno)

2 x Driver IC L293DE

40 x Jumper wires

2 x Fans

1. Connecting Stepper Motors and the Fan to the Breadboard

Following the circuit diagram, we can wire one stepper motor to the driver on the breadboard. Then, following the same diagram apply that to the second driver and motor, however, the jumper wires will have to be plugged into a different set of pins in the arduino (since the first motor is occupying the space of 4 others).

Warning/Tip:

The drivers are very small and the pins are very close together. It would be wise to space out the two drivers so the wires do not get confusing.

Next is to wire the fans. This is fairly simple, the fans that I had available were basic computer processor fans, which have a positive and ground. Plug those two into their respective +/- pins on the breadboard, and angle each one towards each driver. (We found that because the stepper motors are receiving bursts of information and commands over a long period of time, the drivers tend to overheat and smell. Adding a fan to cool it fixed this issue).

2. Arduino Code

This is the easy part!

Open the Arduino IDE go to the “File” tab then drop to the “example” tab which will drop down even further and show you a “stepper” tab Then you want to open “Stepper_OneStepAtATime”

This will preload an example code that is almost plug-and-play to the arduino/motor wiring. We will have to make small adjustments because we will be running two motors, which I will show down below. You may also have to make minor adjustments depending on which pins you have decided to use, since the Arduino IDE defaults to pins 8-11.

The code that I have used to make the two motors move in “sync” is below:

//#include

const int stepsPerRevolution = 200;

Stepper myStepper1(stepsPerRevolution, 9, 10, 11, 12);

Stepper myStepper2(stepsPerRevolution, 4, 5, 6, 7);

int stepCount = 0;

void setup() { // initialize the serial port: Serial.begin(9600); }

void loop() {

myStepper1.step(1);

Serial.print("steps:");

Serial.println(stepCount);

stepCount++;

delay(0.5);

myStepper2.step(1); delay(0.5); }

3. Possible Problems

Issues that I ran into during this process was not using the right code example, using a bad jumper wire, using the wrong driver IC.

• Make sure that your driver that you’re using is capable of controlling a motor.

• Check the serial number and check its specs.

• I ran into a problem of having a dead jumper wire, which caused my motors to spin strangely.

• I had to use a multimeter to check every wire.

• And always double check your code for small errors like missing an end “;” command.

1. Material

For the full production model of the arms it's recommended that they are made out of strong yet lightweight material, we felt that aluminum was a perfect fit.

We used 032 gauge aluminum sheets cut to 9.125" x 17.5" and traced the pattern from the drawing shown in the previous step.

2. Fabrication

Using the hemmer (the blue machine) we added hems that face opposite directions so that when the piece is broken and folded, the two hems would interlock forming a single complete piece.

For the large bends we used the tennismith, because of it's high precision.

Now for the smaller bends, you're going to want to use a machine with a smaller foot, this is where a machine like the roto-die comes in. Because of its smaller foot, it allows for smaller breaks to be made, unfortunately, the roto-die at our disposal was still too large for our rail and it was deformed.

**Alternatively, if you don't have access to the proper equipment or tools, then a substitute can be made.**

In our case, we cut our arms from aluminum solar panel rails using a plasma cutter and grinded the ends smooth then bolted them back to back to make a double sided rail system. Ideally, we would want to weld the rails together, however, without access to a welding station we instead clamped together the rails and drilled through then bolted them together. But if this route is taken, then special care should be made to use a lock nut and washer to ensure that the piece has as little flexing as possible.

3. The Belt

For the belts we used some old 3D printer belts that we were able to salvage.

The belts weren't long enough initially so using some heat shrink tubing we combined two pieces to make one that would be adequately long.

The green gears and wooden dowels were replaced by disk bearings with extra wide washers used to keep the belt from slipping out of place.

4. Carriage

And finally the carriage was made of a 5" x 5" sheet of 032 aluminum, with holes drill pressed where the corresponding screws and washers are meant to go. The distance will vary depending on how wide your rail is and how much clearance you have on your washers.

Unfortunately, every side of our project ran into the major barricade of time, and we were unable to complete our design by our target date. Each member of our team ended up collaborating in every other aspect of our design to at least some extent, leading to some learning curve time sinks. This, coupled with the want to design a product with as little outside resources as possible (as we all wanted to create our respective parts from scratch), lead to a great amount of reinvented wheels.

Everyone that worked on the project learned more about the other aspects of the project. Making software do a specific action is one thing, then to make software work together with hardware is another. I would say that it is important that whoever is working on the coding aspect of this project, be as familiar as our project coder.

Overall, we were not able to achieve exactly what we wanted to. However, I feel that we were on the right track and we all discovered and learned new concepts that we will be able to apply to future projects.