10/7/23

The general plan was established, based on watching the launch video.

Performance Goals:

Autonomous

Robot will use tensor flow to identify Team Element and place a pixel on the tape marked by the team element. (20 pts)
Robot will drop pixel in location marked by team element (20 pts) and park (5 pts)
Team will apply for autonomous control award

TeleOp

Robot wil place 5 pixels on the board (15 pts) to make a mosaic (10 pts) and cross the 1st line (10 pts).

End Game

robot fill fire paper airplane which will score 10 pts
robot will hang from truss (20 pts)

Design Constraints

Robot must fit within the 18” cube
To pass under the swinging door, the robot must be under 12” tall or have a mechanism to move the door without getting stuck.
The drone must start behind the truss, go over the 24” truss and travel 109” to land on the other side of the back wall to score points.

Sub-Systems

Chassis (4 motors)
1. The chassis wll use mecanum wheels so that the robot can drive forward and backward, rotate in place, and strafe both left and right.
2. the chassis will house the electronics and provide structure to help with wire management
3. the chassis will provide strong points for contacts with other subsystems
vision
1. The camera will be mounted to the robot in such a way that the camera does not interfere with the other subsystems and that it can see the april tags on the pixel board and the team designed element.
2. autonomous op will have a function that can detect the location of the team designed element on the game field.
3. autonomous will have a function that can identify the location for the yellow pixel on the back board using April tags.
pixel manipulator (1 motor, 1 servo)
1. The pixel manipulator will be able to grab, lift and place pixels on the game board.
2. The pixel manipulator will use a motor to lift the arm up and down and it will use servos to control the grabbing action.
drone shooter (1 motor)
1. the drone shooter will have an adjustable angle for launching the robot
2. The drone shooter will be optimized for the speed of the motor and the airplane to fly to a scoring location.
winch (1 motor to move hook into place, 1 motor to winch)
1. The winch hook will be set by moving a medium motor.

Tasks

CAD Design

Team designed camera mount
The team designed element for TensorFlow will be designed in CAD and 3D printed in both red and blue. This model will optimize the design for detection by Tensor Flow and minimum printing time.
Hook for winch will be designed in CAD and 3D printed. This model will be optimized for structural performance.
Grabber sides to work with the pixel grabber servos.
attachment for winch setter arm.
CAD drawings for each sub-system will be created and shared with judges at competition.

Vision

Tensor Flow
1. Team has 240 minutes of training time (4) 60 minutes. One session should be sufficient to build a working model. We will likely want to divide the session onto two groups, to train the red and the other to train the blue object. This means that we can make two models using the FIRST provided training for each TSE. Alternatively, the model
2. Videos should be made from different angles, different lighting but from the actual location of the camera on the robot and from the position on the field.
3. Videos of the Team Designed Element must be submitted by coach to the FTC for model construction. https://www.youtube.com/watch?v=LGSL5izjCKU
4. https://www.youtube.com/watch?v=MLNjARrsIMA
5. Resulting file will be TensorFlow Lite Model

run label studio on docker

docker run -it -p 8080:8080 -v %cd%/mydata:/label-studio/data heartexlabs/label-studio:latest label-studio –log-level DEBUG

Computer Vision

6 states to detect using computer vision, from two starting positions on each side.

red left, red center, red right

blue left, blue center, blue right

https://teachablemachine.withgoogle.com

Label Studio

April Tags

10/14/23

April Tags Testing

April tags were printed and tested using one of last year’s chassis. To view the camera stream, a hdmi cable had to be run from the robot to the computer. The feed was run through facebook live and then through OBS studio.

The robot will use April tags to place a pixel on the board in the correct position during autonomous driving.

10/19/23

Drone Shooter V1

Cailin designed, programmed and tested a drone shooter that was based on a single wheel spinning shooter.

Hand Held Test

Table Test

10/20/23

Cailin collected data on the performance of the shooter at different power settings. She plotted the averages of three settings and determined that there was a linear relationship. Based on the initial findings, the plane will not reach the target and some adjustments are needed.

10/21

Cailin coded and tested a prototype swing arm to place the hook for the winch.

10/22

Cailin coded a prototype winch today.

10/22

Cailin tested the prototype winch, and it worked perfectly. The winch rope was connected to the table using a girth hitch, so a hook or some other attachment needs to be designed.

10/27/23

Cailin coded two servos for a prototype grabber arm. The arm was tuned and tested with a single pixel. The arm was able to grab and hold the pixel and then release the pixel. The next step would be to mount the arm to the robot and develop designs to allow the arm to collect on one side of the robot and then deliver on the other side of the robot.

11/1/23

The robot field assembly was started by Calin. She assembled the pixel holder. It was important to assemble this component in order to test the grabber arm.

11/2/23

Cailin assembled the truss supports today. These were important to test the winch and paper plane, which had to fly over the truss.

11/3/23

The swing door was constructed for the robot field. This was important to test the performance of the robot when driving through space.

Cailin tested the winch with a coat hanger as the hook, and while it lifted, since the base of the winch was not in the center of the robot, it was lopsided. It took about 15 seconds to lift the robot.

Cailin weighed the robot to be 15.4 pounds.

11/4/23

The robot winch was tested with the swing arm and the winch using the coat hanger hook. It worked perfectly but slowly.

The robot was tested for clearance for driving under the yellow bar. The heights of the rear towers were too tall to pass under the yellow bar, so those towers were cut.

The towers were pushed to the back of the robot so that the swing arm could be as long as possible and still fit inside the robot’s footprint.

The mount between the swing arm and the medium motor axle was improved by adding a tetrix axle hub, which has a set screw and side screws.

The hook was tested again but the swing arm only operated in a single direction. To give it both directions, the entire mapping to gamepad 2 had to be changed. Under the new configuration.

When the swing arm was tested again, the motor was not strong enough to move it in both directions. The power had been .25, so it was raised to .75. Testing indicated that this was too much power and the arm was hard to control. A power of .50 performed similarly but less extreme. A value of .35 seemed to work perfectly.

The full set-up was tested by driving under the yellow bar and then setting the hook and lifting the robot. It will be important to have two operators comfortable with the gamepads because the operation of the robot on the game field is tricky.

11/5/23

I want to design an object that is easy to detect for tensor flow object recognition. The object needs to fit within a rectangular prism, that is 4″ tall and has a base that is 3″ on each side. The numbers 9721 must appear on the object and must be smaller than .5 inches in height. The object must be red and have no other colors. The object will be 3d printed.

Baked on the advice from BARD, a rectangle was designed with one side modified like a key. The rectangle was then rotated about the opposite axis to make the cylinder with grooves. The grooves were straight so they were chamfered to make smoother grooves that would be easier to 3D print. The grooves were added in the event that another team also designed a cylinder and in hopes that the model would be able to discriminate between the two cylinders. The model was then shelled from both sides and printed at a fractional scale that took about 30 minutes to print. The prototype will then be evaluated for the ease of the model to recognize the correct model when on a field with an incorrect model.

A robot arm was designed using a similar design from two years ago.

The original plan to rotate the arm used pulleys but it didn’t work because the set screw could not be set tight enough.

A second design was tested using a chain and sprockets. This design worked, but there was so much stress on the system that the column holding the top sprocket bent, which created slack in the chain and made the model unstable.

The next step would be to brace the motor axle and the top column better.

11/5/23

