Posted on

Bryan’s Status Report for 9/19/26

For the week of September 13th – 19th, I primarily focused on researching electrical and embedded-system components required for Iteration 1 of our 6-DOF surface-drawing robot arm. My work centered on identifying suitable power supplies, smart serial bus servo motors, microcontrollers, and supporting drivers. In addition, I investigated object-detection models that could run on the NVIDIA Jetson platform, specifically the YOLOv26 model and the process of training and deploying the model using Google Colab.

In order to provide adequate power to the NVIDIA Jetson Orin Nano, Intel RealSense Depth Camera D455, 6 smart serial bus servo motors, and possibly a microcontroller, I found that a MeanWell LRS-350-24 24V, 14.6A, 350.4W power supply would be the safest bet, paired with a fuse distributor; it would be easier to have a pair of wires from the power supply to the fuse distributor than to have multiple wires coming straight from the power supply. Given  that 24V may be too much for certain components (namely the Jetson), I figured that we would also require a 24V to 12V step-down converter to avoid overcurrent.

The biggest change from our original concept to the Iteration 1 design was the transition to using smart bus serial servo motors rather than traditional stepper motors. This is because these smart servos provide live position data, which we would have otherwise needed to reverse-engineer using traditional servos. For a project like this that requires exact precision, smart servos would save our group much-needed R&D time that could be used for testing and verification. As we do not yet have accurate simulation data from AutoCAD, we can only estimate our torque requirements. From my preliminary research, I found that Hiwonder, Feetech, and Waveshare offer affordable servos within our budget; I found Robotis Dynamixel servos cost upwards of $100 each, which is unsustainable.

Our team also explored the prospect of using an object detection model to run on the Jetson, for the purpose of identifying different color pens to pick up. Although this is not yet an official requirement, I conducted research into how to implement this. After comparing current commercial object detection models such as SSD, YOLO, DETR, and Faster R-CNN, I established that the only model to combine high accuracy, real-time detection, and compatibility with the Jetson Orin Nano platform was the YOLO family of models. More specifically, there are a variety of YOLOv26 models that are available based on inference speed and GPU strength. Since we do not require many detection classes, the YOLOv26n (nano) model will be sufficient.

Reinforcement learning for the model will be performed on Google Colab, since high-end GPU accelerators are free. To create the dataset, the workflow that Ultralytics provides will be sufficient, since it allows for drawing specific detection polygons onto input images and the simplified creation of different detection classes. As for implementation on the Jetson, I would use OpenCV to grab frames from the camera feed, run the trained YOLOv26n model (exported to a TensorRT-optimized engine file), then output coordinates for the object detection box.

For next week, I aim to complete the following:

  • set up Ultralytics workspace
  • start training YOLOv26 model on dataset with different color pens
  • collaborate with team to finalize design of Iteration 1 and obtain accurate simulation data for servo torque requirements
  •  assist team to refine master parts list into spreadsheet with prices, links, and any other information
    • specifically finalize brands of smart bus serial servo motors
Posted on

Team Status Report for 9/19/26

Team Status Report

For this week, our team focused on defining the master project timeline, evaluating key system risks, and refining our initial mechanical and electrical hardware architectures.

Project Risks & Management Strategies

Our team identified three primary technical risks that could jeopardize project success and established corresponding management strategies. First, structural deflection in our 3D-printed links under joint motor loads could degrade drawing accuracy. We are running SolidWorks stress and torque simulations on Iteration 1 link geometries prior to printing, with a contingency plan to insert internal aluminum reinforcement rods or increase print wall thickness if excessive flex occurs. Second, dynamic surface geometries could push the arm past its physical reach or into joint singularities. We defined a strict 0.4m *0.4m * 0.4m target workspace and designed our path planner to bound trajectories, utilizing an adjustable mounting base to reposition targets as needed. Finally, subsystem integration between ROS2, microcontrollers, vision tracking, and physical hardware presents a late-stage bottleneck, so we proactively restructured our timeline to include dedicated integration buffer weeks.

System Design Changes

We updated our system block diagram this week to replace traditional stepper motors with smart serial bus servo motors for primary joint actuation. Smart servos provide built-in position feedback controllers and support daisy-chain communication, which drastically reduces physical wire runs and bulk throughout the 6DOF arm structure. While smart servos carry a slightly higher unit cost than bare steppers, they eliminate the need to purchase separate motor driver breakout boards for each joint and significantly reduce wire harness assembly time, keeping overall project costs and risks on track.

Project Schedule Status

The team completed a comprehensive review and revamp of our master schedule this week. We explicitly incorporated dedicated buffer space for system integration and physical hardware debugging toward the end of the term. With these adjustments in place, our overall project progress remains on schedule relative to our updated roadmap.

Team Progress & Highlights

