1 of 32

HAcK Group 7

Team Free Block-E

Jerry (Shengjie) Zhu, Julia Stoneburner, Phoenix Tsou

2 of 32

Our Physical Design: Arms

In our first design, our arms were almost identical in shape. The active arm was intended to have an additional smaller arm that functions in a clasping mechanism.

All of our prototypes were laser cut with the exception of one. This was due to laser cutting being much faster than 3D printing.

3 of 32

Passive Arm Design

•The proximal section made longer to fully extend past the wheels.

•The height of the distal section intended to do the actual picking up was decreased.

•The alignment holes were changed because the non-flat shape of the plastic clip that attaches to the Servo was not taken into consideration initially.

First Prototype

Second, Final Prototype .

Crude CAD replica of the plastic Servo clip

proximal

distal

Height decreased

thinner

Proximal end lengthened

4 of 32

Passive Arm Mechanism

The passive arm suited picking up the Tie Fighter.

The intention was to hook underneath the center rod, lift it up, and allow it to slide down the arm into the backpack.

In testing this worked well. Unfortunately, we do not have video footage.

5 of 32

• The proximal section was altered to fully extend past the wheels while not hitting the backpack when the object is lifted up and dropped.

•The height of the distal section intended to do the actual picking up was decreased. It was also made thinner to fit the handles of the Atomic Death Star.

Active Arm Design

Similar adjustments were made to the active arm.

Proximal end dropped down

This is where the mini servo fits

6 of 32

The Clasping Mechanism

•Mainly: The Atomic Death Star would get caught in the upper corner of the larger arm.

•The servo has to extend back really far to drop the Atomic Death Star into the box due to its curvature. Its curved this much so that the larger arm can be thin enough to slide into a handle of the Atomic Death Star.

•There is a lip on the clasp I added in case both arms didn’t make good contact. This would have hit the bigger arm which I didn’t foresee until later.

The larger arm rotates back about 180°—the maximum angle for the Servo. The Mini Servo does the same.

Mini servo and clip not pictured for clarity

The backpack

Object gets stuck!

Not the best design.

7 of 32

Active Arm Cont’d

The design in the third iteration was changed pretty drastically. While the clasping mechanism was able to pick up the Atomic Death Star by hooking and enclosing on of its ‘handles’, the object would get stuck on the inside corner in the process of being rotated up. We decided to change our approach.

First

Second

Third and final prototype

8 of 32

Active Arm Mechanism

Mini Servo rotates the small arm to lift object

Big Servo rotates towards backpack

Block-E aligns and rolls into hook of

9 of 32

10 of 32

Block-E’s Sentience—LCD Screen

11 of 32

Bonus: Cool LCD During Testing

12 of 32

LCD Iterations

The numbers of customized characters were cut down from 13 to 8 while still making pretty similar faces. The smile was made with keyboard characters instead, and the smaller heart eyes were reused instead of the larger ones.

These weren’t needed after all. It seemed to have resolved itself once the Arduino board was reset.

13 of 32

Our First Challenge: ESP32

  • ESP32 being the foundation of making everything to work..
  • Our laptops had problems connecting and controlling the ESP32 chip…
    • Jerry’s laptop can’t write… and can’t upload codes to the chip (AMD cpu supporting?!)
    • Phoenix’s laptop can’t read… and can’t transmit data between laptop and chip after bluetooth connection.
    • Tried, but time wasted
  • Fix: Wes lended us a new laptop on the second day of competition
  • The issue on Jerry’s and Phoenix’s laptop prove to be hardware related since the new laptop worked almost instantly :)

14 of 32

Trying to Debug the Data Transmission…

15 of 32

Our Design: Data Transmission

/ Work Flow

  • The car needs to work remotely and wirelessly
  • Data Flow Chart: (Basic)

16 of 32

Serial Connection Code

17 of 32

Our Design: Main Controlling Code (Arduino)

  • Basic thought:
  • Concise and Straightforward main loop code
  • Things to check: Cars going forward? Backward? Left or Right?
  • Servo Operations: Left, Right & Micro Servo going back/forth
  • Bonus Function: All servo reset and micro servo reset

18 of 32

Main Controlling Code Continued

  • Features:
    • Clear Pin Declaration, Key binding zones, and delay time.
    • No need to change every number in the document, easy to edit
    • Motor delay time was eventually not used.

19 of 32

Main Controlling Code Continued

  • Functions with clear names and nomenclature
  • One separate function every move! (Car operations, servo operations)

20 of 32

Main Controlling Code Continued

  • The self-defined functions make embedding all kinds of operations into the dancing possible.

21 of 32

Main Controlling Code: Deficiency

  • We didn’t have the time to embed the LCD code into the controlling code and have to add them in the main loop. The main loop could have looked like this:
  • (This is how the main code looked like before I embedded the LCD functions written by Julia)

22 of 32

The (Still Simplified) Flow Chart

23 of 32

Our Process: Building & Testing the Car

Testing motors and servos!

24 of 32

Our Process Continued

Putting things together…

25 of 32

Our Process: Preliminary Testing

Block-E with his body taped and eyes waggling :)

26 of 32

Our Process: Almost Everything Done

27 of 32

28 of 32

29 of 32

Maybe We Should Have Tried…

  • We noticed that the electronic devices worked very unpredictably given insufficient voltage / unstable voltage, especially the big servos (they will refuse to work if given below ~4.9V, and we had to power it up using 5V connected to a breadboard)
  • Should have checked more datasheets to make sure everything are given their desired voltage.

30 of 32

References:

31 of 32

Task Assigns

  • Julia (Online): Solidworks, Arm Design, LCD Creativity
  • Phoenix: Data Transmission, Car Assembly, Car Operator
  • Jerry: Main Controlling Code, Wiring

32 of 32

For reference

Teams are required to submit their design review presentation by Tuesday, July 26th, at 10 AM. Presentations must be 10 minutes or less and given in recorded video format, where all team members present equally on their design process and demonstrate their finished robot’s functionality via photos and videos. Teams are required to use Google Slides for their presentations and embed all photos and videos of the robot within the slides themselves. The guest judges will be evaluating each team’s Robot Functionality and Features score as well as their Presentation score based solely on the content of the team’s video presentation, so ensure that you showcase all of your robot’s functionality within the presentation itself. Engineering communication practices demonstrated in the presentation, such as clear descriptions of the designs and code used, the iterative design process, and future improvements, will also be considered. For detailed information on presentation criteria, refer to the judging rubric.

Presentations will be submitted in three parts:

1) Video File (MP4)

2) YouTube Link (Instructions on how to upload a video to YouTube can be found here)

3) Link to Your Google Slides

Presentation Submission Form

all teams will create a design review presentation, a ten-minute video where they explain their design process from start to finish, showcase relevant CAD models and code snippets, and demonstrate their final robot’s performance.