Cailin revised the arm by making a direct mount to the motor and raising the motor to a higher position on the axle. This eliminated the need to transfer power from the motor to the axle with a chain or pulley.

This design worked fine and was bench tested. The testing revealed that there was a difference in the geometry of the axle brace and the motor axle, which created an imbalance in the towers.

11/6/23

The arm was modified with a different axle holder which allowed the two columns to be aligned. This allowed for a C channel to be added as a brace to support the tower.

Bench Test V2

The servos were tested in the original configuration, which was based on designs from 2021. The testing indicated that the arm could place the pixel in the scoring element but that collecting the pixel would be difficult.

11/7/23

A 120 degree bracket was added in an effort to make the grabber parallel to the ground, which was considered the best way to grab the pixel from the side.

Bench Test V3

The gripper was re-assembled after some cutting. This resulted in an accidental design, where the gripper grabbed backwards instead of forwards. This design was tested and it worked well. But, grabbing the pixel was still difficult.

Field Testing V3

The gripper was re-assembled in the original configuration with the 120 bracket and tested. This worked better, but the single tire did not give the gripper much room to grab the pixel.

An additional wheel was added to the gripper which improved the performance of the gripper. In testing, it was determined that the gripper was currently hitting the floor when the robot drove, which created a hazard. The arm also make the robot extend beyond the 18” size limitations.

Grabbing 1 pixel V4

Driving and Collecting Pixels V4

A proposal was made to modify the arm in order to prevent the gripper from hitting the floor. There are several ways to accomplish this task: the arm could be reduced in length. Additional servos could be added to articulate the grabber so that brace could be removed and replaced with servos.

11/8/23

11/9/23

Cailin cut the arm to length so that the robot can drive freely.

Cailin also replaced the swing arm motor with a servo, which reduced weight and did not change performance. This also saves a motor port for another use.

Cailin modified the configuration file and programmed and then tuned the servo by mounting the horn after testing the servo’s movement.

Cailin tested the servo swing arm and demonstrated that it worked correctly but might need to be cut to size. The attachment for the hooke might also need some work.

11/10/3

Cailin tested a second prototype drone launcher. This launcher uses an elastic for power and a servo as a trigger. The design was inspired by the team that made this video https://www.youtube.com/watch?v=myP1QPth3ZU

We tried 3-D printing the designs but our printer needed some maintenance so a metal design was made.

There were also some tests of the drone design. The best designs appeared to hold the wings together and not have floppy wings. This was determined using scotch tape to hold the paper plane together.

11/11/23

Cailin, Yorda and Kayla met at the SBHS Scrimmage. They were the only female robot operators. Another team had a pair of girl that did the machine learning elements for their team.

Cailin brought double sided tape and play dough to experiment with for releasable mounts to the swing arm. These mounts did not work.

There was a significant problem with the servo horn. We were using a plastic servo head that would not attach correctly to the servo. This was not a problem in practice, but was a problem at the competition. Replacing the head with a metal horn makes sense.

Wire management and labeling cost the team considerable time. The team needs to use some type of labeling system to make it obvious which wires are connected with with components.

The gripper arm operation was not intuitive to the operators. This became manifest when the operators would conduse whether they were moving the wrist or moving the arm. Sometimes, the swing arm would move when the arm was trying to be moved and so on. Another version of the software should be considered based on a discussion with the operators that might make sense.

During practice, the winch became loose and did not catch when it was being operated. The team practice setting the winch but it is not easy to maintain tension in the winch and leave slack for the swing arm.

During practice, the team also discovered that the servo mount for the wrist was bent, which caused an imbalance between the two sides.

The team participated in the first scrimmage but the hook came off the arm and then the arm fell off the sevo. The robot drove well and fit underneath the center truss and could pass through the swinging gate. The team tried to push some pixels but the robot drives over the pixels. Adding something along the bottom of the robot makes sense.

In practice, the robot gripper arm struggled to grab the pixel consistently. It might make sense to have the gripper arm grab the pixel directly from a V shaped intake bumper, to make collection easier. This might work well with an inside grabber instead of an outside grabber.

The arm itself is hard to operate for several reasons. First, the arm is not attached securely to the axle because the REV hubs allow for too much wiggling and the hubs are held in place by pressure and not mounted directly to the extrusion with fasteners.

Second,the arm does not move consistently through the range of motion because the shifting forces caused by the servos This could be mitigated if the servos were not on the end of the arm or if the joint. This could also be mitigated if there was a mechanism to hold the motor’s position while it was moving. As of right now, the arm is not stable when it is held in a position mid-way between vertical and horizontal. That needs to change if the arm is to be useful.

One of the other teams used the machine learning through FIRST. They added objects for both the red and the blue marker. Their marker was a short cylinder, which was recycled from the last year’s cone cap. They printed on sparkly filament and had a single tall post for detection. They trained their models for 55 minutes for each object and used separate models for the different alliances. This made their model sensitive to color and not just shape.

All of the of the other teams used GoBilda systems, except for a new team that was using tetrix and us. All of the teams used mecanum wheels. The GoBuilda basic robot kit was operated by one team and they could hang, grab pixels and so on. This is likely to be common. Scoring the paper plane and autonomous will be critical if the team wants to improve their standing.

At this point, it seems like the team needs to consider some design changes.

Move to goBilda chassis system
Use gobilda arm for lifting or use tape measure winch system.
Design TDE for machine learning and start working on autonomous once gobilda system is assembled.
Build Machine learning model for autonomous
Develop Autonomous routines for both red and blue from two different starting positions
Practice driving with arm to get as many pixels as possible

swing arm failure

11/20/23

Cailin, Kayla, Sage and Yorda all met yesterday. They drove two different mecanum chassis and in order to get a better feel for the rev 2” wheels versus the AndyMark 4” wheels. The team determined that they preferred the AndyMark 4” wheels for driving forward and backward but that the wheels were unreliable when strafing. If the priority was to score points in autonomous, then the strategy would be to use the smaller wheels that would operate better.

The team evaluated two different drone shooters. Version 1 was a modified spinning wheel shooter. The advantage to this style is that the whole system occupies less space when compared to the elastic shooter. A disadvantage is that the use of the motor increases the overall weight of the robot, making it hard to lift and drive. Another disadvantage is that the fuselage of the plane has to be calibrated to the gap between the shooter wheel. This is an issue with the fixed dimensions of design and the team’s experience using paper plans.

Version 2 used a modified elastic with a guide. The advantage of this system is that it is lighter and simpler when compared to the first version because it uses a servo instead of a motor. The disadvantage to this design is that it takes up more space because the elastic has to be pulled back to load the plane.

The team discussed how to make paper airplanes and some design choices. The team determined that the plane needs to hold its shape and that a dart design would work best with the elastic shooter. Toward this end, the team folded this dart design from a youtube video.

The team also conducted some tests of the drone shooter, v2, using dart planes. The drone shooter uses elastic bands with a servo trigger. The team measured the flight to be 96”, which is a good improvement over previous prototypes. The drone needs to fly about 109”. The launch angle was about 45 degrees.

The second flight was analyzed using tracker pro, which led to the following conclusions:

The plane did not follow a ballistic trajectory on the way back down. It dropped much slower and the path was not symmetric, which would be the case with ballistic motion.
The plane needs to fly further, meaning a higher initial velocity.

The team has several problems to overcome in the next practice.

