Project Logs

Collapse

• Day 2: Vision Pipeline and Browser-Based Calibration on the UNO Q

  Arya Patel • 13 minutes ago • 0 comments

  The UNO Q runs headless, with no monitor attached. That meant calibration windows that pop up on screen wouldn't work, so we built our own tool instead. vision_server.py is a small web server on port 8000. Any laptop on the same network can open it in a browser and see the live camera feed with our detections drawn on top.

  One-command setup. setup.sh does the whole install in one go:

  • Creates a Python virtual environment at ~/pandav/.venv.
  • Installs opencv-contrib-python-headless, numpy and pyserial.
  • Adds our user to the dialout and video groups, so we can use the serial port and camera.
  • Checks at the end that OpenCV's ArUco module and pyserial both load.

  The headless build of OpenCV has no windowing code, which suits a board with no monitor.

  Consistent colours, all day: The C270's auto-exposure and auto white balance kept changing how colours looked under the hall lighting, which broke colour detection. cam_setup.sh fixes this. It turns off every automatic setting (exposure, white balance, gain, backlight compensation) and locks them to fixed values. It also sets anti-flicker to 60 Hz. The camera runs at 640×480 in MJPG. A background thread keeps only the newest frame, so the planner never acts on an old image.

  Calibration with ArUco markers: We print four ArUco markers (IDs 0–3) and place them at the corners of a 200 × 150 mm rectangle. One click in the browser tool finds all four markers and computes the pixel-to-millimetre mapping. This replaced our first method of clicking points by hand, which was slow and depended on how carefully someone clicked. The same four corners also define the work area. Everything outside that area is ignored, so people and objects around the booth can't trigger a false detection.

  What the browser tool does:

  • ArUco mode: shows which markers are visible and saves the calibration.
  • Background capture: averages 30 frames of the empty workspace into a reference image, used later for obstacle detection.
  • Markers mode: finds coloured blobs and shows each one's position in mm and its angle. Clicking a pixel shows its colour values and its position in mm. We used this to tune the detection range for our green Crayola marker.
  • Detect mode: shows the marker and any obstacles live.
  • Path mode: draws the waypoints it extracts from the Sharpie line, with the start marked green and the end red.

  Reading the Sharpie line. Dark ink is separated from the white paper and thinned to a one-pixel-wide line. We then search that thin line for its longest continuous stretch. This means a small ink blob or a slight overshoot at a corner no longer breaks the path. The path is ordered starting from the end nearest the marker, then sampled into waypoints. If the contrib thinning function isn't available, the code falls back to our own implementation of the same algorithm (Zhang-Suen thinning).

• Day 1: Building the Arm, Working Around Supply Delays, and Joystick Control

  Arya Patel • an hour ago • 0 comments

  We assembled the ACEBOTT QD022 4-DOF arm kit following the manufacturer's video (Instruction 1). The parts list is in components section.

  The USB-C hub and power supply for the UNO Q didn't arrive until later in the day, so the organizers told teams to prototype on their laptops in the meantime. 

  After assembly we measured the arm, because our inverse kinematics needs exact dimensions:

  • Shoulder to elbow: 78 mm
  • Elbow to gripper: 50 mm
  • Table to shoulder pivot: 40 mm

  The arm has three positioning joints (base, shoulder, elbow) plus a gripper, with no wrist.

  We then wrote ESP32 joystick firmware (teleop_test.ino) to prove the hardware worked before adding autonomy:

  • Joystick centring and deadzone: On boot, the firmware averages 50 readings per axis to find each stick's resting position, so the arm doesn't drift.
  • Speed limit: Every joint moves at a capped rate. We first used 90°/s, but the arm was jerky, so we lowered it to 30°/s.
  • Pose memory: When the arm stops moving for 1 second, the pose is saved to flash. On the next boot the arm eases back from there instead of snapping.
  • Freeze button: Pressing the J1 button freezes all motion. This became the basis for our manual-override kill switch.
  • End-stop warning: The firmware warns when a joint sits at 0° or 180°, where the servos buzz and heat up.

  Problems we hit:

  Buttons with no pull-up. ESP32 pins GPIO34/35/36/39 are input-only and have no internal pull-up resistor. Our joystick buttons read correctly only because the modules supply their own.
  Reset on connect. The ESP32 resets whenever the serial port opens, so the Python side waits 2 seconds before sending any command.
  Late supplies. Delays cost every team time on Day 1. The organizers let us take the arm home overnight, and implemented the changes based on updated requirements.
  
  

• Day 1 Morning/Early Afternoon: Understanding the Challenge and Planning the Control Flow

  Arya Patel • an hour ago • 0 comments

  The challenge was handed out (first attached image) Tuesday (09/22/2026) morning 11:05 am. A robotic arm has to find and pick up a marker, trace a path from start to finish, and put the marker back down. It must plan its motion in real time with no network connection and no pre-programmed sequence. The strongest demos add an obstacle or a hand mid-run, and the arm has to detect it, replan around it, and keep going without losing accuracy.

  Before touching hardware, we sketched the task as a flowchart (second attachment): find marker, pick it up, go to the path start, follow the path, put the marker back, return home. Our first key design decision came from that sketch. Our first draft had separate "find another path" boxes for the approach and for tracing. We merged them into one shared routine called Guarded Move. It moves in small steps, checks the camera before each step, and detours if something is in the way. Every movement the arm makes uses this one loop.

  Our first key decision came while drawing it. The first sketch had two separate "think of another path" boxes, one for the approach and one for tracing. We merged them into a single shared routine called Guarded Move. It moves in small steps, checks the camera before every step, and detours if something is in the way. Every movement of the arm uses this one loop, so obstacle handling works the same way in every phase of the task.

View all 3 project logs