Out of curiosity why do you prefer the straps over rope? Also, are the blocks that it’s on 3d printed?
1 Like
#silversonly
Some of our mentors have had previous experience with strap-based elevators and found they pretty much never needed to be re-tensioned, as opposed to the dyneema rope, which does need to be tensioned sometimes as the rope stretches.
Ultimately it’s a preference item, as the ThriftyBot elevator has a very nice system to tension the rope, but we feel we can make as-good of a system without the dyneema pulley kit.
And yes, the strap blocks at the top are designed to be printed out of Onyx, ideally.
4 Likes
Kickoff!
Prototyping!
We did a little bit of prototyping at the end of Sunday and found our roller claw prototype the most promising.
The biggest takeaway from it was that it’s possible to score sideways cones if you pick them up with a roller claw, and perhaps uprighting cones isn’t necessary!
Some resources we’ve been looking at this weekend:
- Good robots from 2022 FTC game:
- Inspiration from old games:
Priority List
As we said in our last update, the plan for kickoff was to ask:
What Will Windham Windup Wield to Win Week Won
Priorities marked as “W8” are intended to be completed for Week 1. We expect to complete some items marked TBD as well, but which ones, we’re not sure - it depends how difficult they actually are.
Robot Concepts
- Double Joint Arm
- Tilted Elevator with Arm
- “Walmart” Pink Arm (pnuematic extension, not pictured)
Robot Size
Heated debate on whether it’s more important to have the extra space to package more simple mechanisms to reach L3 Cones or whether it’s better to be smaller for bridge balancing but have a more complex mechanism as a result.
It’s going to be tight on the bridge with three “standard” width robots.
Sigh
30 Likes
Double Jointed Arm
- Very good at loading game pieces from Double Substation
- Scores effectively at all levels
- Very small, so probably good for balancing partners
- Is it W-8 simple enough to have working for Week 1?
- Floor intake is terrible, but it’s low priority
Walmart Pink Arm (WmPA, the “Gold Arm”)
- Okay at loading game pieces from double substations
- Scores effectively at all levels
- Very small, so probably good for balancing with partners
- Simpler than DJ
- Floor intake is still terrible
Tilted Single Stage Elevator with Virtual 4-Bar
- Decent at Double Substation and floor loading
- More complex than Purple or Gold, likely difficult to get working for Week 1
- Large by necessary, so poor at balancing
27 Likes
Software Update 1: Reaching Into the Cookie Jar
shoutout @jonahb55 for title/format inspiration
One of the primary strengths of the Double Jointed arm is its ability to quickly pick up from the Double Substation - which we’ve affectionately been calling the “Cookie Jar”. Since the arm can sit back into the frame for Cookie Jar intaking, we can slam the bumpers up against the wall for super-quick cycles without worrying that our claw would bottom out against the plexiglass behind. This seems to be a promising strategy.
While we have yet to commit to a robot archetype, one of the main concerns around the Double Jointed Arm shown above is the amount of software effort required to maximize its potential. To reduce some of the risk of building one, over the past 24 hours we’ve developed a simulator and basic controller for the DJ arm using the WPILib ArmSimulation example as a base. This simulation models gravity, inertia, current draw, and other useful metrics, includes a simple 2D visualization, and allows us to experiment with different control schemes for the arm.
GitHub: GitHub - WHS-FRC-3467/DoubleJointedArmSim: Double Jointed Arm Simulator
Some highlights:
-
Pertinent field components are modeled: double substation, mid and high rungs, grid aluminum tubing
-
Trapezoidal motion control is implemented through WPI
ProfiledPIDControllerclass -
Multiple control modes:
- Presets (Setpoint) Control (default): Move both joints simultaneously to the desired position. There are 6 positions, all shown in the video based on real field element dimensions and the real dimensions of the Double Jointed concept
- Zero-Latency Software Four Bar: keeps the top arm at the same angle regardless of the bottom arm’s position. This is accomplished by setting the upper arm’s setpoint to negate the setpoint of the lower arm
- Manual angle control (not shown): manually set each arm’s setpoint independently of one another
-
Gearbox, inertia simulation for both arms, weight simulation for lower arm
Caveats of note:
- Gravity is not simulated for the upper arm since the WPILib
SingleJointedArmSimdoes not inherently support a moving arm joint, but its inertia is simulated. In the grand scheme of control, this isn’t super critical, it just will affect some of our tuning. - The current motions for going from the floor to the node scoring positions pass through the grid elements - a simple but suboptimal workaround to this would be to program in an intermediate position that tucks the arm in before moving to those mid/high scoring positions. Watch for this in a future update.
This simulation seems to be promising in that the control for the arm is fairly simple - just two independent ProfiledPIDControllers running each of the joints. This simplicity is afforded by the assumption that we are only picking up and scoring on one side, and we’d just spin around 180 degrees in transit between the Cookie Jar / Loading Zone side of the field and the Grid / Community.
We hope the wider FRC community finds this type of research useful, especially if your team is considering building a double jointed arm or similar mechanism. If you have questions, or want to experiment with this tool, feel free to reach out!
34 Likes
12 Likes
Hi! I’m the lead programmer from FRC 997 in the PNW district, and we’re also exploring a revolute-revolute arm for our cone/cube placement.
Just out of sheer luck, I was challenged by our main programming mentor just before winter break to develop a control system for a 2-dof arm. And now we get to do 2-dof arms.
Our system isn’t quite finished, and is in fact lingering in a development branch of our library, but it contains one big feature I think could be of great use to most teams who want to maximize the time efficiency of their multi-dof mechanisms: configuration-space planning (configuration space is a space defined by the angles of the joints, not the end effector position).
Configuration space navigation could be a general solution to the problem you have with the mid pole blocking your farthest extension.
At this time, for us, it’s more-or-less just an optimized version of Dijkstra’s graph traversal algorithm through a set of predefined nodes which we place inside a valid (collision-free) space, although we briefly explored (pun intended) RRT or RRT*. There’s also talk about doing some small changes to paths to keep the center of mass centered (which I’m pretty sure 971 2018 did).
Pretty much the worst graph you’ll ever see, representing a very simple configuration space and nodes-- this would be considerably higher-resolution for anything we’d actually use.
Anyway, we’re more than happy to share our open source code (GitHub - Team997Coders/spartanLib2 at multiDOFMech), which we will be finishing and merging soon-ish. If you have any questions about the whole thing, you know where to find me (and our design team might be wanting to ask some questions the other way!)
6 Likes
This is super cool stuff! I’d never considered using something like Djikstra to traverse a graph of valid states for the arm. Thanks so much for sharing. Down the road I could definitely see us port the visualizer/simulation stuff to work with 997’s control scheme & kinematics.
3 Likes
Design Challenges
We’ve been heavily considering the Tinybot “DJ” Double Jointed arm design, and we’re trying to find design challenges we may not have considered yet.
Absolute Encoder Mounting
The current double jointed arm model has no good place to mount an absolute encoder. We can’t easily put them on driving shafts because they’re geared 2:1 from the relevant joint, so one absolute encoder position could mean two possible states. Ideally absolute encoders can tell us where the arm joints are to start the match with a high degree of precision, and they’d be 1:1 with these two joints:
However, those are going to be either dead-axle or MAXSpline shafts to transfer the torque better than, for example, a hex shaft can.
Our ideas are currently:
- Add a set of 3D printed gears off the lower shaft with a ratio of 1:2 and put the absolute encoder on that shaft.
- Use an absolute encoder on the lower shaft and use software to know which of the two possible absolute encoder positions is more reasonable
- Find a good way to attach an encoder to the MAXSpline shafts
- Use a potentiometer of some sort?
Any ideas here would be helpful
How Low Can You Go?
We’re a bit worried about our ability to maintain our heading and odometry going over the charging station during autonomous for various autonomous modes with a minimum height Mk4i swerve drive.
Current ideas:
- Put the 2x1 atop the modules for more ground clearance (also raises CG and makes it easier for cones to end up stuck under the robot)
- Use 1.5x1 instead of 2x1 for drive rails
- Use a rolly bar!
The Struggle
14 Likes
For cases like this in the past we’ve used 10-turn pots with great success
2 Likes
Potentiometers are generally better for this application in many regards. 3 wires instead of 4+, cheap to buy and replace, easily accessible, and a wide variety of mounting and sizing options. I’d stick to Pots if you are able to.
2 Likes
Weird concepts we’re probably NOT going with:
Single Joint arm on a Diagonal
Double Joint Arm on a Diagonal
12 Likes
You have to be careful here with the special extension rules this year. You’re only allowed to extend over one side of your robot, defined by the sides of the frame perimeter. If you extend exactly over a corner, you’ll be hitting two sides, which is illegal.
10 Likes
This is a primary factor in why we aren’t doing this. Could be easily solved with a small flat section of the frame.
4 Likes
Now if you cut a flat on your bumper like 1787, but the width of your arm then you’d be good!
5 Likes
It looks like they are only extending over the corner of their frame in their LOADING ZONE and COMMUNITY. This would still be legal due to G109b:
5 Likes
2023 CAD Working document here: Onshape
Bit of a mess, and nothing is set in stone, but figured I should share it early.
4 Likes
Midnight CAD Update
Encoder Mounting
Since we can’t directly mount to the joint’s directly because they’re a dead axle tube we decided to mount it to the lower near the gearbox shaft and have a separate axle geared to the same ratio as the rotating joint. This is geared from a 16t to 32t gear so they are small enough to run inside of the 2x1 and package well.
Gearing
This year we want to put an emphasis on the center of gravity improvement, But for the weight that can not be mounted as low, we want to keep it as light as possible. So this year we also decided to use 3D Printed Onyx herringbone gears because they have significantly reduced backlash and are much lighter than standard COTS gears.
Half A-Frame Support
Obviously, support is almost necessary for an arm of this size. This is a piece of max tube supported at a 55 degree angle (relative to frame). Custom gussets for improved attachment rigidity. Keeping a row of rivets parallel to the 1x1 is more efficient than making them all vertical though it may look pretty weird.
Pros
- Allows for chain to be tensioned better
- Decreased sway for more accurate stacking
Cons
- Consumes valuable space
Ground Intake = Bad 
We have decided to postpone the addition of a ground intake for several reasons.
- Most useful for 2+ game piece auto, not a week 1 situation
- Inconsistent cycle times due to orientation time
- Potential solutions are complex
- Most ground intakes would have the same acquisition zone as the arm claw intake
- Handoff will be messy
- Not enough tipped cones to be a huge priority
Drivebase Updates
30 Likes
Baller
15 Likes