Modify arm to make it easier to manage the pixel
1. add counter weight
2. use different design
How to mount the assembly to the robot.
1. use axles on both sides
2. use brackets
How to increase the initial velocity of the dart.
1. use different elastics
2. use springs
How to frame the video to analyze the flight of the dart.

Shooter V2

11/21/23

Cailin mounted the shooter to the robot so that it was on the side of the robot and out of the way. She tested it several times and it worked great.

Cailin, Kayla and Yorda met today and working on the drone shooter. The team used tracker pro to determine the initial velocity and launch angle of the drone. The team determined that the drone launched at around 5 m/s with an initial angle of 26 degrees. The plan flew about 90 inches. The trajectory of the plan showed that it was not ballistic because the curve was not symmetric about the peak height, which is the case for projectile motion. Instead, the plane glided to the ground and did not achieve symmetrical speed.

The team then ran an analysis if their data using Bard, to determine the optimum launch angle based on the shooter’s specifics, including the initial height of the plan at 10 inches, initial velocity of 5 m/2. Bard returned an agle of 21 degrees, which was close to the current angle. However, the robot did not appear to actually have 5 m/s initial velocity. It appeared to fly closer to 80 inches.

The team decided to make some adjustments to the shooter to give the plan for time to fly. They decided to change the mount of the plane by mounting an extrusion to the shooter and then mounting an axle cushion to hold the assembly in place using an axle. This would allow for easier adjustments to the launch angle and initial height.

With the additional adjustments to the mount, the plane flew great but the initial angle did not appear to be sufficient to correct the flight path. The next step will be to increase the initial velocity using a different elastic or a spring.

Alternatively, it might make sense to consider returning to the ball shooter approach, which has the potential to generate much high initial speeds.

Measure Shooter Sage

Measure Shooter Yorda

11/25/23

At the last practice, the team printed two braces to stabilize the guide path for the elastic based drone shooter.

Cailin modified the shooter by attaching these mounts.

She also modified the shooter by adding more tension to the elastics. Initial testing was a dramatic increase in the distance traveled by the plane, which gave this approach merit.

The system was videoed using slow-mo to try to better model the trajectory, to determine the initial velocity of the plane, to better control the launcher.

At this point, it became clear that grabbing random elastics from the “junk drawer” might post an issue to reproducing the results. A quick scan of staples indicated that rubber bands come in a variety of sizes, shapes, so the team would need to identify the specific type of elastics band used in the shooter if the team hopes to be able to model the trajectory consistently.

There is also some concern over the degree to which the elastic design will withstand driving around during the competition.

Another concern is that the impact of being pushed along the guides appears to damage the back of the planes. This means that the team would need to have multiple planes on hand and hope that they all perform about the same.

During the few trails she completed, the robot flew at least 10 feet horizontally before landing on the couch, which was at least 12 inches off the ground. At the next practice, she plans to repeat the tests outside so that the video analysis can be more complete in hopes to modeling the trajectory better, so that the plane can be controlled.

11/29/23

Cailin tried to test the drone shooter outside, where there would be sufficient space to video the entire flight in a single frame without having to move the camera to track the drone. However, the drone shooter had to be redesigned instead because the sliding mechanism came out regularly. This could happen when the robot was operating, which could lead to a premature or failed launch.

The problem of the unstable slide resulted from the previous redesign, which mounted the drone shooter to the robot pl placing the shooter on an axle to allow for easy repositioning of the shooting angle. however, when this was done, the extrusions needed to be mounted to the plate and then the bushings to the plate with long screws. In order to maintain the alignment of the bushings, holes were selected for mounting that were not symmetrical with the optimal spread between the extrusions because there were a limited number of fixed positions and they did not align with the bushing holes.

Cailin felt it was important to address the problem before conducting more advanced analysis because the analysis would require that the shooter perform consistently. This meant that the slide would need to by fixed in place so that it could not fail. This also meant replacing the “junk drawer” elastics with new elastics with a known size and characteristics.

There were at least three different ways to address this problem. A new pillow bearing could have been designed and 3d printed. This would take 2-3 hours of printing and an hour of desgin time for 3 hours of total time. The team’s CAD computer was in the shop being repaired, so this option was tabled.

Another option would have been to have modified the slider to be wider, so that it could not slip. This would require cutting or adjusting another piece of flat aluminum and cutting 2 holes for the catch mechanism mounts. This included the possibility of having to use a band saw or table saw to cut the aluminum precisely and the band saw was not set-up and the table saw did not have a metal cutting blade.

Another option would be to design the floor of the drone design and cut custom holes in order to optimally align the existing slide with the extrusions. The team had an existent piece of aluminum that needed a single miter saw cut and then 6 holes drilled from a drill press. The team’s mitre saw and drill press were ready to go, so this option was selected.

Holes were marked with a pen using the pillow bushings as a template. The cutting point was determined by marking the end of the REV flat against the piece of aluminum. The cuts and drilling took about 10 minutes once the equipment was set-up. The revised shooter was assembled and is now ready for testing.

Next practice the team should evaluate the shooter using the new elastics using video in slow motion and tracker pro to analyze the movement of the drone.

11/30/23

Cailin tested the new design at Petra Cliffs because it was too windy to do the testing outside. She is a member of the Dev. Team at Petra Cliffs and they happily allowed her to test the robot during the school day when the gym was mostly empty.

During the first test, she used the smallest rubber bands and the plane’s flight was about 54”. Cailin decided that the small elastics were not sufficient for propelling the robot.

She replaced the rubber bands with the largest rubber bands and re-tested. The plane flew much further and mostly straight. However, on the second test flight, the drone got stuck in the robot and smashed by the pusher. The next flight was poor so the plane had to be replaced. This raises the concern that the team may need multiple planes for competition day.

Additional tests with a different plane were similar but not easily repeatable. The base of the launch was not fixed to the robot, so it could slide and change in the initial launch angle.

These flights, however, were impressive with the plane routine flew 10’ or 120”. The plane would move about a foot off of the centerline, and it happened on both sides of the centerline. This can be used to make a model of the ideal firing position for the drone.

The team will need to analyze the video to determine the ballistic stage properties, initial launch angle and initial velocity. This will allow the team to compare the ballistic trajectory to the flight trajectory and create a regression model.

Thick Elastic Bad Angle

thick elastic bad launch

Thick Elastic Damaged Plane

Thick Elastic Strong Plane

Thin Elastic

12/1/23

Cailin worked on modifying the winch design. The new design was based on the idea of using a tape measure winch, which has been done by many other teams over the years.

Other teams attached a tape measure to a motor so that when the motor operated in one direction, the tape rose vertically. Since the tape measure is stiff, it can reach a considerable height before it falls over on itself. It is also soft, so it can hit something else and not get the robot stuck. When the motor is operated in the other direction, the tape measure wraps around the axle and lifts the robot like a winch. If this works, it would reduce the overall complexity of the robot by removing the swing arm from the previous design. It would also eliminate the risk of the winch rope getting stuck on moving parts while the robot is operating.

In order to make a tape measure winch, Cailin took apart a tape measure. She did this by removing three screws that held it together. This exposed the tape and the various sliders. In youtube tutorials, the other tape measures were held in place by a flexible plastic axle. Her tape measure, however, would not come out and there was no obvious way to remove the tape measure.

After exploring the tape measure completely, it became clear that a sticker might be blocking access to a screw. The sticker was removed and then the screw was removed, which released the tape measure.

