need to have a Walpole & Westwood team night, order some pizza’s and watch Robots (hope we both make many trips to each others shop’s) hopefully not for missing parts though
1 Like
That sounds like a perfect competition week 0 or week 1 event
Kickoff Season Update!
As the season officially begins, we have started brainstorming our initial ideas and strategies. We analyzed the scoring and rules (especially regarding how much time it takes to do each type of scoring) to figure out what robot skills we should focus on. We have based our game breakdown around team 125’s talk, and our analysis is documented in this spreadsheet, which will be updated during the next couple of days.
Here are a few key takeaways that we immediately identified:
- Because there is no restriction to prevent the viability of a swerve drive, we will be using swerve due to success and experience. To combat sliding on the charging station, we will likely lock the wheels into an “X” formation once balanced.
- Floor intake will likely be more manageable than taking from the loading station for scoring points, due to the additional time required to reach the piece.
- There are a variety of autonomous routines that would all be applicable, such as a 1 game piece, 2 game piece, and 3 game piece routine.
- Based on our initial time based estimates, placing game pieces on the top row first may yield the most points. However, this analysis was taken without factoring in the complexity of designing or building a subsystem to accomplish this.
- Endgame does not require a different subsystem entirely but instead can simply be an extension of the drive subsystem
- We will likely need two vision subsystems working simultaneously: one for robot localization via apriltags and one for system alignment for placing game pieces
- We can likely use a gyro to automatically stabilize on the charging station, in combination with locking our swerve drive
- We need to build a grasper to reliably handle both objects – something to keep in mind is that you can only extend over your frame perimeter in one direction at any given time
We will be meeting again today and working on predicting alliances and deciding what we want to work on moving forward for our robot. We will also be sorting out how to make a minimal setup to practice with.
We will continue to update you all on our progress in this thread, and as always, if you have any questions please feel free to reach out!
Best wishes,
Team 1757
Written by Claire, Luke, Landon, and Sean
4 Likes
If that’s how the cone looks, I wonder if the cube will survive.
in my defense…
I have none
Kickoff Day 2 and First Week Update
On Sunday (1/8) we began defining our robot’s feature set and scope on this spreadsheet. Afterward, we analyzed several possible alliances. For our feature set and alliance data, a few things stood out as noteworthy:
- An above average bot scoring in the top row slightly faster significantly outperforms an average bot that scores in the mid and hybrid rows. Therefore, we should aim to build a robot that can at least score in the middle row to maximize points.
- The largest factor of cycle time is the amount of time to get from one end of the field to another.
- The endgame should be highly prioritized as it’s a simple source of points
- An arm of some kind will be most effective (see 971’s 2018 bot for inspiration)
Based on this, we have considered the following systems below.
Chassis and Swerve
Game Piece Testing
For the general chassis of our robot, we are looking to create a small swerve robot, with a low center of gravity.
We tested the bumper height’s effect on certain game pieces, specifically the potential for cones to get stuck underneath the robot. We found that in normal driving conditions, game pieces are unlikely to get stuck underneath the robot. However, when pieces are jammed between robots (which we simulated using feet) it is possible for cones to become fairly stuck under and somewhat damaged by the swerve modules. On a different note, we found the cubes to be relatively robust, compression forces did not pop it.
See the media below for images and videos of our testing.
Getting cone stuck under
Getting cone stuck under pt 2
Pushing cone under other robots (tip first)
Pushing cone under (flat edge first)
Pushing around cubes
Charging Station
We are also looking into bumper height’s effect on the ease at which the charging station can be climbed onto. We are beginning to think about the viability of using another mechanism dedicated to “pushing” the ramp down and making movement easier.
(at 11 degrees the wheel intersects to make the bumper tangent)
We think there may also be some issues involving swerve in getting on top of the charging station.The first bot that attempts to climb the station will likely be fine (Ri3D redux did enough testing to verify this), but the second bot may need help in tipping the ramp up so that they can get on. We will likely have to design for the worst case, which is that we have a combination of ground clearance and downforce to drive onto the ramp with at least 1 robot already on the scale.
We learned in 2012 that getting the ramp to tip down with no robots on top of it and getting the ramp to come down with 1 or two robots already on it was difficult. However, that year, we built a small pneumatic arm that forced the ramp to tip towards us before we drove on. We could possibly replicate this mechanism which also could be dual purpose with the same arm joints pushing down the ramp being used to deploy a pick up mechanism that corrects or upright traffic cones.
We have already committed to the Mk4i swerve modules that we have assembled so no matter what we will be working around those modules. We’ve also tuned swerve drive on falcons to be pretty finely controlled to deal with it being the way we place ourselves inline to drop off the game pieces (so we don’t need to rotate the arm relative to the robot).
Arm
Arm Concept
We are thinking about using an arm as a manipulation mechanism. We potentially envision a 2DOF arm + 1 DOF wrist that can pick up both cubes and cones, with a high range of motion on the wrist joint. As we can utilize the movement of the bot, we do not need the arm to be able to move side to side. An important note is that with an arm the starting configuration poses a good challenge, as it will need to fit inside of the frame of the robot before activation. We have found that the shoulder joint only needs to move 90 degrees max, the elbow joint 210 degrees, and the wrist joint somewhere like 270 (at least in the configuration, lots to play with) in order to achieve all necessary motion.
Trying out different geometric configurations in CAD
One potential default state is when the robot holds the cone into itself (as pictured above). The only thing we have to be mindful of is the arm (elbow) sticking out and being vulnerable to being hit as we speed across the field. We would want the arm to be behind the robot while moving, not in front.
Additionally, we’ve been utilizing inverse kinematics to calculate the joint angles needed to reach a specific position.
(Geometric IK for 2DOF arm)
From this, we are beginning to create our own simulation. GitHub - 1757WestwoodRobotics/2023-ChargedUp at arm-control
Intake
Intake Concept
We haven’t set on anything yet for the intake system and have been just experimenting with different ideas. So far we’ve only explored the dual game piece centering mechanism; this was based off of WSRP 2023 - Passive Cone Re-Orientation Prototype - YouTube for indexing and Compliant Intake Testing | Ri3D Redux 2023 - YouTube for initial intake. This system would orient both gamepieces on acquisition into a known configuration. We eventually scrapped this idea because the indexer is 18 inches long by itself and requires a variety of compliance that was not reasonably within the scope of the team and would require more space for minimal strategic benefit. It is overly complex for what could be replaced with a different strategy: cones received from human stations in a known position.
Conclusion
Moving forward, we seek to further develop and finalize our design. We will continue to update you all on our progress in this thread, and as always, if you have any questions please feel free to contact us!
-Team 1757
Written by Claire, Luke, and Sean
3 Likes
Second Week + Outreach Updates
During the past weekend, we worked on an arm prototype to manipulate game pieces, brainstormed robot mechanisms, and discussed a new belly pan design. We’ve also worked on extending our outreach to our community through school and library events.
Arm and Joints
During the course of the week, we began finalizing our arm design. We will be using a 3DOF arm, with flexible shoulder, elbow and wrist joints. In between the joints, we will be using 3” carbon fiber tubing, as it is light and durable. We will also be using a MAXSpline Shaft in order to safely route cables in place of a hex shaft. Instead of belts, we will be using a #35 chain and a corresponding gearbox to control elbow joint movement. Our goal is to keep weight at the shoulder joint in order to ensure maximum stability. We plan on using WCP Rotation SS Gearboxes to step the ratios down, and going into those with a 20:1 VersaPlanetary gearbox to further our ratios.
One important note about our arm design is that we will not be using pneumatics. The rationale behind this was that our robot only needed pneumatics for arm brakes and potentially a grabber. Based on our math, we predict that our gear ratios on the motor will prevent the need for dedicated brakes (~360 to 1 motor to arm, uses roughly 13 amps at the worst position of all three linkages horizontal).
Arm Prototype
In order to make progress on programming, we have built a prototype arm. The arm prototype uses two 2x1 bars and one as the moving arm, as well as a Falcon with a 14:70 gearbox. We changed a few minor elements of this while building, including replacing the belt with a #35 chain and sprocket (closer to what we are doing on the robot) and adding an absolute encoder on the upper hex shaft for programming usage. Stay tuned for an update from Luke regarding arm control later this week!
End Effector
Our initial end effector will be modeled after the Everybot design with some key modifications. Our goal is for it to be swappable, in case we wish to change it or pursue a different design later in the season. Like the Everybot, we will be using 3 rollers, with dedicated cone and cube areas. However, we will not be using wheels and reducing the number of belts. Last year, we had difficulty with the robustness of our intake as the belts often slipped, leading to a total disintegration of our intake. This year, we will be ensuring that our belts will be protected from two sides, which will mean replacing the inside belt with gears (given that the distance is small enough). We will also be using foam rollers attached to polycarbonate tubes instead of wheels. It will be necessary to soak the rollers in alcohol in order to ensure that they fit snugly onto the polycarbonate tubes.
Potential Issues:
Below we’ve put together a list of concerns that we have with our current design. We will be trying to design around these over the next few weeks:
- Side load on these arms could really shred into pieces (faster than humans can react)
- Because of how we’re gluing the arms of the carbon fiber breaks we have to replace the entire tube and joints attached to it
- Holonomically doing a spin in between the charging station is nearly impossible at >26in bot width, so being smaller as always will be better, however the complexity tradeoff should not be understated
- Gear ratios will need to be decently beefy: torque load in worst case scenario is rather high
- Tuning the arms will be a nightmare, for low loads (like for the demo arm) the arm is really able to wiggle when told to go to a setpoint, compounded with shifting torque requirements caused from further links changing
- Chain tensioning between links will mean we need to be mindful where to put the turnbuckle and how much length we actually have for it
Outreach Events
Aside from building our bot, we’ve worked on promoting STEAM to younger children and minorities. Here are some courses we’ve organized:
Library Minicourses
Our library minicourses have been held at our local library with the goal of introducing STEAM to 3rd to 6th graders, in which our attendance peaked at 12 kids. Our first session focused on introducing STEM, what it means to them, and how it impacts our lives. We also introduced the EV3 Mindstorm robots; we showed them the parts of the robot (the input/output ports and motors) and how to use MakeCode to make the robots move and do what we want them to. In the next session, we focused on elementary physics: forces, why things move, gravity, and the differences between mass and weight. We performed experiments with dropping 2 different objects at the same time and predicting which will hit the ground first; the first time we showed mass does not matter and the second time we showed impact of air resistance. We plan on having one final session on the 27th, which we are looking forward to.
[1] Luke introducing what is STEAM [2] art activity with crayons
She Can STEM
On Monday 1/9 we had our first meeting for our She Can STEM minicourse. We began with introducing STEAM and seeing where they see it in their everyday lives. Afterward, we gave them a hands-on challenge: with 4 sheets of paper and a limited amount of tape, they were tasked with making the tallest tower they could. We will be continuing these classes with new lessons over the next couple of weeks.
Conclusion
Moving forward, we seek to further develop and finalize our designs as well as continue our endeavors in outreach. We will continue to update you all on our progress in this thread, and if you have any questions feel free to contact us!
-Team 1757
Written by Sean, Claire, Landon, Luke, Baili, Nina, Rachel, Adrian, and Andrew
4 Likes
Programming? Programming.
Abstract
Since we’re going with a 3 linkage arm, a lot will go into the control of the arm to make it smooth and behave responsibly. Furthermore, autonomous is always a very important aspect of the game, and path planning will be crucial to achieve a reliable autonomous. As a python team, we have ease of writing code yet lower general support in the larger FIRST community, so skilled programmers who can translate between java examples and interpret them into python are in high need. As always our entire source code is available at 2023 Charged Up Github Repo
Falcon metaclass wrapper
Controlling motors is hard and repetitive.
In preparation for very large files that don’t contribute to the overall purpose of the code, a Falcon500 powered by TalonFX wrapper class was established at the beginning of the season to make interfacing simplistic. We plan on expanding to NEOs and NEO 550s as we plan on using a NEO 550 in the final grabber mechanism and perhaps in future mechanisms years ahead. This is the start of somewhat of a unified “1757lib” which lives in the “util” folder on our repository.
Arm control
Oh boy! Three whole linkages! Control wise, each serial joint will be controlled with a Falcon500 through some constant gear ratio and have a CANCoder attached directly to the end shaft to get absolute positioning.
Inverse Kinematics
As stated in a previous post, we geometrically derived the inverse kinematics for 3 links with a fixed Pose endjoint. Internally, end effector poses will be represented as Pose2d with some known position and rotation. Numerically these positions are placed into CAD. They are the following: Top scoring position, mid scoring position, storing/protected position, double substation intake position, single substation intake position, and floor intake position. Each of these poses actually allows for two configurations of the proximal 2 arm joints (they can simply be mirrored over the line created from the wrist joint to the shoulder joint, however by forcing the sign on the elbow joint they can all be consistent.
Derivation of inverse kinematics for three joints:
Let Pose (xf,yf,thetaf) be the final pose. Let r1 r2 and r3 be the lengths of the shoulder, elbow, and wrist joints respectively. Since the length of the wrist is known, the position of the wrist joint is known, let this be (x,y). X = xf - r3 cos(thetaf) and y=yf - r3 sin(thetaf). The rest of the derivation is geometrically trivial with the law of cosines and inverse tangent properties. (see math for 2 joint in first week post)
To Feed Forward
To maintain position, the motors will need to supply a constant torque onto the arm to counteract the torque caused by gravity. ArmFeedforward works best for a single arm. This is because the radius in relation to the pivot does not change. With higher order arms a simple constant multiplied by the cosine of the angle will not be enough. Higher order systems will require more complex feedforward mechanisms.
Simulate, simulate, simulate
Since we do not expect the arm to be operational for programming until it is too late to start programming, the value of simulation is important. SimFalcon allows for per-motor simulation, but a combination of three SingleJointedArmSim allows for basic inertia simulation. This gives values back to the simulated relative onboard with absolute encoders giving knowledge of positioning as the real robot would. The absolute encoders are used on initialization to set the positioning of the motors properly, allowing their onboard relative encoders used in PIDF loops to have absolute data. Using Mechanism2d, the entire simulated arm can be viewed.
(video demonstrating arm interpolation through end effector states).
The currently there is no mechanism to prevent the end effector from interacting in a damaging way with the grid.
Cartesian control and damping
As inverse kinematics allows for full cartesian coordinate control over the motors, we can interpolate how fast we want the end effector to move and have complete path control. The following video shows both 3d simulation with advantagescope as well as Trapezoidal profiling in cartesian space and the rotation of the wrist joint. Currently this takes a linear path from the start to finish but further improvements can optimize potential collisions of the arm with the environment and other robots.
Pathplanning
In 2022 we used Pathplanner’s export to Pathweaver wpilib trajectories. Experimented with in the 2022 offseason and implemented in 2023, we will be using pathplannerlib directly. Using python has meant that there isn’t first class support, but the 2023 updates are here to have event markers and end stops. There were some initial issues (thanks Luke for putting in a pull request to robotpy! We technically have a 1757 contributor to robotpy now!) But given that we had pathplanning from the previous year, it was mostly a conversion. We custom wrote the movement action commands instead of using pathplanner’s base command set. The reasoning is simply that it’s not in robotpy-pathplanner lib so custom implementation was required.
One hurdle that is encountered is that the built-in translation function for converting from red alliance to blue alliance actually has a blue-side forward result, simply acting as if the red side was from the blue side. The vision system does not account for this, so a rewrite of this translation function was needed to convert it into actual world positions
This also converts driving after teleop is enabled to be driver forward at all times (therefore not needing to reset). Last year we encountered issues with coming directly out of a pathplanner auto and having to reset to have proper odometry (see any match video from last year robot after WPI and you’ll see the first action be a rotation and gyro reset), so figuring this out is a big leap for the team.
Absolute drive (an important swerve drive mechanic)
Last year our lead programmer had a new idea for drive control, an absolute relative drive. The common swerve drive control method was to have a field relative translation for the bot, and a robot relative rotation. What this meant is a left input on the rotation axis would result in the robot rotating to the left at a constant speed. A translation action was not affected by rotation but instead was in “field relative” space. The difference of absolute drive is that the rotation is also field relative. A left input on the rotation stick will yield the robot turning to face left. This year we expect this type of robot control to be very important for drivers when they have to be able to turn to specific positions for collection and scoring on swerve drives. You can see this in action in any one of our videos from last year. Having fixed controlled rotation will allow for precise driver input and less fiddling with controls when cycle time is very important.
Sidenote: the drivers have also experimented with alternate driving methods on swerve to get used to interesting control schemes such as a curvature drive, standard tank drive, standard field relative drive, and full robot relative drive.
Vision with apriltags and photonlib
Originally a self-induced challenge by myself to finish apriltags before winter break, we have a complete vision system complete with sensor fusion for complete robot localization. Last year,we worked with our first complete vision system as a team that resulted in significantly enhanced system performance, and using apriltags will be very important to account for combined sensor error as well as for being able to reliably use sensor data for automated alignment to various points on the field such as the double substation and the grid.
The How
Photonvision generates camera-relative 3d transforms of each apriltag. Since the position of the camera is known and the position of the apriltag is known, the position of the robot can be determined from a single apriltag datapoint. These transforms are fed into a RobotPoseEstimator in order to create a sense of where the robot could be at a given time, this is combined with the gyro and wheel encoder information to get an accurate sense of where the robot is on the field at any given time. This is used in other subsystems when needed, as well as results being logged to AdavantageScope through the usage of each known pose and ghost poses
Going further
We plan on using this odometry data to have automated alignment in complete robot space for important precision actions such as placement of gamepieces on the grid and collection of those gamepieces. Autonomous will also use this data. Perhaps an automatic engagement on the charge station by using the rotation gained from the apriltags will be possible. Overall having a sense of where the robot is on the field is beneficial to aid in other systems.
We’re a python team!
Since we made the decision in 2020 to begin using python, we haven’t looked back. The ease at which our programmers can keep pushing out code is unparalleled due to its beginner-friendly nature and ability to keep going further and do more complex actions. However, when it comes to the greater FIRST community, python does have its drawbacks which I plan on listing here.
- Examples
This should go without saying, but being in the minority will inherently mean that finding other code that can just be taken is very difficult if not impossible. The added benefit is that the programmer has to properly understand the code in order for it to be implemented.
- Libraries
At least for the 2023 season, there is no first class support on libraries, although the robotpy team is working hard to keep consistent, there is inherent latency and bugs are prone to arise (see pathplanning for one such instance which team intervention was needed)
- Help
The average FRC programmer Joe has more experience in java for FRC than python for FRC, so when it comes to support with the larger community, it becomes more difficult and daunting to ask for help instead of just pushing through and trying to find solutions
Hopefully with 2024 bringing first class python support, each of these issues will be addressed as more and more teams adopt the simplicity and rapid testing that a python system provides.
-Team 1757 Wolverines
Post written by Luke
11 Likes
1757 Wolverines Testing Sims, Intake, and Arm Demos | The Open Alliance Show | 2023 Charged Up - YouTube Check out the testing simulations and demonstrations provided by 1757 Wolverines as they showcase what went into their alpha intake, arm joints, control and test bench and programming work on The Open Alliance Show.
6 Likes
Here is the slideshow we used yesterday
Micro code update:
Waypoints!
From a driver perspective, alignment is very crucial to be fast and accurate this year. Since we are already planning on having global positioning, we are going to use this with dedicated waypoints.
The result is that the driver presses a single button, finds the nearest waypoint, and then automatically moves into place.
4 Likes
Hey all!
We apologize for the long hiatus in OA posts but we are back with some 1757 updates. In the past few weeks, we tested our everybot-inspired intake from various angles and really focused on tough decisions in CAD. Here are some of the major updates we made over the past couple of weeks:
Drive train
We originally planned for our frame dimensions to be 24x24 in order to have a minimal robot footprint. However, in order to fit the battery (in a way that it could be easily accessed), we widened our base to 24x26.
Intake
We are currently fabricating our intake, which is based on Team 118’s Everybot design, but with the individual wheels replaced with longer rollers surrounded by neoprene. Since our arm is unfinished, we tested our intake with the arm of an industrial collaborative robot (big shoutout to our mentor Chris for bringing it in!). See media below for our testing of multiple intake angles!
With that being said, the intake is now in version 2 since we added bearing retention plates to reinforce the stress points. After experimenting with the intake and the industrial robot arm, we concluded that the relative top roller for the cone intake needs to touch the game piece in order to own it. Once it does, it will have full control over it. When we finally mount the arm and intake onto the drive train, we will experiment with different ways of driving into the games to intake them. Additionally, having more velocity may help with picking up the cone.
The cube has a separate section in the intake, but due to its simpler geometry, it is easier to take control of it.
[1] building the intake [2] testing with the industrial arm
here are some videos:
- intake testing for cone (skip to 0:30 for the actual picking up)
- intake testing for cube
Arm
(math to ensure chain tensioner does not get eaten up by sprocket)
Our arm rotation will be controlled by sprockets and a 35 chain tensioned by the spartan tensioner in order to ensure that we are as rigid as possible. We looked at what the tolerance of the tensioners is per link, and learned that we may have to modify the sketches to account for travel distances. The inline tensioner must be able to travel through all of our expected range of motion without touching each sprocket.
We are working hard to ensure that our joints will not be the arm’s failure point. We lightened the elbow joints in the arm by about 5 pounds, which will lower the chances of our bot tipping if we overextend the arm as well as reducing the amount of torque required on the motor, allowing for potentially faster gearing ratios. Furthermore, in considering how our robot could be made inoperable, we settled on a stack of roller and thrust bearings within the joint to ensure maximum rigidity.
We also have a dead 1.5in aluminum or steel tube in the center of the elbow joint instead of MaxSpline because we determined that using MaxSpline in it would be more difficult with the need to manufacture spacers up to 1.5in OD on the shaft. Since the tube that runs inside the elbow joint can be made to not transmit load, we instead opt for a simple tube. We are still going to use MAXSpline for the wrist joint since the joint itself transmits load.
One important element of our arm design is the use of endstops (also called hard stops), as they allow our initial end effector position to be contained without active motion. We will not be using pneumatics (for any breaking system), so having end stops will be important to hold it in place. With this in mind, the wrist joint is designed so that the end effector is resting on its endstop at both its starting and floor intake configurations.
For fabrication ease, we want the end block pieces (converter sections that take the 3 inch tube and transfer into the square base shape which interface with each joint part) to be repeated to avoid confusion over slightly different pieces.
Learning from last year, we found that it is necessary to prevent backlash in the gears, so we are gluing the gears to the shafts to prevent tampering with the end positions. With regards to the entire arm subsystem, the design unfortunately does not reserve any space for absolute encoders, so relying on the integrated relative encoders in the motors will be crucial to ensure stability, and we need to be mindful about the stiffness when driving the arm.
Other Technical Stuff
Learning from our bumpers struggles last year, we are opting for a two piece bumper to allow for better access. Taking inspiration from 971 in recent years, we are using their bracket mounting system with threaded posts attaching to nuts.
We have begun working on the code for the autonomous phase of the game, but we have also started work on how to balance on the charging station. We have yet to test either of the autos out on the field, but let us hope we can do that soon. We are using pathplanner’s new waypoint feature to maximize the reusability of code with changing paths. Last year we had a significant struggle with autonomous pathing and having events happen between actions and this year we are excited for the new features in pathplanner.
The scouting database that we have started building since last summer is being modified for this season, but it should be ready to use for our first competition. We are looking into using android tablets for scouts instead of their phones, but going back and forth onto the compromises that would have to be made for such a local system.
Conclusion
We continue to refine our CAD and have begun some manufacturing. The arm code is almost complete as well. As always, we will continue to update you all on our progress in this thread, and if you have any questions feel free to contact us!
Best wishes,
Team 1757
Written by Nina, Baili, Luke, Claire, Sean
5 Likes
1757 Wolverines | Mechanism Overview | The Open Alliance Show - YouTube Luke from 1757 Wolverines provides an update on their current robot progress and provides an overview of the mechanisms that will be on their robot on the Open Alliance Show
4 Likes
Beyond excited to see this at Greater Boston.
2 Likes
its alive!
the 3dp tube converter joints prompty broke after some movement
4 Likes
Robot Updates
In the past few weeks, we have made significant progress on our drivetrain, arm, intake, and end effector. We have fully assembled the plastic version of the bot (hooray!), and we are in the process of final fabrication and assembly, in anticipation of our first competition during week 4.
Drive Train
Our drivetrain is essentially complete at this point. For the electronics pan, we cut holes in desired locations to save total robot weight for other purposes. We are using a dual-sided, 0.125” thick aluminum electronics board (inspired by Team 125’s dual layer design) to ensure easy access to electronics, which we struggled with last year. Furthermore, on the robots side, we have a side panel mount board dedicated for providing easy access to USB and ethernet, An anticipated side effect is that ground debris may be able to enter the robot through its underside, so we added a 1/4in polycarbonate sheet to prevent this from happening. We also cut out and constructed the 2x1 rails that support the arm, and installed them on thunderhex shaft spacers.
Additional media for drive train
Arm
We have a functioning arm! Due to the high lead times from outside sources on parts and in order to give programming a head start, we have 3D printed substitute parts made from an FDM printer. For the final bot, all the sprockets remain the same and therefore have been cut. (Oh yes, we cut our own sprockets!) On our Omio CNC router, we cut out clearance holes for the bearings on our shafts. We manufactured a 3D printed design that slots into the versakeys located on our sprockets and allows tighter tolerances than otherwise able.
But who would’ve thought that 3D printed parts could have broken so easily. Due to how our tube-to-square converters were printed, we began to see layer adhesion issues right down the conversion line without even placing the intake on. Understanding this, we tested code without the load from the intake to get a general sense of issues, but then during assembly the inevitable occurred. We had enough time to take a few glamorous photos before the cracks sparked a big rush to replace. This was a result of just manually jogging the arm through some positions and trying to go back to a starting position.
Below are videos of programming’s initial testing. Simulation allowed the team to work out some issues, and it was more a matter of tuning the motor-specific controls.
After replacing the FDM converter parts with SLA homogeneous ones, the robot was able to hold itself together. As a result, we were able to test our first couple of position cycles. Due to the lack of absolute encoders on our arm, and the use of a chain resting endstop for our shoulder, we are not very confident about the cascading effects of the shoulder’s rotation on the position of the end effector. Therefore we are planning on mounting an absolute encoder to the steel shaft that carries the 12t pinion onto the shoulder to have a better initial startup condition.
We anticipated and then found through testing of our plastic arm that the robot is tippy, so we’re adding steel weights near the battery in order to prevent tipping by rocking back and forth.
Robot metal parts (which we have yet to assemble)
End Effector
We made more parts! The revised end effector was cut and constructed together. We opted to redo the shafts and rollers on the intake as we made a cutting jig for flatter edges and cut the shafts to the new size from our previous design. We also cut the neoprene for the rollers flatter to create a better looking intake.
(Sidenote about tolerances: MaxSpline is a PAIN to put into flat parts cut near-exact, so add some tolerances to your cutting to save time! We had to file down both our aluminum and polycarb a bit to make the intake fit better.)
Other Technical Updates
In our last OA post, we discussed how we are opting to use a two-piece bumper rather than just one to allow for better access. This week, we finished fabrication of the bumpers, which are ready for installation.
Programming also began to refine the vision subsystem. In code, the position of our camera can be easily changed to match what’s designed, but in order to figure out what to design we made a pan-tilt mount for our limelight with 6 degree detent rings which grants fine control over the position. Upon experimentation we determined that having a front facing camera, even if to the side, would be fine for our use case of re-affirming positions through the use of apriltags.
Speaking of cameras, we have a Insta360 X3 camera, which we plan on mounting somewhere on the bot to get full 360 playback video automatically stabilized. The intention is to use it in combination with our logging system and match filming from the stand in order to better review any given match for potential issues and general optimizations we can quickly make.
Robot Media and Parting Notes
We finally have a functioning robot! We unanimously agreed that our bot’s name should be Luxo, named due to its canny resemblance to the PIXAR lamp.
We also began testing, which will be our focus over the next couple of weeks.
Here’s a preview on some test driving we did over the weekend:
We will continue to update you on our progress, and if you have any questions do not hesitate to reach out to us!
Best wishes,
Team 1757
Written by Luke, Baili, Rachel, Claire, and Sean
5 Likes
Intro
As our first competition draws closer, we are making the most of all time remaining. Our team has been preparing for the robot’s final assembly, and we anticipate completing it soon.
Electronics and Drive Train:
Because of our expected tippiness, we have added steel plates to the underside of our bot just under the battery.
In our testing, this has reduced our ability to tip, but it is still not zero. We will need to be careful in our fully extended state, and our upcoming driver practice at WPI should shed light on any remaining issues.
We also have CADed up a single piece protective cover instead of the current two piece design, but we have yet to cut it. Currently, we have two sheets but nothing protecting the battery from above. This improvement will make it near impossible to unintentional gamepieces stuck in our bot
Arm:
3D printed parts have been replaced with wood and aluminum parts, and the polycarb tube with carbon fiber. Overall, this gives the arm more rigidity, and we were able to tension the robot’s chains more securely. We expect these parts to hold up better than the 3D-printed ones.
However, we did not replace the wrist joint with an aluminum part. While testing the code, we discovered a silly optimization error, and the bot proved that it could supply a lot of force. We had a plethora of angle optimization functions between both joint-relative space and total motor-relative space. The virtual 4 bars created by the chain and sprockets means that they are different. Part of this optimization was done in the virtual 4 bar-version optimized for a shortest distance. The shortest distance so happened to go straight through the robot. The simulation indicated that this could’ve happened with the arm during practice. Fortunately, using logfiles, we saw exactly what it was trying to do in code and resolved it in under an hour. That joint has been replaced with an FDM printed + polycarb enforced joint which still works wonderfully.
Arm Media:
For those who are interested in looking at the logfile for the failure, here it is: https://cdn.discordapp.com/attachments/706232593313431584/1084608954421743646/FRC_20230312_211612.wpilog (open it in AdvantageScope)
Intake:
Learning from the hand-drilled holes we needed to add after the machining of the original intake plates, new intake plates have been cut for replacement in the event that the polycarb shatters.
For our break beam sensors, we are experiencing some electrical difficulties with the SparkMAX power and wiring of the sensors. For the time being, we are opting to unplug them to prevent SparkMAX from using them incorrectly.
Other:
Batteries! We got our 4 new batteries fully set up and charging, and this year we plan to label them to have equal charge distribution across them all. We cut vinyl labels and took the battery from last year with the most charge and labeled it as our extra one, just in case.
Speaking of vinyl stickers, we also cut out our sponsor logos using a Cricut Maker. These will be put on the polycarbonate protective panels on the outside of our bot.
Here are a few sticker cutting tips we learned while using the machine: (Resource: cricut help)
- Make sure to use vector images for the stickers, as much as possible. This results in the cleanest stickers.
- Peel the vinyl stock from the cutting mat slowly, in order to ensure that you do not introduce large air bubbles into your stickers (make use of the spatula)
- Make sure to “combine” multi component parts in the canvas, or they may be cut separately.
- Exercise additional care when cutting small letters with inside negative space (ex. A, O, B, P). The inside portions tend to come off easily.
- When doing complex shapes or individual letters, be sure to use transfer tape. Last year, we struggled with complex stickers because we did not realize that this was a thing.
Taking team 3467’s advice, we also changed the intermediate shaft bolts with 12-24s. The original bolts were unfortunately very loose with a standard threadlocker, so they were swapped and given the “I mean it” Loctite 609.
Conclusion:
It has been a busy weekend, and we will test our work at the WPI practice field this weekend. As usual, we will continue to update you on our progress, and if you have any questions do not hesitate to reach out to us!
Best wishes,
Team 1757
Written by Luke, Baili, Divya, and Sean.
5 Likes