Skip to content

10. Mechanical & Machine Design


Week assignment

  • This week’s assignment was to design a machine including mechanism+actuation+automation. We divided into gruops and I was part of Awesome machine 3 team.

  • Build the mechanical parts and operate it manually.

  • Document the group project and your individual contribution


The organization

During 2 weeks, of which we only had 3 or 4 days of access to the laboratory, we were developing machines whose main objective was to press the button of another machine.

The core part of the project was done by the entire group of students from FabLab in Barcelona. The second part we carried out in smaller teams. We divided into 3 groups of 3 people. Each team designed a tool, manage to get their engines running and assembled their machine.

  • The machine group page was made by myself and is updated here. We decided to use HTML instead of mkDocs because it was more straight forward for the collaboration of the whole team.

The concept

concept

Diego had this idea of using pulley and belt mechanism to trigger a hand that would hit the enemy’s button.

idea

Gerardo was focued on designing and printing the wheels and the battery case. I made an initial prototype to test the mechanism and understand what we would need.

We decided to cut the tool in acrylic and the hands in eva rubber. We realized that the wheel did not turn easily and that we would need a closed belt to be able to operate the mechanism as we wanted. I took care of getting the belt and Diego got some bearings that improved the friction issue.

suppor suppor

As our board was not flashed and we did not have the code to operate the tool, therefore my task was to run the motors while Diego finished refining the tool.

The code

I had no idea how to program the stepper motors nor how to use the Barduino. Fortunately, Carla wrote an awesome guide that I documented here

The first problem I ran into was that the plate was not well soldered. To flash it you had to hold the micro USB connector with your hand.

When I first uploaded the code and decided to set the drivers, when using the multimeter I realized that the white driver was not working well. When tested with the motor, the motor was not working but the monitor showed that it was sending the commands.

After verifying that the X and Y motors worked correctly, I decided to write the code for the Z motor. The idea was that the tool would work when the machine was moving forward and also on demand when the machine was stationary.

// == FRONT
    if(action == "front"){   
      Serial.println("front_while");
      digitalWrite(MOTOR_DIRECTION_RIGHT_DIR, LOW);
      digitalWrite(MOTOR_DIRECTION_LEFT_DIR, HIGH);
      digitalWrite(MOTOR_DIRECTION_RIGHT_STEP, HIGH);
      digitalWrite(MOTOR_DIRECTION_LEFT_STEP, HIGH);
      digitalWrite(MOTOR_TOOL_DIR, HIGH);
      digitalWrite(MOTOR_TOOL_STEP, HIGH);

      currenttime = millis();
      while(millis()-currenttime < 0.1){

      }
      digitalWrite(MOTOR_DIRECTION_RIGHT_STEP, LOW);
      digitalWrite(MOTOR_DIRECTION_LEFT_STEP, LOW);
      digitalWrite(MOTOR_TOOL_STEP, LOW);
      currenttime = millis();
      while(millis()-currenttime < 0.1){

      }
    }

    // == ACTION
    if(action == "action"){   
      Serial.println("action");
      digitalWrite(MOTOR_TOOL_DIR, HIGH);
      digitalWrite(MOTOR_TOOL_STEP, HIGH);
      currenttime = millis();
      while(millis()-currenttime < 0.1){

      }
      digitalWrite(MOTOR_TOOL_STEP, LOW);
      currenttime = millis();
      while(millis()-currenttime < 0.1){

      }
    }
The problem was that it worked when I touched the FRONT command but not when I touched ACTION. I spent a while trying to figure this out and found that there was an error with a capital letter in the index.h file It was written actionStop instead of ActionStop. That was about the tool stoping, which was an issue when pressing the FRONT command, but it was not related with the fact that the tool was not working when pressing ACTION.

I was only able to solve this in the lab with the help of Edu, who found that a line of code was missing above.

 server.on("/action", []() {
    Serial.println("action");
    server.send(200, "text/plain", "action");
  });
Instead of
 server.on("/action", []() {
    Serial.println("action");
  action = "action";
    server.send(200, "text/plain", "action");
  });

action stop issue

The third problem was that when I was testing the engines I had the phone plugged into the computer which gave it access to the internet and the page could download the required libraries.

For some reason, I decided to unplugged my phone. So, I was only connected to the wifi of the board. The page stopped working and I started getting the following messages.

code issue

One part was related to the Barduino being poorly welded and sometimes making contact and sometimes not. At the lab I got a lot of help from Edu both to fix the board and the code. So, now the Barduino could connect to the internet and the libraries request was no longer an issue.

The fourth problem was that the motors did not have the necessary power to move the machine. Once we had everything ready we did the assembly test. The engines worked perfect when they were weightless. But when having to support the weight of the machine they did not move.

board and motors ready

A stepper drive is the driver circuit that controls how the stepper motor operates. Stepper drives work by sending current through various phases in pulses to the stepper motor. These drivers are very sensitive and thy burn easily. Due to the fear of burning them, I had set them very low and with a high speed.

To solve this, we modify the voltage on the drivers and the speed on the code.

We changed the speed from

 while(millis()-currenttime < 0.1){
to
 while(millis()-currenttime < 0.3){
We increase the voltage of the motor’s drivers above 5v and we added heatsinks to them. After that everything worked perfectly.

The machine

suppor

Find all thefiles here:

Code

3D parts

Some improvement ideas

What the Arduino starts is a web server. A web server has web addresses. When you enter FRONT or LEFT web addresses, what it does is constantly start a motor. Then there are other directions like DRIVESTOP that what it does is just make the motor stop working.

When we click the button (mouse down), the button calls the URL that is assigned to that button. When you stop pressing it (mouse up) it calls the stop. Which means that if we eventually lose connection, the robot will continue with the last address it received.

Because of how the code works, this robot cannot do 2 things at the same time. That’s why I decided to activate the weapon when you press FRONT button. If not is impossible to move and attack at the same time.

This code could be improved to make it easier to handle. Same with the UI. The interface is very basic, it has no affordance and it is difficult to understand how the buttons work. For example, buttons should have more than one state. We need to know status when we are pressing it. The same happens when we press a button that generates an action that lasts in time, for example going forward. It should stay in the focused state until I click another button.


Last update: April 11, 2021