This process made it clear that the inside of the tape measure had a metal spring attached to the tape measure with a slide lock mechanism. This made it easy to remove the tape. Likewise, the spring was attached to the spool with a similar design.

An inspection of the spool revealed that the central hole on the spool was too large to fit the hole pattern of the tetrix axle hub, which was planned to be used to attach the spool to the axle. Thus, Cailin took a series of measurements using calipers so that a 3d designed part could be made to replace the spool.

The team used Fusion 360 for the first time because the team pc was damaged so an apple computer had to be used. The spool was made from Cailin’s measurements by first making a circle. The circle was extruded to Cailin’s measurements. Then, a second circle was made on top of the first extrusion. This circle was extruded to make the interior of the spool. This was then shelled. The rectangular holes were made by extruding a rectangle shape through the whole spool. The axle hole was then made using a cut extrusion on the bottom of the design. Finally, the mounting holes were made by making a circle and using the circle pattern feature to make four holes in total.

Then, the part was copied and renamed. Once it was renamed, everything but the bottom was deleted. This left a design that could make a cover for the other side of the spool to keep the tape in place.

The team still needs to test the spool design with the winch.

The team should also explore using Git for version control of the OpMode.

12/2/23

Cailin began assembly of the tape measure winch to prepare for the cvu scrimmage on Saturday.

The spool fit inside the housing perfectly.

She drilled out the holds in the tape measure housing using a drill press.

When she checked how to best connect the new spool to the housing, she discovered that there is no way to attach the tetrix axle connector inside the housing because the set screw is not oriented toward the hole for the tape measure. This meant that the axle hub had to be mounted outside of the spool.

The tape was attached back to the spool using the initial connection. However, the tape did not want to remain tightly wrapped.

When the tape was fully wrapped around the spool, there was a great deal of energy in the wrapped tape.

The housing was considered important to give the tape a direction to move when the spool was rotated.

It might make sense to go without the housing if that will work.

While the tape measure may work, it might make sense to shift into thinking about the arm from GoBilda robotics for the lft.

The REV arm needs to be addressed.

The team still needs to build a shape to detect with the machine learning model.

12/4/23

Cailin tested the winch today. The hook was attached to the winch with duct tape because this was easy and fast.

The unspooling of the tape measure was tested, which showed that it worked, but there was a tendency for the spool to unwind. So, the movements have to be consistent and not pulses.

When the robot winch was tested, the spool and duct tape attached hook worked but the motor spun when the power was released. This suggests that the rotational force of the resting robot is sufficient to cause the motor to move when not powered.

The robot had a considerable lean because the winch is not centered. It is mounted slightly to the left, making the right slightly heavier. The lean is concerning because it takes more time to get the robot off the ground and because the lean might cause damage to other parts as the robot moves while being lifted. This damage might result in repairs or terminal damage during a competition.

There are several ways to address the placement of the winch. One would be to slide the current mounts to the right until they are balanced. This may result in re-mounting the arm, which is currently centered and shares a mount with the winch.

Another way to address this issue would be to separate the mounts for the arm and the winch by adding another parallel mount extrusion so allow the winch to be centered and the arm centered separately.

Another way to address this problem would be using the glbilda set, which can use the arm to both grab pixels and pull itself up.

The only reason not to use gobilda is cost and time to build. The team could build the gobild robot over Christmas vacation but not on Christmas day.

Tasks to be completed:

re-mount the winch to the robot so it leans less.
mount the arm so that it is more firmly connected and can hold a pixel.
Adjust the front to be able to push pixels.
Design the Team Element for machine learning
GIT the programming.
train the machine model
integrate the machine model
develop autonomous for red
develop autonomous for blue

12/7/23

The robot was not able to hold its position yesterday during testing. Since the robot did hold its position with the string winch, it seems likely that the larger spool to hold the tape is the problem. The spool could be a problem because it creates a lever effect becacuse the force of the robot is applied further from the axle using the spool.

There are at least two different ways to address this issue. The length of the tape fills the spool, which makes the tape further from the spool. If the tape were cut, the tape would be closer to the axle, which would reduce the lever effect. In addition, the spool diameter could be reduced to be just slightly larger than the axle.

The plan for today is to cut the tape and test the robot with a smaller amount of tape. This has the added benefit of reducing the chances that the tape will expand and lose connection to the axle while being unspooled.

If this does not work, the spool will be redesigned and reprinted with the shorter length of tape. This takes 45 minutes to print and 20 minutes to design. If the spool is removed, it could be mounted to place the tape further at the back of the robot to make it possible for robot to be lifted cleaner.

Initial testing of the reduced tape measure showed that it was an improvement, of sorts, but it did not correct the problem that the robot could not hold its position and hang at the end of the match.

12/8/23

Cailin modified the tape measure winch by cutting the tape to reduce the lever effect of the larger diameter spool. When she tested this, the winch worked better but it still could not hold its position.

To address this problem, she designed a ratchet that could be placed on the axle with the spool. The vision was that the spool could move in either direction so that the winch could be raised and then lowered to lift the robot. However, once the robot was off the ground the brake would be applied to prevent sliding back.

The ratchet was designed in fusion 360 by modifying the existing design for the spool cover. A spline shark fin was added to the spool cover. This feature was then rotated about the center of the wheel cover to provide complete coverage. The stl file was processed in Prusa Slicer and then printed on a Prusa ML3+ using PLA.

Cailin also worked to mount the drone shooter on the robot. It was very difficult to image how to mount the drone shooter because it was long and tall and there were no existing mounts that worked to place a flat piece of metal on top of an extrusion that was cut at 45 degrees. 45 degrees was selected because it is an optimal angle for the projectile portion of the flight and we already had a pre-cut extrusion at 45 degrees.

The team had some older metal 90 degree brackets which are soft. This allowed the bracket to be bent to 45 degrees. The flat section of the drone plate was drilled with a drill press to allow a m3 screw to pass through it and be connected to the brace. During assembly, the screw blocked the extrusion so it was replaced with a longer screw and the head was placed into the extrusion and both the extrusion and the flat plate were fastened to the robot.

During this process, the front left mecanum wheel came off the primary chassis. This has been an ongoing problem because the set screws cannot be accessed once the robot is fabricated. So, replacing the wheel requires disassembly of the robot in order to remove the motor mount from the chassis and then the motor from the mount in order to access the set screw. Then, the entire process has to be repeated. Since this could happen at a competition without warning, the team decided to transfer the testing to the other chassis which is more robust but less accurate during autonomous operations.

12/10/23

Cailin and Kayla worked together today.

Their first task was to move the winch from one chassis to the other. In order to get this to work, they needed to also install an expansion hub.

To install the expansion hub, the team had to make a data connection and a power connection. This worked fine.

The team then focused on moving the winch. To do this, they had to mount parallel extrusions. This took some time because the chassis had to be disassembled in order to make room to add the necessary braces.

When this was done, the code had to be modified to make the robot work. Running the code was fine. However, we could not set-up the expansion hub because it was not detected by the robot control hub. We suspect the problem is that the expansion hub is out of date but we cannot update it because the rev hardware package does not run on a mac computer and the pc is still in the shop. However, we can test the system using the other robot, which is currently the plan.

During manual testing, the robot was able to hold its position.

When mounting the drone shooter on the second chasses, it was too tall because of the different in heights of the mounting. The team considered several ways to manage this problem, including cutting down the post, cutting down the plate and making the position driven by a motor.