On the design front, the team held a design review forum to critique our preliminary Iteration 1 SolidWorks draft, successfully identifying key structural constraints around shoulder torque distribution, arm reach, and 3D printing clearances. Additionally, we designed a universal object target mounting base equipped with AprilTags. This mounting base allows dynamic target surfaces—such as cups, curved plates, or flat planes—to be secured firmly in the workspace while providing a clear coordinate frame for the vision system to detect relative to the robot base.

Initial team sketches for helping the robot identify the base and object with AprilTags
1. Initial team sketches for helping the robot identify the base and object with AprilTags

  1. Iteration 1 SolidWorks CAD draft overview showing initial joint and enclosure layout
  2. AprilTag object target mounting base design diagram
Posted on

Jonathan’s Status Report for 9/19/26

For this first week, I dedicated most of my time toward establishing the software foundation and architecture for our 6DOF surface-drawing robot arm. I focused on investigating robotic software stacks to ensure our arm can reliably handle inverse kinematics, dynamic surface mapping, and low-level servo communication.

I spent significant time evaluating the ROS2 ecosystem and selecting key packages for our software pipeline. I investigated MoveIt 2 for 6DOF trajectory planning and inverse kinematics (IK) solving, alongside ros2_control to serve as the hardware abstraction layer between ROS2 nodes and our physical joint controllers. To handle coordinate frame transformations between the robot base, camera optical frame, and variable target surfaces (planes, curves, cylinders, half-pipes), I started planning the use of a frame tree structure using tf2. For perception, I looked into integrating apriltag_ros and OpenCV vision models, as well as evaluating NVIDIA Isaac ROS packages (specifically isaac_ros_apriltag) to leverage GPU-accelerated pose estimation on the Jetson Nano paired with an Intel RealSense depth camera we will be renting from the ECE department. Additionally, I researched using micro-ROS on a microcontroller to handle low-latency serial bus communication if we decide to use things like bare stepper motors. I alsoexplored vis2 and RViz2 setups for kinematic visualization.

For later reference, here are the ROS2 libraries and tools I researched:

  • MoveIt 2
  • ros2_control nodes
  • tf2
  • apriltag_ros and OpenCV (OpenCV would be easier to test and bring up by itself but more difficult to integrate into the final product)
  • NVIDIA Isaac ROS (for CV and more out of the Jetson Nano)
  • micro-ROS
  • vis2 and RViz2

Beyond software, I participated in team trade-off discussions regarding joint selection and workspace reach, helping determine how our software nodes will enforce physical joint limits during surface tracking. I also created our team’s local ROS2 repository, initialized the workspace directory structure, and wrote initial package configuration files to prepare for integration.

I am scheduled on track relative to our project roadmap.

For next week, I plan to:

  1. Finalize the local ROS2 software workspace structure and pull in required drivers and third-party dependencies.
  2. Build out the initial infra for tf2 robot link tree and create a basic URDF/XACRO model representing our Iteration 1 arm parameters.
  3. Assist the team in finalizing the master hardware parts list (servos, bearings, microcontrollers, power supply).
  4. Collaborate with Aaron on verifying CAD Iteration 1 dimensions to ensure motor mounts and sensor placements align with our software node assumptions.
Posted on

Aaron’s Status Report for 9/19

For the week of September 13th-19th, I downloaded SolidWorks from the CMU student catalog, and completed the iteration 1 design of our robotic arm in the SolidWorks Design suite. I broke down frequently used 3D CAD models for other 6-axis 3D printed mechanical arms. The current iteration includes the joints, with some prematurely configured motors and power supply and screw holes.

1. Power supply box with its two lids removed

I designed the main arm’s links, with the base and power supply enclosure. I anticipate the current design for the arm itself to be insufficient for the weight of the motors, so I’ll spend the next week calculating the weight of all components and how much torque they will exert on each joint. The links (the printed section between joints) should be sufficient in size and weight to hold the weight of the arm. I also made sure the measurements for the locations of all 24 cover screws were not blocked, and there was enough spacing between printed components without overlaps.

2. 3D printed components
3. Front CAD view of the robot arm
4. Rear CAD view showing the PSU box

I experimented with pen sleeve designs and ultimately decided on a clawed gripper so the 6th degree of freedom would not limit the pen’s distance from the paper. The gripper now uses one fixed jaw, a sliding jaw, and two 4mm guide rods with an M4 screw that allows the user to manually secure the pen in place. However, this doesn’t allow the robot arm to pick up markers by itself, so we’ll need to tweak this next week.

5. Pen gripper

My iteration 1 CAD and joint, enclosure, and gripper designs, are all scheduled through October 3rd, so it is still in progress and on schedule. I’ve only finished some of the first design and initial load analysis.

For next week, I plan to:

  1. Experiment and design a counterbalance or something stronger to support the shoulder actuator
  2. Define joint limits and degrees of freedom for the six axes
  3. Plan the arm’s path within a fixed workspace that we defined as 0.4m x 0.4m x 0.4m
  4. Verify and further refine the dimensions of the servos, microcontroller, and power supply, among other parts, from the parts list we defined this week
  5. Update the SolidWorks printable files assembly