Robot Arm


by Addison, Emily, Jack, and Yi Ying

What did we make?


This is a robot arm that can be controlled through the internet. Originally, it was mechanically controlled, but we modified some parts and added IoT boards to make it remote controlled. We used Adafruit IO as our MQTT service to relay control signals. On the Adafruit website are five switches, one controlling each of the five motors, the finger, wrist, elbow, shoulder, and base. There were three modes to the switch ~ -1, 0, and 1 ~ and if activated the arm would move backwards, stop, and forwards, respectively.

Steps


  • Step 1

    Modifying the Robot Arm

    This robot arm was first mechanically controlled. To make it remote controlled, we replaced the original board with the NodeMCU board.

  • Step 2

    Wiring

    Initially, we used the motorshield to control the motors and hook up with the NodeMCU. After we figured out that didn't work, we used an IC chip called L293D. Each chip could control two motors, but there was a problem -- every motor needed three pins (a speed pin, input 1 pin, and input 2 pin). We had to control five motors for this project. As a result, fifteen pins had to be used! The NodeMCU clearly didn't have enough pins, so we needed another solution. A new wiring method was made. In the wiring method, two long bus wires were used to control all the input pins. This way, we only needed two pins instead of ten pins to control the inputs.

  • Step 3

    MQTT Integration

    In order for the robot arm to be managed over wifi, we have to include a system called MQTT. MQTT has three parts -- the MQTT itself, a publisher, and a subscriber. The publisher puts out a message into the MQTT system, and whoever is registered to the right channel (subsciber) receives the message. For the robot arm, Adafruit IO's dashboard sliders are the publisher. We publish a mode for a certain joint (ex. wrist, -1). This is sent to the MQTT, then to the subscriber. The NodeMCU in the robot arm is the MQTT subscriber in this project.

Boards


NodeMCU

NodeMCU

The NodeMCU is our main controller. It's very similar to an Arduino, as it can control motors and be programmed using the Arduino software. This board can connect to the wifi and internet, providing use to the IoT system.

L293D

L293D

Orginally we planned to use use a motorshield, but it could only control two motors, whereas we needed five motors. The L293D (IC chip) can drive two motors, so we used three of them to provide controls for five-six motors. Due to their small size, it was more convinient to use these than the motorshields.

Motorshield

Motorshield

Like we said before, this was our first plan of controlling motors. However, the size of the motorshield was pretty big and they were unstackable. That means we can't stack them on top of each other, so we'd have to buy a separate NodeMCU board for each motorshield.

Challenges


Despite completing the hardware and software correctly, the result of the robot arm was unexpected. Instead of reacting to the commands we put up in Adafruit IO, there was always a long delay for the arm to react to it. The possible causes for the delay inclue:

  1. Network latency -- the Adafruit IO server is located in the east coast, and the robot arm is in the west coast. In order to connect, they have have to message back and forth the coasts of America.
  2. Adafruit IO is currently a beta version. It also has a time delay while processing information.

Here's another problem: The arm uses motors to control its joints. Motors have no position feedback. In other words, they run on and on without knowing where it is. Also, the robot arm also had a limit to moving in a certain direction. The motors would keep on running after the limit was reached, causing the arm to break. If the robot arm was based on servos, we could use a software to detect its position and control it more sharply. That way, we would be able to reset the arm's position and make sure it never crosses the limit because it knows and has a position. This robot arm was a very cheap and inexpensive one, lacking the servos we needed to make this project more successful.

From this experience we learned that IOT and MQTT is better for sending single signals, not continual ones. A real-time project (like a robot arm) is something that you want to create multiple movements to, not just one signal. Something like a light, where you just turn on and off would be a much better choice for IoT.

Pictures


Enjoy our pictures!