On balance, the team felt that the best way to proceed was to cut down the plate of the shooter. This was considered important because it reduces the overall length of the device, reduces weight and does not impact the force from the elastics by changing the distance they are pulled back.

12/11/23

Today, we needed to fix the expansion hub.

Cailin troubleshooted the problem by first, plugging the wire that connects the data for the control and expansion hub.

When that didn’t work, she connected the battery directly into the expansion hub, which was successful; one, in making it clear that the expansion hub works, and two, narrowing the problem down to the wire.

Cailin deduced that the power wire that transmits the power from the control hub to the expansion hub was faulty, so she found a switch that would do the trick.

Since the expansion hub now worked, she could stop using the other robots ports and use the right robot. She unplugged the motor from the other robot and put it in port two on the right robot’s expansion hub.

She then connected the servos on to the robot and programmed them to work as they had on the last robot.

Tomorrow, they will have to put the robot together, make sure the airplane lasts while driving around, and mounting the lights.

12/12/23

Today, Cailin put the robot together, and drove it around with the airplane. It went surprisingly well, and she then proceeded to launch the plane and it flew well. They then redid the brace that kept the winch in the right spot, and the winch went up perfectly.

She then tried the winch, and fired the brake, but the brake did not make enough contact with the winch. She reprogrammed it and tried again, but even though the teeth and brake were making contact, the teeth were too small to stop the robot.

Tomorrow, they will redesign and 3D print another spool cover with larger teeth, make the airplane launcher lower, and make the brake fire automatically.

12/13/23

Cailin designed another break. This break was thicker and had larger teeth. She designed the brake using fusion 360 and printed the part on the Prusa mk3+ with red pla. This part was designed to address the problem of the robot sliding down while hanging. It is not totally clear why the brake stopped working but the placement of the parts appears to have slightly changed. It is hoped that the new part will work in a wider variety of arrangements so that it is less sensitive and more effectively.

Cailin also mounted a 2m distance sensor on the bottom of the robot. The sensor is used as a trigger to fire the brake, to hold the robot’s positon when hanging. She developed the code by creating a sample opmodel in onbot java. She copied and pasted the libraries, the declaration, the instantiation and the telemetry code from the sample and combined it with the previous code she wrote to trigger the servo with the distance sensor.

She is working on a new workflow where the program is editing in VS Studio, which is connected to the GitHub repository. The code is then copied and pasted to onBotJava and built to the robot.

12/15/23

Cailin is installing the new brake and testing it today. If she can get this done, the next step will be to work on the robot arm.

The installation of the brake went fine and it works great. However, the spool doesn’t unwind the tape measure correctly. The problem is that the tape becomes unwound as the spool moves, so the tape gathers in loops around the spool instead of going straight up.

Cailin tried numerous things to keep tension on the spool but none of those efforts worked. The first effort was a plastic L bracket which was mounted to the winch cover base. This was held in tension using an elastic that went around the motor.

The next effort was a tetrix 90 degree bracket that was mounted to an extrusion with a piece of foam. This created too much tension and made the problem worse.

A third effort used a rev extrusion as a spine, and this showed promise but it was not tested.

Since the original tape measure had a spring inside, Cailin explored using a spring inside the winch spool to maintain tension. She attached the spring to the tape measure connector after drilling a hole with the drill press. During testing, the spring didn’t make a difference. Moreover, during testing, the tape measure broke at the connection point and it need to be replaced.

A visit to Lowes resulted in an informal comparison of the tape measures in the store. Each tape measure was extended to 2 feet and locked. Then, the tape was wiggled. The tape measures were compared, two at a time, to determine which tape measure was the most stable. In the end, the best tape measure was selected.

Fortunately, the tape measure used the same connection as the old tape measure so the spool did not have to be taken apart. The tape measure was drilled to mount the hook and then cut to size and connected to the spool for testing.

The spine was reattached and everything is ready for testing.

12/16/23

The robot winch was tested today. It worked perfectly.

12/17/23

Cailin worked on the arm. It was not removed from the original robot because it had everything that was needed for testing. She tested if a chain counterweight could help the arm operate better. The counterweight from the chain was not sufficient to make the arm work.

Cailn then tried using some elastics to support the arm. Four elastics was too much and the arm could not reach the ground. Three elastics worked great.

Cailin tested the arm and it could lift and deposit a pixel and operate much more smoothly than previous efforts.

Test with Elastics

Pixel Placement

Cailin and Sage met today. They did a full test of the lifter and airplane shooter and both worked. The airplane did not go as far as expected but the lifter and brake worked fine.

Cailin and Sage then attempted to transfer the arm and the cross braces from the first robot to the second robot. This process was straightforward but they had difficulty re-attaching the braces. Cailin used an allen wrench to slide the nut into place and then twist it with her fingers. Sage used the technique to attach the opposite side. They worked together to move one wire at a time and Sage took notes to make sure that the changes were correct.

The robot now needs to have the software moved from robot to robot to integrate the arm operation with the rest of the robot. Once the software is moved, the arm can be tested to determine if any changes need to be made to the specific geometry now that it is on another chassis.

12/18/23

Cailin moved the code to operate the arm from the original robot to the new robot. She also placed the code into methods to make the code easier to read and understand.

12/19/23

Cailin designed and printed the brackets to hold the arm onto the elastics and the robot. She did not install the brackets yet.

12/26/23

Cailin evaluated the shooter. After the team mentor, Luke Fitzgerald, explained to her how the springs were related to the potential energy of the plane, she added two more elastics and rested the shooter. It worked much better because more energy.

The shooter was also tested using the spinning wheel but that design was abandoned because the dart plane design did not work well with it and the dart plane was considered an accepted design.

There is not a consensus yet on how to manage the height of the shooter problem with the robot. Cailin considered a horizontal cut and a vertical cut to the shooter to get the design to fit under the truss.

Cailin then mounted the new brackets to the robot to simplify the arm operation. This worked well. She attached the elastics to the robot using a screw and a post with the new braces.

12/27/23

Cailin worked today and zip tied the electronics wires. Some supports were placed to move the electronics off the ground. A new paperplane was designed after Luke indicated that he felt the plane design might not pass inspection.

Cailin moved the plane launched because of a fear of contact between the gripper and the launcher. The launcher was moved backwards in the plane. When tested, there was no problem.

However, the arm appears to obstruct operation of the winch, so some changes may be in order.

Testing indicated that the pixel could pass through the space.

Several new plane designs were tested before accepting the final design. The first design flew well but did not hold up to the shooter when tested. The shooter went so fast that the plane got crushed into the back of it. Several efforts were made to address this issue such as reducing the number of elastics and sliding the nuts back to reduce tension. However, these changes did not make the design functional.

The next design was between the dart and the last design. It had more body and was longer, so it seemed to connect better with the guide. When tested, this plane worked well.

Plane Test New Design

12/28/23

Caiin, Yorda and Sage all met today. They reviewed the tasks for the machine learning and considered how the design a Team Element that would be ideal for tensor flow object detection. The documentation from FIRST indicated that the model would do best with visual textures such as zebra stripes or bright neon. This realization made the team reconsider the important of 3d printing versus using multiple shades of red and blue, respectively, to make the object easier to detect. They considered using different types of washi tape and cricut vinyl patterns.

They also watched a video on collecting the data for the object training. Yorda volunteered to take over the machine learning portion of the project. The plan for moving forward will be to design the object and then take pictures of it from the robot at two different starting positions. The object will be placed at multiple spots for each of the three lines where it could be placed during competition, 6 positions per line for 18 positions total. The pictures will be repeated in multiple lighting scenarios with low, normal and high light. This will be repeated for the blue side. It is important to also have empty frames with no object but with the game elements.

