MTM / BILL-E 1.5
This project started as a universal robot arm (a UR.1)- the idea was to modify BILL-E to the point that it would behave as such, and, at the same time, migrate the motors and control system to Jake's small rotary, so that adding joints, modifying control and so on become easier and generalizable. As timed passed, I was completely overwhelmed by the building process of the project and couldn't complete the UR.1 side of the project. But the new BILL-E, BILL-E 1.5, is here.

Stuffing Boards

In order to control this version of BILL-E, we will be using Jake's Small Rotary board. In this phase of the project, I learned much about how bad I am in board stuffing - only about half of my boards ended up fully working (although only one was a complete failure). The whole process of stuffing, getting started on programming and iterating between hardware and software to debug took me about one week and half.

Upgrading (cof) BILL-E

Amira redesigned the original BILL-E to account for the new motors and boards. Here's how the new version looks like: And after a ton of rearranging, updating the files and 3D printing: The purely mechanical model looks like this: And here's the stuffed version

Motors + Programming + PID

The next step was implemeting a version of PID in order to control the angles. The specification that Amira and I had set up was that she would handle me (angle, joint) tuples from the web side, and I'd be responsible for the system response. We first set up a simple system with Jorge's boards and components. Here's the first version of that code:

We had much trouble implementing the actual PID control, mostly due to Coulomb friction. The P (proportional) and D (derivative) parts were pretty straight forward, and behaved as expected. However, the motor had a threshold PWM of 40, and below that value it simply wouldn't respond. Above the value, however, it would be too quick. This means that our integrator term would add up until it the resulting PWM is above 40, and then would overshoot to the other side of the error. In most systems, this overshoot would decrease exponentially with the sinusoidal evolution of position - but in our case we couldn't eliminate this overshoot.

Hence, as of now, Ki is a zero term in our code. It is not a generally bad control, and has an error of about +/-3 degrees in Jorge's motor (BILL-E has a ton of backlash, so it's worse). After that, I started playing with the BILL-E system. In particular, I wrote a small piece of code and hardware specification