Taking inspiration from CoreXY printers, I present a concept for an FRC mechanism that can achieve up-down and in-out motion with two low-mounted powertrains. I call it the CoreXY Elevator (CoreXY for short).
Motor 1 can power the orange tube up and in, or down and out.
Motor 2 can power the orange tube down and in, or up and out.
Once you combine the forces of the motors, you can achieve any combination of linear motion in two axes. You can add stages to the telescope, so long as they’re passively driven off of the moving primary stage.
This image shows the routing of a timing belt for one side. The other side would be a mirror of this:
This example is built with the WCP Greyt Telescope, AndyMark Elevator Bearings, MAX Tube, and MAX Planetaries
I tried hard to make this mechanism / geometry viable for 2713 this season, but it’s turning out to be too complicated for our team. As such, I’m sharing it with the public. Note that this CAD is incomplete. It’s missing a way to attach the belts to the orange tube, and the interface between the telescope and elevator could be beefed up, for starters.
Here’s the public Onshape document: Onshape
And here are a few more pictures.
Hella sick, Ty! Thanks for sharing!
Who hurt you?
Which is a distinct question from “Who is going to hurt you?” to which I know the answer is “software people”
I’m hearing the controls would be pretty easy, but that’s coming from our mentor with a PhD in Robotic Controls.
I don’t think that this would be any harder to control in code than an arm, due to the way that its rigged, they should be far more afraid of the build people
This is pretty neat! I saw something similar in FTC last season of using a differential slide setup to extend diagonally and horizontally.
It’s really not that hard. It’s just a basic differential control, not unlike meccanum control.
Raise arm: Motor 1 forward, Motor 2 reverse
Lower arm: M1 rev, M2 fwd
Extend: M1 rev, M2 rev
Retract: M1 fwd, M2 fwd
And of course you can move both axes simultaneously by varying the ratio of motor speeds.
Personally, I’m offended that you are insinuating that any and all breakages is caused by software.
We don’t break the robot, we only show you what you didn’t make strong enough.
A similar thing was done in FTC by 9881 in Skystone, except with the differential powering a horizontal extension:
Video: https://drive.google.com/file/d/10XHgSW5cAjIfst8eJ9N4QvYeNbhROuz2/view, Golden Gears 9881 // Inter League Tournament - YouTube
And you, my friend, have just discovered the most dangerous phrase in all of software engineering.
I once said “oh yeah, should be easy” and then it took me 3 days of my life to fix a small bug :\ I don’t use that term any more.
More like: “we do these things, not because they’re easy, but because the hardware wasn’t ready on time.”
Keep telling yourself that
This is a really clean implementation of a potentially awful mechanism. So much so that would would consider it for use on a robot… in the offseason.
We do these things not because they are easy but because we thought they would be and we’re too hard headed to admit we were wrong because that would make the imposter syndrome too loud and I’d never make it through any more interviews and oh god I’ve forgotten how to sentence good and this is just one giant run on
Alas, being both a driver and software guy has it’s benefits! I make the controls exactly how I want and there is nothing anyone can ever do to stop me.
As far as actually controlling the mechanisms, that’s a whole other story cries in melted gearboxes
@Ty_Tremblay should be right, this will be easier to control for precise movements.
This is the theory (based on a graduate course in robotics I took). There is always guaranteed to be a small error in the position of a motor, due to a variety of factors. These include:
- Slop in gearboxes
- Encoder measurements being discrete and not continuous
- Other internals
Even if your software is perfect, the motor itself isn’t. Thus you can never be perfectly on.
Let’s call this error delta.
In the case of a linear system, your error will be delta times the radius of output shaft (such as a pulley with belt or rack and pinion). For a rotational arm, the error is delta time the length of the arm. (This is a “taste” of the math, it’s not perfect explanation)
Additional error means that software solutions for auto positioning become less reliable.
Will this matter? It all depends on your robot. People will make both work. I just wanted to shed some light on the subject.
Has anyone figured out how to connect the rope/belt to the actual tube?