almost done with base chassis wiring (pt2 of saturday)

I got a quite a few things done in this journal

1. attached all wheels properly which took a LONG time to do because of the tiny and annoying provided hex screws that basically wore out instantly
2. labled everything that would be useful to refer to
3. officially placed the drv8871 motor drivers in the most optimal spots, and used hot glue along with zipties when necessary to make the wiring secure and optimized (this took majority of the time due to the amount of iterations done)

worked with motor drivers --> finished ALL base wires (pt1)

I finalized the DRV8871 as our new motor drivers due to their higher peak amp capacity and their ability to turn the motor power source to a logic power source all with 1 wire (also, I realzied that having 4 flexible motor drivers is better than two motor drivers with too many wires to move). I made the strategy of removing the plastic shelling from 22awg dupont wires, and using dupont wires + hot glue for logic (I kind of regret this now since male dupont thing is really weak, but it's fine because this part of the robot will be enclosed to resist any harsh pulling).

In my next journal I will connect everything.

Tested all motors with wheels after one was behaving weird

I noticed that when I was resoldering the wires to a motor, when given 12V power, it was making a really weird and disturbing clicking sound. Now, all of them seem to work, but two make noises that the other two don't. I am not sure if this is a motor issue or the solder issue (I don't think it's a solder issue), but at least they all seem strong.

Placed mux in the best position possible to make wiring neat

During the wiring process, after getting the new frame, I had a perfect spot in mind to place the mux (this is what centralizes the addresses of 4 distance sensors, an MPU6050, a OLED, and a grove port to female dupont pins to connect straight to the jetson orin nano).

It took a lot of effort to get the placement done since I originally did this with the old frame, used heatshrink for all STEMMA wires, and finalized how I would go about the solution. But, when taking the parts out for the new frame, the motor wire came out and was honestly behaving weird when given 12V, but I was able to fix it (hopefully it stays fixed).

Anyways, I finished the placement with the new frame after:

Big frame change in order to adapt for new wiring strategy

We realized that our old frame looked fancy, but was not suited for the changes we wanted to make. Below are the key problems listed:
-Made the wiring and placement of the buck boost converter to the buck converter very awkward
-Covered certain Jetson Orin Nano pins because we were originally going to use an Arduino nano --> but, due to the switch since that is no longer needed, the frame needed to be changed anyways
-Started to look chopped due to the amt of holes I drilled to account for all the random changes we had

As anyone would, the problems made it clear that it was worth to disassemble a lot of what we had to have a new frame. We realized that we needed a way for our ports (2 USB, display, USBC) to be avaliable to us while the jetson orin nano is packed in the center of the robot. The image below shows what we did (took 4 hours of CAD + call):

Here are pictures we edited during our group call:

Interconnected ALL parts

Now that the switch issue is fixed, and I got the other parts I need, the last part to connect is the motors to the motor driver, the servos, and minor logic connections. Other than that, I started planning out how I would fit and place all these parts onto the robot in a safe way.

Completely fixed connection strategy for main switch

If you scroll down in this journal to where the switch was first soldered to other wires, it already looked dangerous, but at the time I thought that it worked. However, when using the Jetson, it started sparking for no reason, even though ground and voltage never touched. Either way, I knew I had to fix those connections so learned how to use crimp connectors with my own wires. After a lot of experiments, I fixed our connections around the switch!

Continued to wire, glue, and zip tie mess

In my last log I made most of my connections to the 40 pin extender of the jetson orin nano. Now, i’m continuing to wire the sensors up, specifically focusing on the I2C connections and mux this time. You might also notice that I attached the front plate with screws too, and even put on and found the best way to have the batteries on the robot.

Connected motor driver to 40 pin jetson extender

I connected all of the necessary motor driver pins to the jetson orin nano extender and glued it on (allowing me to keep all wires secure without ruining the jetson at all). next, i’ll continue to do the same thing with the mux, relay, etc.

Created a plan for how I would use motor drivers

To have the robot actually start driving, I believe the next best step is to work on and connect the motor drivers to the motors and Jetson Orin Nano. However, the problem is that my dupont wires are not good enough to handle 12v at 2-3A. This meant that I had to come up with a plan to somehow connect bare wire to the dupont pins of the motor driver. I was somehow able to wrap around the bare wire around a pin, apply solder carefully, and then put a heatshrink on top of it. I did this for the voltage and grounds of two motor drivers. Then, I planned out and attached all other necessary wires.

Tested all connections for continuity

I realized that it was important that I test all my connections for continuity to make sure that some weren't bad. Thankfully, I found out that one wire connected to my touch sensor wasn't soldered well and I was able to fix it.

Tested distance sensors with front bumper + tested wheels

I needed to make sure that the distance sensors were at the perfect positioning to work. So, I screwed the wheel mounting hubs onto the motors and tested the distance sensors (ToF) with a mux to see if it could detect obstacles and if it would be feasible in code. From what I tested, it seemed to work well for now.

Fixed issue regarding the USB cable of camera

If you look carefully at the camera two logs ago (where I show the robot assembly in progress), you can see that the camera had 4 wires that are in a secure cable with aluminum paper covering. THe issue was that this cable was so thick that it was taking way too much space from the robot. So, I made the tough decision of cutting it to the point where I just had those four wires. However, when stripping the wire to reveal the bare metal, I accidentially took off the white one entirely. So, I had to carefully solder it back on and test for continuity using a multimeter. It works! I did have to buy a replacement USB to 4 wires from amazon though.

Brutally drilled through all mounting hubs and built wheels

After spending nearly an hour trying to figure out why my screw types weren't working at all on the universal mounting hub, I decided to try using my 3mm drill bit thru the hole to see if it would help. While it was a huge hassle, since sometimes the entire hub would start moving in a circle, I was able to succesfully drill all holes in all hubs and attach the M3 screws I have onto the wheels + hub.

Start assembling and putting components together on chassis

The time has come! Now that we have fully finalized the major components in our current CAD model, I can start to reassemble and put together the parts on the robot. In this image, the back plate, motors, jetson (with all cables) and front plate have all been attached and assembled.

There were times when I needed to solder a bit of the CAD off to allow wires (something we didn't fully account for when making the CAD model but it's okay).

Fixed previous code fake green square algorithm in map

Building on what we learned before, the yellow dot also has a very important role

In RCJ linetracing, some green squares are fake, as they are on the other side of the horizontal line in the intersection (meaning the robot should ignore it)
The yellow dot helps to check
If the yellow dot is located over the black line, it means that the green square is located above the black line
This means the green square is fake, and won’t be considered
However, the robot still has to turn if a real green square is also located in the intersection

this still needs a lot of refining but it's a good place to start

Nearly finalized green square detection algorithm

When there is an intersection, we have to check for green squares
Detecting them is relatively simple, just check for a large group of pixels with greater green value than red and blue values
However, the location of the green square relative to the line matters
If its on the left side, the robot must turn left, if its on the right side, the robot must turn right, and if it’s on both, the robot has to do a u turn
To determine what side a green square is on, we draw out 4 points a set distance from the center of the bounding box of the green square

The code checks the 4 dots (pink , blue, green, and yellow in this image)
If both the green and blue one are located over the black line while the green is not, it means it must be a left turn, as the green one is on the right side of the green square, thus meaning the green square is on the left side of the line. Vice versa, if both the blue and pink ones are over the black line while the green is not, it must be a right turn.

CODE WORK --> wrote out code plan

We reviewed our linetracing plan from last year, and evaluated what we could improve upon this year
Ultimately, the following plan was drafted:
Line following
Accounts for green square, follows black line, etc
Linetrace is based off of the OpenCV Mat containing all the pixels for the black line, we can use a more complicated algorithm (not just center of mass)
For green squares, we can have the robot turn using the gyro, or remove the other parts of the intersection so it only sees the correct path, and just does normal linetrace based off of that
Obstacle avoidance
When obstacle is detected through the front distance sensors, the robot will stop moving and go around it
To maintain a constant distance from the obstacle, we use the side distance sensors
During this process, the robot must actively be trying to refind the black line
Due to the nature of the turns, the robot cannot resume line following immediately after refinding the line, it must perform a turn before continuing line following

Once the silver line is detected (linetrace code must continually check for the silver line)
Robot enters the victim stage
Keeps turning until a victim is detected
If multiple are detected, go towards the one with the largest bounding box (the closest one)
Approaches the ball until a certain threshold is reached (we can estimate distance from ball by finding the area of the ball onscreen placed at a set distance away from the camera, and because the area is inversely proportional to the distance from the ball, we can estimate pretty accurately how far the ball is from the camera)
collectBall() function that sends the commands for the motors to pick up the balls. This can be done with delay() or encoders doesn’t matter too much
We use touch sensors on the claw to confirm the claw has a hold on the ball and when the touch sensors are released, confirms that the ball is deposited into our third platform

(and a lot more)

Afterwards, we all agreed on this plan

Needed to remove all pieces from robot, then worked on oled+

As part of our three-member squad right now, one person is testing out OpenCV code, the other is working on CAD + code, and I, the person who is writing this, am working on CAD + hardware. We had a really long discussion about changing a lot of the CAD model but then eventually came to the conclusion that it was not worth doing all of that to save 1 centimeter of length. So, we changed our distance sensors but kept mostly everything else the same.

Since we are using a mux now, I realized that I had a oled screen with a Mux connection. However, the model didn't account for that, so I bascially just drilled a bunch of holes near there until I was able to fit the wire through. I also added the click sensor on the back of the robot

Added touch sensor to claw to detect ball accurately

(other teammate work)

Changed claw design, adding a push button to confirm that the ball is grabbed and secured.

Printed and tested the mechanism to ensure it’s functional

Used code to put it under different scenarios.

Changed CAD model from distance sensor to touch sensor

Added push sensor behind the robot, replacing the distance sensor
Because the distance sensor can only detect distances above 2 cm, and we need a sensor to confirm if the robot is in contact with the victim evac zone, a push sensor would be more effective/easier to code

Tested it after

Designed new frontplate

Problems with old front plate
Distance sensors were positioned forward, meaning thinner obstacles might not be detected
Victim camera was positioned too forward, forcing us to increase robot length as the linetracing camera has to see ahead of it
New design used angled distance sensors that would detect when an obstacle was directly in front of the robot
This also lets us validate the obstacle using the gyroscope, as when the robot is stuck, the gyroscope will show low acceleration
The victim camera is moved backward to give more space for distance sensors

Made brutal change to the distance sensor & made I2C strat

(worked on by all 3 teammates)

We ended up testing our previous distance sensors (cheap ones) and realized that they were horribly inaccurate, even when "calibrated". This scared us and led us to look into the sensors used by previous teams. After research and emailing, we got a call from the team that placed 2nd internationally in 2025. We were informed that they faced a similar problem, and that they used the VL53L0X sensor. So, after a lot of conversation, we decided to do the same thing.

As we developed our solution, on CAD, we changed the distance sensors to our more reliable model. A hole was added to the battery mount to allow for the wires from the distance sensor to travel directly to the center of the robot, where it would connect to the jetson orin nanos pins.

We also finalized how we would go about using I2C, as all parts needed a unique way of being functioned. The picture below shows an example of what we planned out using a mux (with ONLY the Xshut pin soldered).

Designed and printed map parts

(completed by teammate and I)
We spent this time looking into competition rules, and the specs of the maps, including ramps and obstacles. We want to recreate identical maps when we start coding and testing, so that meant we needed to CAD map accessories (so we don't have to buy the expensive ones). We needed a good way for this to work, so after many iterations, we came up with a LEGO style approach, where we can screw on more pieces (as shown below) to increase the height of the ramp. We also made a hinge mechanism for the seesaw, and printed it. It ended up working successfully, but we still have to fully test it with the robot.

)

Iterated through how LED would be attached to CAD model

(completed by teammate)
My teammate spent a long time trying to perfect the CAD on how the LED would be attached to the robot. There were numerous options we went through, including solder, tape, just a fire CAD design, but then we landed on zip ties for now, that produced the result shown below. We also tested the LED by connecting it to a relay, which was connected to a stripped USB.

Tested motors and motor drivers together

After figuring out the issue with the motor drivers, I fixed all of them, wired them, and started running numerous tests on the motors. We also learned that each can support two motors so we adapted for that in the future. Our numerous tests proved successful, and now we just have to figure out where we can stuff the motor drivers in the internal robot CAD.

Tested and fixed motor driver problem

Originally a few months back I wasn't sure why these motor drivers weren't working. I ended up finding out I can't just solder the corners and assume that the conductive parts are touching, and that I have to solder every single pin. After learning this, I resoldered these motor drivers, and they work now!

Finalized LiPo Charger

(PARTNER WORK) Our original one didn't work so we looked throughout Amazon to find a good LiPo charger. We chose this one, and it was absolutely amazing (50W per hour)!! The UI was great too.

Finalized Display Port wire (sob)

This one was a nightmare. So, we knew that we were NOT going to rely on something like VNC Viewer on competition day (if ykyk) and the clear path to take was the old keyboard and mouse route. However, once the robot was built, these ports would be completely inaccessible, meaning we needed extender wires attached to the ports beforehand that come out to an external point of the robot that we could access. Originally, I thought that the Jetson Orin Nano was going to use an HDMI port. But, after taking a closer look, it was a Display Port. The problem with this was that when I ended up buying an extender for this, it was WAY too thick and did not fit. I even cut one open to see if removing the plastic shell could help (it did not). So, I had to buy 6 different versions before coming across a slim fit version seen in the picture.. A great learning experience, but it was very annoying.

Iterated complete main connection circuit of the robot

I spent a lot of time getting this circuit to be perfect since it was the primary electronic component of our robot. If something goes wrong here, the entire robot will be affected. Originally, I made the mistake of not knowing that there was a type of switch that only turns on when you hold it, and flips back off once you release it. Unfortunately, because of this, I had to restart everything with the proper switch. Other things I had to work on here was making good solder connections, putting heatshrink over every connection, looking at what wire lengths were the most optimal, and testing voltage of each part along the way. Another major event was that one of the buck boost converters stopped displaying voltage, which made me very confused. After over an hour of trying to figure out what happened, I realized the internal wire connection it came with was really, REALLY, bad. I fixed it, though, and the wiring works now!

Soldered wires onto motors

I soldered wires onto each of the motors since it was clear that it would be too hard to do once the motors are already on the robot. I wanted to attach heatshrink to the connection ports of the motors, but when i tried to do this, the heatstrink would just stick off of the ports and not work. Either way, I'm hoping that this has a good enough connection.

Planned out what parts would go to what battery

Most of this time was spent ideating and chatting between teamates. Since we have 2 4200mah LiPo batteries, we needed to find a good split between parts to make sure both run out at around the same time period. Note that one battery is solely powering the Jetson Orin Nano. This is because we realized that other power consuming parts, like the LED, can be attached to the USB port of the Jetson Orin Nano.

Printed all parts and took off supports

(PARTNER WORK & MY WORK)
(FYI I'm logging the time spent to adjust the 3d printer and take off supports)

We printed ALL the parts for the robot, with many having a great amount of tree supports that needed to be removed using flush cutters. Also, many times, the print ended up being unsuccessful due to starting the print too fast, print sticking off, or even some form of random error.

3D printed and tested claw iterations

Partner started to 3D print and test claw iterations (around 4). He needed to print it multiple times to tweak minor things, but this built version will likely be our final one (we might add stuff later tho)!

Developed 3rd platform system (testing still needed)

Added a microservo in the back of the third platform for controlling which section on the third platform is released
(in RCJ rescue line, silver balls representing live victims have to be released in one area, while black balls representing dead victims have to be released in another)

A “wing” was created to be attached to the microservo
This wing would rotate, and should allow one sides balls to roll off the ramp, while the others stays on the platform
However, when the wing tilts downward to one side, it’s possible for the balls on the other side to roll out too if they’re on the far left/right sides of the third platform
Lastly, bumps were added to the wings so that when one side tilts downward, and the other side tilts upward, the wings go up as well, preventing the balls on the far sides from slipping through

Finalized the initial working prototype of robot CAD

We created a third platform, a ramp structure on the back half of the robot, for storing victims (represented as metal balls in RCJ).
The ramp structure makes it so that balls will roll toward the bottom naturally, and a system will be created with the microservo at the back of the third platform for releasing the victims
Moreover, we created a battery mount that also functions as a mount for the distance sensors
A new platform (the grey one to the left of the camera) on top of the frame for attaching the buck boost converters is there as well.

We iterated the 3rd platform and the battery mounts numerous times to get to this version.

Fixed a problem with claw/arm to adapt it to robot design

The new arm/claw was lightweight, but additional changes had to be made when adding it to our robot, as when the claw is rotated upward/downward, the buck boost converter (represented as a blue box) as well as the linetracing camera (orange) got in the way

To get around this, the arm had to bend 90 degrees to remain centered. This is important because to find victims, we use the wide angle camera (centered and mounted on our front plate). This means that when the robot has reached the ball, the ball should be right in front of the camera at the center.

Partially finalizing the claw and arm (improvements)

Afterward, a lot of experimentation was done to ensure the claw would grab the ball securely while minimizing weight. We had to iterate many times (and print many times). Our design is below:

We stayed up overnight since our printer kept failing with our support settings for the final claw print, since it was not flat anymore. After playing around with the seetings, tree supports worked well, and the claw worked very well with a ball. Key features include:
Spherical design, allowing it to fit better around the ball
Thinner claw (roughly 1-2 mm thick, allowing for it to be solid without being bulky)

Now that the arm is mostly complete, working on claw design

We originally tried more flat claw designs, but after testing, this did not work because of key flaws. It was too complex and didn't secure the ball well, especially since the microservos aren't that strong. Soon, we'll try changing and iterating our design.

Continued to develop arm system for the robot

Two MG90s microservos added to control the claws
1 TD 8120mg servo with 20 kg torque for moving the entire arm and claw
This arm design was too heavy, however.
Also, it had to be printed in two parts, which isn’t efficient, thus was changed

Started developing a complex arm/claw system

Created arm-claw system, tested multiple iterations until a working version was established
First set out on creating an arm design.

We are aware that this will need additional improvement.

First arm design:

Developed initial front bumper prototype

Started working on the front bumper and figured out where to mount the camera for line tracing.
Built an arm-claw system and tested a bunch of versions until one finally worked.

The issue we're having here is that we want to keep the robot length under 25cm, but the front bumper makes it reach 24cm. However, removing it would not allow us to have LEDs on our robot.

Developed additional CAD for electronics

Threw in a voltage checker, distance sensors, the Jetson Orin Nano, an Arduino Nano screw terminal, and a buck converter (that grey box-looking thing).
Added a back plate that holds the distance sensors and voltage checkers on the left side, plus another frame on top of the baseplate to use space more efficiently.

Dropped in an Arduino Nano screw terminal at the front. Added two batteries, one on each side, to keep the weight balanced.

Developed front panel system for robot CAD

Made the front panels and stuck a camera right in the middle.
Slid the distance sensors between two plates to keep them steady.
Screwed those plates onto the baseplate and added another frame on top for extra stability, feels way more secure now.

We're really unsure about the ToF sensors right now, but we'll keep what we have.

3D modeled Greartisan 12V DC motors based off of online spec

Created baseplate for the robot and added screw holes for motors
Motor mounts are connected directly to 4 pillars on the corners of the baseplate
Motor mounts loop around the front and the left and right sides of the motor, leaving the top uncovered to place the motor into position