The team also tested in the airplane launcher with the new planes. In a preliminary analysis of 5 launches the plane scored in ⅖ but did not clear the back wall in ⅖ and failed to launch in ⅕. To address the failure to launch, Yorda and Sage took measurements using calipers to design a U insert to mount the plane to the elastic trigger. The hope is that the plastic mount will make the whole process easier on the plane and make the plane re-usable.

Plane Test Slow Motion 1

Plane Test SlowMo No Trigger Guide

Plane Test slowMO no Trigger Guide Test 2

Plane Test Slow Mo NO Trigger Guide Test 3

12/29/23

Cailin tested the Tensor Flow Object Detection opMode and mounted the camera. She connected a HD Display to the hdmi port of the controller hub and connected the usb from the display to the laptop for power. The HD display showed the video feed to help understand how the object detection was working.

The white pixel was easily detected in high light situations. In low light, the object detection did not work well. The detector also seemed much better able to distinguish color from shape as evidenced by false positives with a paper airplane. The model also detected the yellow pixel but not the purple, which we thought was due to yellow being more similar to white than purpose is similar to white.

The model also appears to have been trained with the object facing the camera and not on the floor, lying flat, because the model did not detect the white pixel in that position.

This preliminary work suggests that the color and lighting are essential for detecting the object. Ideally, the team would take the training photos at the gym at CVU in different lighting conditions throughout the day. and in different starting positions. In an ideal arrangement, the team would also do this on both sunny and cloudy days.

Assuming the team designed element is radially symmetric, there is no need to rotate the object at each position. If there were a need, they team would have 4 or more rotations to capture the different orientations at each position.

Each starting position would have the following photos.

Red Left

Line 1 6 positions (across the line to reflect the random place where the object could be placed)

Line 2 6 positions

Line 3 6 positions

This would be repeated for the other red position and then the two blue positions.

This whole activity would be repeated hourly, from 8 AM to 5 PM to capture the different lighting scenarios. It would be important to train the model on a day that was considered sunny and on another day that was considered cloudy.

The team will probably want two different models, one for red and one for blue, as opposed to a single model. This should reduce the training time by reducing the training data.

Cailin attempted to mount the new airplane guide, but there was no way to mount the guide. She considered several different ways to modify the guide to make it easier to mount. She consider merging the guide with a REV 90 degree corner bracket, which was easy and would allow the part to mount like the corner bracket without any additional measurements or CAD work.

However, she decided to extrude the back side to make a tab for mounting with two holes.

12/30/23

Cailin tested the place shooter with the new part. The place was tested four times. On the first trial, the plane flew perfectly. On the next three, the plane flew almost identically but too short.

Cailin adjusted the nut position on the extrusion from 4.75 inches from the back of the extrusion to 5.5 inches, in order to create more force to fly the plane further. The plan was to take repeated measurements to attempt to better describe the flight performance of the plane. However, when she attempted to reset the plan with the trigger, she pulled on the new part, which broke.

She reprinted the part and continued. The plane flew perfectly but the part broke on impact with the extrusion.

Plane Test Guide Break Video

She re-designed the part and added a guide on the front of the part so that it would slip into the extrusion. She took measurements of how the plane holder and plane fuelselage interacted, which showed that the holded need to be extended another 2.5 inches in order to be seated in the extrusion while also in the trigger. The considered at least (3) different designs, including extending the length of the plane holder another 2.5 inches, which would take the longest to print and could potentially interact with the wings. She consider a triangle design, which would have been half the material and time as fully extending the design. She decided on the least material approach, which was to make a small rectangular extension that was smaller than the previous two designs but which should be sufficient to correct the problem of the broken plane holder. She also learned a new extrusion technique, which was to extrude to an object to make the front of the part symmetry with the existing part. While she was doing this, she increased the thickness of the brack in the back to reduce the chances that it would break. She did not decided to increase the infill, which is another possibility.

The plane was tested once and it worked perfectly. More testing needs to be conducted.

1/1/24

Cailin tested the airplane today and it scored 30 points on each trial.

1/2/24

Cailin modified the plane shooter by cutting it with a miter saw in order to fit under the 14 inch yellow bar. She decided to modify the design with a cut that was parallel to the floor because it preseved attachment points on the flat metal base, which would have to be re-drilled if the cuts were vertical.

After cutting the bars, Cailin noticed that the cuts were not identical despite her best efforts to keep them equal. She decided to keep the backs aligned, to present the tension on the elastic and keep the distance to the trigger the same. She tested the revised design and it work fine despite looking a little sketchy.

Cailin then tested the robot to drive under the 14” bar and she discovered that the pillars for the arm were too high. She took the arm assemly apart and cut the bars ½ inch shorter so that they would fit.

When everything was put back together, she drove under the bar and the plane came out. The top of the plane is slightly higher than the bottom of the bar, but just barely. Cailin pulled the trigger back, just a little bit, and the plane fit under the bar. This also changes the flight tragectory a little, beacuse there is more tension the elastic.

When tesitng the driving, the robot was too fast. Cailin reduced the power several times to get it drive more smoothly but the robot get getting stuck.

The bottom of the robot was not secure enough for driving. Duck tape was added to keep the expansion hub from calling and the hd cable was removed from the driver hub. With these modifications, the robot drove predicatably.

1/3/23

Cailin conducted further testing today, to see if the robot could pass under the swing. When driving under the swing, so that it could swing, the plane was hit by the swing arm, which knocked the plane off of the robot three times in a row. This does not seem like a chance event but something that will happen every time.

Test Drive Swing Arm2

Test Drive No Plane Under Truss

When pushed, the swing rises along the motor and then falls onto the plane. A guide could be created to prevent this, but the guide would prevent the robot from clearning the 14” bar. Perhaps the arm could be used?

The team could decide to avoid the middle of the course because the robot can drive under the side pathways.

When driving in the opposite direction, the robot arm was able to lift the swing and drive under once. The act could not be repeated because one of the custom printed brackets failed and the arm could not operate successfully with only a single bracket.

An inspection of the failed bracket showed that it broke on the front end, and the closer bracket, which was attached to a REV HD axle hub and not a tetrix motor hub. The bracket could be enforced in a number of ways, such as: printed with greater infill, printing a thicker bracket and replacing the rev mount with a tetrix mount. Printing with more infill does not change the geometry. Printer a thicker bracket changes the geometry slightly. Replacing the rev hub with tetrix should work fine.

The robot could drive under the 14 inch barrier.

Test Drive Backwards

Cailin decided to reprint the bracket with greater infill.

When the bracket was finished printing, Cailin re-installed the bracket. She also added a second tetrix motor hub, which simplified the overall design by eliminate two collars, the rev hd hub. She also reduced the bushing from a large to a small to reduce the freedom of motion of the axle on the brackets.

KK Plane Test Back Row

1/4/23

Cailin tested the robot with the new bracket and it worked fine.

She developed several new methods for autonomous.

She developed a method to convert inches to clicks to drive the robot forward. She made the conversion using data from two days ago taken from the distance sense in the back and the encoder telemetry data. The calculated ratio was 37 clicks per inch. Shen tested, this seemed to be just a little short so she changed the value to 39 clicks.

