MicroFRC Tutorial

Here is the 2023 FRC (FIRST Robotics Competition), and in the robotics world, there's no one who hasn't heard of it before. So, as a robotics enthusiast, these robots are spectacular, and every year, every robot, there's not a single one that doesn't amaze me. However, there's a huge problem (somewhat) with this competition: it costs a lot. I'm not talking about a few hundred dollars, but a few thousand; the price tag is terrifying as a student who can barely afford to go out. Though it makes sense—a large competition requiring large fees—I wanted to know if I really wanted to invest that time and money into a singular competition. So, I decided to just make it. But smaller. Much smaller.

DISCLAIMER:

Though I am sharing what I have done, I strongly believe these things should be created by your own thinking. This is because thinking of your own solutions to the problem and seeing it work is the absolute joy of it, and I don't want such a thing to be robbed. Regardless, this instructable has lots of transferable information to any robot, and I would highly recommend reading it.

BUT, if you are still too lazy and you just need help with a few things, the last step, which is just some tips I've found out, can be of use.

Here are the supplies I used:

• 3D printer(for all my solid structures)
• 4 x Mecanum Wheels
• 1 x FS3003 Futaba Servo Motor
• Make sure to have the servo horns, they are very important
• 4 x dual shaft DC gear motors ( You can find these anywhere)
• 1 x ESP32
• 1 x Alfredo NoU2 board (Usually have to be ordered online)
• 1 x Li-Ion or Li-Po Battery, 9v
• 1 x 9V Battery Barrel Jack Cable
• 1 x SG90 servo
• 2 x N20 Motor

You can get most of these things through this site created by Alfredo: website

Firstly, I believe starting with the arm is very beneficial to the building process because for most people, it's the most challenging part. Additionally, developing the arm first allows you to align the chassis design accordingly, making the process much easier.

For the arm design, I opted for one with two joints to control the arm's height and position more precisely. However, there are many other viable designs, such as using a chain, reducing the joints to one, or creating a rack and pinion design. The key is to find the design that works best for you, rather than following what everyone else is doing.

Here's how I made my arm: It consisted of two parts—the base joint and the secondary joint—connected by a 3D-printed panel. The panel for the second joint is about half the length of the main panel because I wanted to avoid excessive force on the first joint that could cause it to break.

An important tip for anyone using servos: When 3D printing a panel to attach to the servo, avoid simply using the normal servo shaft and a glue gun to connect them. This method is weak and not well-designed. Instead, use a servo horn and create multiple holes on the panel for the horn. This allows you to screw the panel and servo together, ensuring stability and durability.

The gripper, which I believe is the most time-consuming part of the whole design due to the extensive trial and error involved. Like the arm, there are numerous possible designs, such as a normal pinching design, using two rollers, air suction, stabbing mechanisms, or any other approach you prefer. However, I chose to stick with a design featuring two rollers because I believed it would offer more consistency when handling the cones.

The design process was relatively straightforward. I needed to create a design that accommodates two N20 motors and attach some sort of disc with friction to roll the cones and cubes effectively. After going through almost ten designs, I finally achieved a functional one. I used a glue gun to attach rough sandpaper for added friction, which helps hold the cones and cubes in place.

My tip here? Measure and calculate everything beforehand to minimize the trial and error process.

Recommendation:

Before proceeding with the chassis assembly, it's recommended to complete the gripper and arm assembly. The chassis should be tailored to fit the dimensions of the arm.

Now, moving on to the chassis design itself, it typically consists of a simple rectangle with extensions for motor placement. In my design, I positioned my motors horizontally, but vertical placement is also possible and can save space.

I found that my chassis had several limitations and flaws, which I'd like to address. Initially, it was a basic rectangle with extensions for mounting the motors. However, this design proved to be too weak, especially under the weight of the robot. The motor holders would bend, causing the motors to dislocate and resulting in erratic movement. To address this, I used a suitable-sized aluminum panel to reinforce the motor assembly. Alternatively, a better approach would be to redesign the chassis by adding struts to the motor holders on both sides, making the design more resilient to weight and stress.

Additionally, it's helpful to include a few holes in the chassis for routing wires, ensuring a neater and more organized assembly.

Even though "Wheels" aren't technically a step in making the robot, I found these wheels (mecanum) fascinating and would like to discuss them briefly. In one of the diagrams above, there are six diagrams illustrating how a 4-wheel mecanum wheel chassis can perform various movements, including moving forward and backward, right and left without turning, diagonal movement, and turning. I chose to use these wheels because in a small arena, mobility is crucial for fast transportation, which is exactly what mecanum wheels offer.

However, I also discovered another type of wheel called omni-wheels, which seem to function similarly to mecanum wheels. While I haven't experimented with them personally, they seem extremely interesting, and I would highly recommend considering them as well.

The key point here is that in small arenas, the mobility of the robot is crucial, so paying attention to the type of wheel used is necessary.

Now comes the assembly, usually the final step in the construction process. Assembly should be relatively straightforward; while things can be hot-glued, attachment with screws is much more reliable. In my case, I created another box to hold the main servo for some extra elevation.

