The Example C in the blue box under G109 is pretty clear about curved frame perimeters. A curve is a polygon with infinitely many sides, and therefor extension over a non-infinitesimal length of the frame perimeter extends over multiple sides and is illegal.
Your point about adding a diagonal side under the arm extension is true, which is why the idea isn’t necessarily illegal but it’s something they would need to pay attention to.
Thanks. I misread example C. My bad.
Has any thought been given with this control choice (location of the abs encoder) towards where backlash will be? How will you manage the backlash from the arm, considering this is on the wrong side of it? Or is there simply not enough backlash here to matter from a controls perspective?
Edit: I somehow both replied to the wrong person (sorry @aaryanv !) and also missed a significant part of the post! The backlash consideration here is the herringbone gears - is that enough considering the chain backlash that may be present?
I’m only replying because of chief Delphi wont let me post embeds as a new user.
We are starting assembly of a mock-up of our arm with older VEX parts we had on hand. This prototype will be highly advantageous to give our programming team 1-1.5 extra weeks of coding ahead of manufacturing our cnc’d arm. This arm has the same effective specifications as our REV ION arm. With this arm, we hope to gain a significant advantage in cycle time with a lot of driver practice and extra time for code optimization. after the CNC’d robot is operational; the other will be used for drive team practice allowing for our coding team to work on optimizing the motion simultaneously.
(herringbone gears as talked about in previous posts printed on our markforged onyx one)
This arm was assembled by our new students with the supervision of experienced members. Assembling this arm allowed our new students to explore different areas of mechanical assembly. We had students assembling versaplanetary, students learned how to work with pre-drilled box tubing using a custom 3d printed jig (pictured), and students measured, marked, punched, and drilled holes by hand. Our students learned how to work with gussets as well along with using new tools like saws, drill presses, and mills.
We have weighted the arm in the last tubing as the same weight as our end effector (weight calculated from onshape). The slight reduction in weight is on account of the MAXtube (will be used for the cnc’d arm) being significantly lighter than Versatube (had on hand and was used for the mock arm) while still maintaining a improved structural rigidity.
While the design team was working on CAD for the prototype arm and mechanical was assembling it, we had a group working on compression testing for the cube and cone (on a related note we have popped our cube).
Skip-5.13 GitHub: GitHub - WHS-FRC-3467/Skip-5.13
As of now, we have some tested drive code and the subsystem framework for the double jointed arm and Limelight.
Some issues we ran into early on were needing to make the switch from SDS swerve code to the 364 BaseFalconSwerve library. We had some initial difficulties when trying to test the MK4i code which is still an open issue in the repo. We instead moved to MK4 code and will continue testing on our currently assembled 2022 robot.
364BaseFalconSwerve GitHub: GitHub - Team364/BaseFalconSwerve
Another issue we had was reading the Absolute Value from the REV Through Bore Encoder due to a documentation difference between Rev and WPILib. What we learned we needed to use was the DutyCycleEncoder class with the DIO port of encoder. We also have the Encoder class used and set up in case we need to use it later.
In the constructor:
private DutyCycleEncoder m_upperEncoderAbs = new DutyCycleEncoder(3);
In the initialization function:
m_upperEncoderAbs.setConnectedFrequencyThreshold(976);
m_upperEncoderAbs.setDutyCycleRange(1.0/1025.0, 1.0/1025.0);
Another was adding the proper feedback sensor for the Talon FX. There is no documentation for using a non-CTRE duty cycle encoder with a Talon FX. The documentation for configSelectedFeedbackSensor(FeedbackDevice feedbackDevice) and the FeedbackDevice class are contradictory and the Phoenix docs do not have information about how to setup a sensor that is not connected to the talon or on the CAN bus. The FeedbackDevice class says
//Quadrature encoder
QuadEncoder(0),
//CTRE Mag Encoder in Relative mode or any other device that uses PWM to encode its output
PulseWidthEncodedPosition(8),
//CTR mag encoder configured in absolute, is the same as a PWM sensor.
CTRE_MagEncoder_Absolute(8),
//CTR mag encoder configured in relative, is the same as an quadrature encoder sensor.
CTRE_MagEncoder_Relative(0);
Link to full class: FeedbackDevice (CTRE Phoenix Java 5.30.3)
We will run initial testing with FeedbackDevice.PulseWidthEncodedPosition as that is what makes sense and make changes from there.
The important functions are
In the ArmSubsystem constructor
private TalonFX m_upperJoint = new TalonFX(CanConstants.UPPER_JOINT_MOTOR);
private DutyCycleEncoder m_upperEncoderAbs = new DutyCycleEncoder(DIOConstants.UPPER_ENCODER_ABS);
In the initialization function
m_upperJoint.configSelectedFeedbackSensor(FeedbackDevice.PulseWidthEncodedPosition);
m_upperEncoderAbs.setConnectedFrequencyThreshold(976);
m_upperEncoderAbs.setDutyCycleRange(1.0/1025.0, 1.0/1025.0);In the periodic function
m_upperJoint.setSelectedSensorPosition(getUpperJointPositionAbs(), 0, 10);Methods
public double getUpperJointPositionAbs(){
return m_upperEncoderAbs.getAbsolutePosition();
}
public void setSimplePIDUpper(double position){
m_upperJoint.set(ControlMode.Position, position);
}
public void setMotionMagicUpper(double position){
m_upperJoint.set(ControlMode.MotionMagic, position, DemandType.ArbitraryFeedForward, ArmConstants.kGainsUpperJoint.kF);
}
We have also done some initial testing with the new 2023.0.1 Limelight 2+ firmware and using the vision client found the following results:
I worked on a very similar thing yesterday. Another caveat to note is that the angle of the upper arm greatly affects the behavior of the lower arm. The MoI for moving the lower arm will be vastly different in say the upper arm being vertical vs. horizontal. A simple ArmFeedforward won’t take that into account.
EDIT: A more concrete example
The lower arm dynamics are vastly different in the two following scenarios as the center of mass of the upper arm changes distance from the lower arm’s pivot.
We decided to use to the REV ION hardware this year because we saw the benefit of using the MAXSpline shaft over a normal piece of hex at the rotation points. A 100: 1 or 125:1, still have to decide, MAXPlanetary drives a 24t sprocket on hex which drives a 48t MAXSpline sprocket fixed to each joint. We repeat this step for the upper joint making it use the same exact hardware. One of the main reasons we decided to use MAXSpline is because of how easily their system was able to be mounted on a ¾” deadaxle tube with a tube nut on each end and be able to easily come on and off the robot as shown here.
Also, when drilling a 1.375” hole into the box tube, the MAXSpline sprocket, plate, and shaft collar can all be clamped together using 6 bolts on the top and bottom section of the pattern when correctly lined up.
As mentioned before We decided to make a prototype of this arm with materials we have in our shop, which were mostly composed of VEX parts. In order to convert this from REV to VEX, we changed the MAXTube to just standard VersaTube. This will incorporate a VersaPlanetary with a similar 100:1 gear reduction. We continued to use a 48t sprocket but unfortunately, we had to a 22t sprocket instead a 24t so our ratio won’t be 100% symmetrical, but to attach them onto the tubing we used VersaBlocks because of the convenient hole patterns they had.
Earlier this week we started manufacturing parts for this proto arm and just today we concluded our assembly of it. In the next coming meetings, we plan to assemble a drivebase along with a prototype claw and make it into our practice robot for programming to use or drive practice for later on when programming has the actual robot.
Fully Assembled Arm Video
We also assembled all our swerve modules we will be using this season
Not a full post, but thought I’d share that DoubleJointedArmSim now supports a motorized wrist, with prototype code for all 6 setpoints we plan to use on the arm initially.
This is available on GitHub on the double-with-wrist branch.
Wonderful work Windham Windup!
Thanks James! 95’s thread has been quoted many times as inspiration in our slack. We’re super excited to see your machine at Granite State.
I worked a bit more on my simulation yesterday. I decided to extend the SingleJointedArmSim to slightly modify it to work better with the wrist.
This of course still doesn’t simulate the effects of the wrist position on the forces acting on the arm, but it aligns better with the real world.
This week we have almost finished the design of the entire robot excluding some small tweaks and optional modifications. We spent a lot of time over the past week prototyping and Saturday we completed the prototype arm.
For our claw, we have 2 sets of 4in 30A durometer rollers spaced for optimal compression of the cube and the cone. We are running it using a bag motor going into an UltraPlanetary Gearbox. We will be 3D printing some herringbone gears made of PLA to reverse the direction for the opposite side of the claw. The exact gearing of the UltraPlanetary is TBD.
We’ve decided to incorporate a wrist to the claw to enable primitive ground pickup and extra maneuverability while scoring game elements. We had 2 general designs for a wrist, one using pneumatics and the other using gearing inspired by 7407’s wrist design found in their Open Alliance CAD.
We’ve decided to prioritize building the pneumatic wrist due to its simplicity in the programming. After Week 1, depending on how beneficial we see it to be, we may switch out for a geared wrist to enable some more freedom for the angle of the claw.
The ground pickup functionality from the arm is not ideal but we are hoping to be able to use it in Auto or scoring in the Low Row for week 1.
The belly pan this year is your typical belly pan. We considered making a brain pan like last year, but with worries of falling off the charging station, and thus touching the underside of our robot, we didn’t want to damage any electronics. The PDH is centered in the robot (of course) and with the Pigeon and Carnivore right above it. The Carnivore makes CAN much easier considering we would need a lot of CAN wire otherwise. The right side of our robot features the compressor, Talons, and PH, while the left features the RIO and Mini Power Module. We also decided on a horizontal battery as it would make the wiring to the breaker a lot easier. Some electronics not seen are our radio, radio power module and solenoids would all be on the arm and arm mount. A solenoid would be on the arm because it reduces the amount of tubing needed from a normal manifold-solenoid assembly on the belly pan.
do you have any videos of the intake in use?
Just wanted to give a quick update-- 997 has aligned (probably) on a double-jointed arm as well. To be honest, I haven’t done as much work on the software side of things as I would have liked to. However, 3467’s sim, and 449’s feedforward dynamics model, will both be very useful to us.
However, I have had the time to work on one of the pieces needed for our configuration space navigation-- the generation of configuration space plots so we know where we can put Dijkstra nodes.
A figure generated with MatPlotLib and a point-cloud method. Areas we want to avoid are defined and split up into hundreds of points. They are then translated into sets of joint angles with inverse kinematics and plotted here on a graph from -pi to pi. The white areas are valid states for the arm to occupy.
There’s still a flaw where an arm segment can occupy an invalid space if the end effector is okay, but that’ll be fixed soon.
You can find the source here:
I’ve intentionally made the restrictions/even the inverse kinematics very configurable, so this probably is easily adaptable to other 2-dof arm layouts.
We’ve done some small tests, but admittedly didn’t document them as well as we’d like. Today we will grab some photos, videos and share some key dimensions that we find are working.
We are not the strongest team for prototyping and have been learning a lot from other teams on here. 
This week is midterms for the team. We met this afternoon for one last “big” push before taking tonight off and entering a stretch of lighter meetings so students can focus on those. I’m putting up a placeholder and our students will follow up with more detailed responses when their schedules allow.
No GIF tonight - this more accurately describes how the team is feeling with getting so much accomplished this week!
EDIT: Forgot to credit 7407, whom our student took heavy inspiration from!
One of our students slapped this bad boy in the design:
The basic concept is simple - stick these forks under a partner who is already on the Charging Station, then use their mass to lift ourselves up. We are planning to be light, so if we have a max weight partner with enough clearance we can get our forks in there, we should be able to lift ourselves up. If we don’t have a max weight partner - well we did build 24”x24”, so hopefully we can all fit on the station together.
This made me nervous, so I tried to do a little bit of math from my Strength of Materials classes. There’s a decent chance I messed something up, so if my math is wrong or I’m using the wrong equation, please let me know!
The sum of the moments about the pivot point should be the maximum moment we’d see, and I estimated 16” away from the pivot being where our partner’s center of mass is located.
The maximum normal stress through the tube is the Maximum Moment*the diameter of the tube divided by the Moment of Inertia of the tube.
I then compared this to the Flexural Strength of a piece of 0.875” OD CF tube from McMaster and then let out a sigh of relief:
Does this mean the design will work? Absolutely not. But the CF tube shouldn’t fail via normal stress given the assumptions made, and we should have plenty of safety factor in case the assumptions are wrong. It may fail in 15 other places due to stress concentrators or poor mounting or bending causing us to touch the ground or us pushing our partner off the station with the forks or…