She created a second method to drive the robot using the conversion. This method takes a distance in inches, converts it to clicks and then drives the robot using a while loop until it has met the number of clicks.

When tested, the robot drove very nearly the exact distance with very little drift.

The next task will be to get the robot to turn and then to strafe.

1/5/24

Cailin developed a method to turn the robot using the imu. This was challenging for several reasons.

The IMU heading is 0 for straight ahead and negative for a right turn and positive for a left turn. This means that a single statement to turn won’t easily work because of the inflection at 0.

The telemetry methods, provided in the sample opMode, return a string object. This caused confusion because the string contains numeric digits, which make it appear to be a number. The error was detected when an error was produced that they values in the condition were not the right type. The first effort to correct the problem was to cast the string as an int. This did not work because the initial heading was “-0.0”. The default string cast method could not handle a negative 0 but the error message was not clear. The error message was pasted into Bard, which said to cast the string to a double instead of an int. When this was done, the robot could turn.

Another issue was that the heading data has to be continuously called to update the heading of the robot. This meant that the method for autonomous had to run a while loop. After a great deal of trouble shooting, the method worked well and produced only a small amount of error during initial testing.

The next step will be to build an autonomous program for straffing, which will need to make automatic adjustments, to correct the drift, while the robot strafes.

The current game plane:

negotiate with alliance team to start on side closest to parking area so that the robot does not have to drive under the barrier in order to park. The team should expect to yield to a team that can do everything in autonomous, including place the pixel. If the robot starts in the further position, the team should place the purple pixel and then stop. This will produce 20 pts. If the team is doing this, the expectation should be that the other team will score at least 5 points for parking if not 20 pts for the object detection. This will produce an alliance total ranging from 30 to 50 points.
If starting from the furthest position, the team will detect the team element, place the purple pixel, and then park. This will produce 25 points.
to navigate to place the pixel, the team will detect the object and then follow 1 of three paths: forward for 30”, 90 degree turn left, forward for 20 inches; forward 30”, -90 degree turn right, forward 20” or straight foward for 40”. Once that has been done, the robot will navigate to parking. This is dependent upon the pathway.
following autonomous, the team will collect and place 1-2 pixels that are on the close side of the truss. The team will avoid driving under the truss if at all possible, because of risk to the a place. If the team must drive under the truss, they can do the side step technique developed by Cailin.
At end game, the team will align and fire the plane and then raise the hook and lift.

public void imuTurn(double target) {

angles = imu.getAngularOrientation(AxesReference.INTRINSIC, AxesOrder.ZYX, AngleUnit.DEGREES);

String initialHeading = formatAngle(angles.angleUnit, angles.firstAngle);

double num = Double.parseDouble(initialHeading);

if (target > 0) {

while (num < target) {

angles = imu.getAngularOrientation(AxesReference.INTRINSIC, AxesOrder.ZYX, AngleUnit.DEGREES);

initialHeading = formatAngle(angles.angleUnit, angles.firstAngle);

num = Double.parseDouble(initialHeading);

telemetry.addData(“heading:”, initialHeading);

telemetry.update();

driveRotateLeft(.5);

}

driveAllStop();

}

else {

while (num > target) {

angles = imu.getAngularOrientation(AxesReference.INTRINSIC, AxesOrder.ZYX, AngleUnit.DEGREES);

initialHeading = formatAngle(angles.angleUnit, angles.firstAngle);

num = Double.parseDouble(initialHeading);

telemetry.addData(“heading:”, initialHeading);

telemetry.update();

driveRotateRight(.5);

}

driveAllStop();

}

1/6/24

The team needs to design the team element today.

The team does not need to design a strafe mode for autonomous yet. The turning and forward appears very accurate.

The team considered three different procedures for making decisions about the prop. They considered a competition where they each design a prop and then vote to determine the best design. This would be the best way to ensure that everyone got time working on CAD. They considered a model where the worked collaboratively to make the decisions, which would take the longest but probably be the best design but where they would each have the least CAD time relative. A hybrid approach would be to delegate the individual tasks, where each individual would make part of the design.

The team developed a team prop. The pro design has a vertical component of 98 mm, which allwos for seven 14 mm sections. Of those sections, four represent the team numbers, from top to bottom, 1,2,7 ans 9. The discs are 10 mm, 20 mm, 70mm and 90mm to represent the team numbers with sections that are 14mm tall.

Kayla and Yorda worked on the design in Fusion 360. They worked collaboratively.

The team developed a backward opmode.

The team drove the robot. Team mentor Luke Fitzgerald discovered that one of the wheels was not turning when the robot was strafing. This was not discovered when the robot was driving forward, backward or when turning.

Cailin printed the model developed by Kayla and Yorda. The design printed well but it was not possible to remove the supporting material from the design.

1/7/24

The design for the team prop was remade with some slight modifications to the design. First, the design would be printed in halves in order to eliminate the need for support materials. Second, the design would be made significantly taller, to make it easier to detect. The reprinted design would take 6 hours to print, which would be the longe

1/11/24

Cailin copied and pasted the strateLeftIMU code to make a strafeRightIMU. To accomplish this task, she placed the robot on a jack so that the wheels could freely turn. Then, she ran the turnLeftIMU program and recorded how all of the motors behaved when running the method. Then, she copied and pasted the text and renamed the method, strageRightIMU.

Within the code, she copied and pasted the motor values and then commented out the original motor values. Then, she determined how she wanted the motors to turn and make these values on a sheet of paper. The goal was to reverse the process of strafing left.

In her first effort, the switched the power adjustments and observed the motors operating. This did not give her the effect she wanted.

Her next effort was to switch the signs of the power for all of the motors. This did produce the desired effect. The robot was then removed from the jack and tested on the floor. The robot recovered from a disturbance in both directions.

Demo of corrections with wheels off ground

Demo of autonomous strafing with corrections

Strafe Test Right Test

01/13/24

Cailin, Yorda and Kayla met today (with Mentor Andrew Kim) and worked on the machine learning data collection. The initial plan was to take videos of the target from different positions. However, collecting the data was difficult because it was hard.

To make the model as accurate as possible, the team included a number of “null” frames that included the red tape and the other types of game objects.

The team tried to use facetime, then zoom and facebook live to get video from the robot using the camera. Eventually, the team decided to use ScreenCast-o-matic, which became ScreenPal. This was the software used to make the workshops for the girls teams a few years ago.

Once the stream was set-up, the team decided to drive the robot to collect video as the robot moved. The team thought this would more accurately represent the appearance of the target.

However, the robot had trouble staying on the back of the tile and not falling off the tiles. Eventually, the team reduced the power and finally ran the strafe on low power using an autonomous op. This worked fine.

Once the team collected a good sample, the team uploaded the video and placed the bounding boxes. This took a long time. The team made good use of the tracking option and revised the bounding boxes numerous times.

TeleOp Machine Learning Video Collection

01/14/24

Cailin and Sage met today to collect the data for the superior side of the field. They attempted to colect data in a new pattern, where they would strafe at the back, the advance and strage in the opposite direction and then advanced one more time. This produced a video that was too large so they had to repeat the process with a back and middle approach.

They also made some difficult choices about whether ot include a bounding box that resulted from the tracking. It was obvious that the tracked was correct, but there was so little of the target that the team didn’t want to keep it unless it was a good hit. This was because the team was afraid of false positives or multiple positives.

Then the team collected all of the data, they labeled it. A dataset was built that included all of the red images and then the model as built over-night.

01/15/24

The model was tested and it worked great. It did not detect the red lines and it did not detect some similar red objects that should not be detected. It worked well in the low light, so it should work better on competition day.

A preliminary op mode has been written to process the image data. The OpMode runs a loop based on detections and counts. The opMode stops looking after 500 attempts to find the object.

The opMode required the sample code to be tweaked in order to use the correct model, the correct labels than then a few lines had to be uncommented for the program to work correctly.

1/17/24

Cailin merged the methods from the TFOD opMode and the Strafe-Left op mode so that a single program would be able to do everything. This program was called the Red Alliance 2024 v1.

01/18/24

Cailin designed and printed a pusher for the pixel.This was needed to guide the pixel into position during autonomous. The mount can be

1/19/24

Cailin transformed the code for the object detection into a method. She did this by determining the x,y coordinates of the bounding box using the code from the demonstration opMode. She then moved the prop to different locations to determine the limits of the x coordinates to determine a range that would show the center and right positions. The left position was not in the frame of the camera. The model appears to correctly identify the object each time.

1/20/24

Kayla, Abby, Yorda and Cailin all met today. Cailin worked on the engineering notebook to make the highlights of the practice notes.

Kayla, Abby and Yorda worked on the red autonomous. They were able to get the inferior position working for the left and center positions. It was difficult to navigate the right position.

They got the center position to work for the superior position but the right position was not being correctly detected. They need to do some more work on this at the next practice.

Autonomous Red Center Park Side No Park

Autonomous Red Left No Park

Autonomous Red Center No Park

1/21/24

Abby, Sage and Calin met today. Sage and Abby collected the videos and uploaded them to the FIRST Machine Learning Tool Site. They also classified the object in the videos.

Later that day, Cailin created the data set and then trained the model.

1/22/24

A new pusher was created for the robot that was based on Cailin’s initial geometry. The pusher was created using a polygon that had sides of 1.8, which was slightly larger than the pixel. A center line was placed across the hexagon. A rectangle was added to the top of the hexagon. Another rectangle was added to the back. They were connected with lines that made a triangular brace. The rectables and lines were mirrored across the center line. The shape was extruded. to create the main body. The mount was created by extruding the back of the pusher. A single hole was added and then a rectangular pattern was used to place the rest of the holes. The hold size was .13” and the spacing was .56”. The object was sliced on prusa and then printed on a prusa printer.

1/23/24

The new pixel pusher was mounted.

Cailin downloaded the blue alliance machine learning model from the FIRST FTC ML Tool Chain website. She uploaded the model to the robot using the Manage feature of OnBot java. She copied and pasted the code from the Red Alliance 2020_V2 OpMode and pasted it into a new opMode, BlueAlliance2024_v1. She modified the code to use the new model. She tested the model and it worked. She had t modify the opMode for the placement of the new pusher. While she was modifying the code, she discovered that one of the wheels was not working correctly. She re-wrote the axialDriveEncoder() method to reset all of the motors and to use the absAverageChasissEncoder() method to determine how far the robot had driven. This got the motor to operate properly and ⅔ of the positions for autonomous work fine.

The team needs to make progress on the engineering notebook and on the final autonomous position.

1/24/24

The practice notes and robot programming code was printed by Cailin.

Sage had her Dean’s List interview.

1/25/24

Cailin 3 hole punched the practice notes and the programming code and placed the papers into the binder.

Cailin modified the autonomous to make the right side of autonomous work.

The next step will be for Cailin to get the autonomous to park in the superior positions for both red and blue. Then, there will be (4) op modes that need to be perfectly clear.

1/27/24

Cailin completed the autonomous for the parking for the blue alliance autonomous. The program works in time for all three positions.

Autonomous Blue Park Right

Autonomous Blue Park Center

Autonomous Blue Park Left

1/28/24

Cailin, Yorda, Kayla, Abby and Sage all met today. They worked on the engineering notebook and did a bunch of whole robot testing.

End Game Plane Test 10

When the team was testing the winch, the brake did not fire properly but it did fire and it lost a tooth. The brake was remounted and retested and it worked but the team wanted to make some changes because the robot needed to be 7 inches off the ground before the brake triggered. The trigger height was reduced but that led to another problem, which was that the winch operator wasn’t sure when to stop using the winch.

End Game Hang Test

This meant that the winch was being operated with the brake in place, which caused the brake to bend. The team decided to add some type of feedback so that when the brake is triggered, the winch can’t work. Alternatively, there might be a way to change the brake default behavior using a command like: motor.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.BRAKE);