An important issue I encountered during assembly was with the battery. Initially, I used a simple 9V disposable battery connected to the NoU2 jack. However, I faced a significant problem with the consistency of the current because the battery was not rechargeable. I noticed this when simple servo movements seemed fine, but larger movements in the chassis, which required consistent current, were erratic. So, I realized I needed a rechargeable battery that provides consistent current, leading me to use a 9V Li-Po battery.

However, I want to emphasize that while assembly may seem like the end, there's still much more to do, and this is where the challenging part truly begins.

Coding the robot was relatively simple for me, but I encountered a few specifics that I had to figure out. So, here is a short explanation of my findings.

1. If you are accessing the same part, they usually have to be in the same if statement, with else if's, as then motor commands could overlap.
2. Activating too many parts at once can sometimes cause weird errors.

Here is my functional code at the end:

#include <Alfredo_NoU2.h>
#include <AlfredoConnect.h>
#include <BluetoothSerial.h>

NoU_Motor FL(4);
NoU_Motor BackL(3);
NoU_Motor FR(1);
NoU_Motor BackR(2);
NoU_Motor GR(6);
NoU_Motor GL(5);

NoU_Servo sec_Servo(1);
NoU_Servo main_Servo(2);
int speed = 0.8;
BluetoothSerial bluetooth;


void setup() {
  bluetooth.begin("torazo minifrc"); // Change this name before uploading!
  AlfredoConnect.begin(bluetooth);
  bluetooth.println("Starting motor and servo test program.");
}


void loop() {
  int speed = 0.7;
  if (AlfredoConnect.keyHeld(Key::Digit1)){
    GR.set(1);
    GL.set(-1);
  }
  else if (AlfredoConnect.keyHeld(Key::Digit2)){
    GL.set(1);
    GR.set(-1);
  }
  else{
    GR.set(0);
    GL.set(0);
  }
  if (AlfredoConnect.keyHeld(Key::Digit3)){
    sec_Servo.write(10);
  }
  else{
    sec_Servo.write(0);
  }
  if (AlfredoConnect.keyHeld(Key::Digit4)){
    main_Servo.write(70);
  }
  else{
    main_Servo.write(0);
  }
  if (AlfredoConnect.keyHeld(Key::W)) {
    FL.set(0.7);
    FR.set(0.7);
    BackL.set(0.7);
    BackR.set(0.7);
  }
  else if (AlfredoConnect.keyHeld(Key::D)){
    FL.set(0.7);
    FR.set(-0.7);
    BackL.set(-0.7);
    BackR.set(0.7);
  }
  else if (AlfredoConnect.keyHeld(Key::A)) {
    FL.set(-0.7);
    FR.set(0.7);
    BackL.set(0.7);
    BackR.set(-0.7);
  }
  else if (AlfredoConnect.keyHeld(Key::S)) {
    FL.set(-0.7);
    FR.set(-0.7);
    BackL.set(-0.7);
    BackR.set(-0.7);
  }
  else if (AlfredoConnect.keyHeld(Key::E)){
    //top right diagnal movement
    FL.set(0.8);
    FR.set(0);
    BackL.set(0);
    BackR.set(0.8);
  }
  else if (AlfredoConnect.keyHeld(Key::Z)){
    //bottom left diagnal movement
    FL.set(-0.8);
    FR.set(0);
    BackL.set(0);
    BackR.set(-0.8);
  }
  else if (AlfredoConnect.keyHeld(Key::C)){
    //bottom right diagnal movement
    FL.set(0);
    FR.set(-0.8);
    BackL.set(-0.8);
    BackR.set(0);
  }
  else if (AlfredoConnect.keyHeld(Key::Q)){
    //top left diagnal movement
    FL.set(0);
    FR.set(0.8);
    BackL.set(0.8);
    BackR.set(0);
  }
  else if (AlfredoConnect.keyHeld(Key::L)){
    //turn right
    FL.set(0.65);
    FR.set(-0.65);
    BackL.set(0.65);
    BackR.set(-0.65);
  }
  else if (AlfredoConnect.keyHeld(Key::K)){
    //turn left
    FL.set(-0.65);
    FR.set(0.65);
    BackL.set(-0.65);
    BackR.set(0.65);
  }
  else{
    FL.set(0);
    FR.set(0);
    BackL.set(0);
    BackR.set(0);
  }


  AlfredoConnect.update();
}

Here are some quick solutions I would've found useful when i was doing my microFRC:

• The robot isn't moving straight
• It could be an imbalance of the motor's power, which should be solely debugged
• It could be that the chassis is bent or the wheels are flawed
• The motors aren't moving from the computer
• Check if the ESP32 is inserted to the NoU2 in the correct orientation
• Try to debug with very simple code to simply test the code.
• Make sure your Alfredo Connect is opening the COM port that is outgoing, not incoming, or else it won't work.
• Servo's aren't moving like I thought they would
• If they are doing full circles, they are probably continuous and hard to control through the AlfredoConnect
• The gearbox itself could be broken, try to debug by using a new/unbroken servo
• The servo could be too weak to the load it is trying to, look at different servos and the powers carefully.

FINAL TIP: NAME YOUR ROBOT! (mine is named squeak)