The team also tested the teleOp using all of the systems. The robot did well with shooting the plane and driving with the plane. However, the team discovered that the power needs to be on to set the trigger. The team needs to modify the code to set the trigger during the initialize phase. This needs to be changed for every opMode that uses the airplane.

The team discovered that the pushed could rotate in position beause it slipped and broke. It was remounted in the center so there is less chance of slipping.

The team did a superb job using the arm to place pixels, which was a surprise. The team developed an algorithm which was:

drive to position
flip the wrist
grip the pixel
flip the wrist
drive to wall
lift arm
flip wrist
release pixle
flip wrist
repeat

This algorithm was used successfully by Cailin and Kayla on the arm and with both Yorda and Sage for driving. The team felt that Yorda’s time playing FIFA with her brother helped her drive the robot.

The team could place 3-6 pixels in the two minutes with relative ease and despite the plane appearing wobbly, it all seemed to work well. This was a surprise and showcased how well the team works together.

Pixel Plane Test 10

Pixel Plane Test 11

Autonomous Blue Left Park

1/29/24

Cailin worked on parking with the red autonomous. She updated the red autonomous with the changes to the blue park autonomous, which were as follows:

she added the zero brake behavior for the winch motor
she modified the driveEncoderBackwards method to use the absAverageChassisEncoder method.
She modified the init phase of the opMode to add the servo set for the drone trigger
She commented out the sleep statements that were included in the autonomous to have time to see the encoder values while the program was running.

Then, she used symmetry as a starting place to complete the red park autonomous. She also departed with the blue approach by adding a strafe and a forward instead of an imu turn. This was more accurate, took less time and avoiding hitting the team prop.

Red Autonomous Park Left

Red Autonomous Park Right

Red Autonomous Park Center

During test, however, it became clear that the winch is not working correctly. This needs to be addressed at the next practice.

1/30/24

The winch code was modified so that the winch would automatically stop when the robot is 5 inches above the ground. This was done by making an additional if statement within the bumper command. This made it so that when the robot was being lifted, the robot checked its height off of the ground. If the height was a above 5 inches, the brake was triggered and the winch was powered off. This worked well.

Cailin also noticed that the robot arm needed to be in the forward position or the center of balance for the robot would by way off.

When the arm was forward, she noticed that the center of weight was shifted to the left. She decided to move the battery to the right, as a counter balance. This worked better. When the robot is balanced, it can be at a lower height and still off of the ground.

1/31/24

Cailin added photos to the engineering notebook. She printed more back-ups on the 3D printer including the cog wheel. She also streamlined the code on the robot so that the only opModes that appear are the competition OpModes. She added the plane trigger to the other opModes. She planed the opModes into the autonomous section. She renamed the opModes to make the names clear and she corrected some confusion errors in the names of the opModes. For example, one opMode was named RedAlliance2020 but it should have been 2024. The winch program was corrected, tested and added to the opModes.

Winch Test