paper: The Scoosh - a novel approach to linear motion

Thread created automatically to discuss a document in CD-Media.

The Scoosh - a novel approach to linear motion
by: GeeTwo

By utilizing a specially curved surface, we were able to convert rotational motion of a NeveRest60 motor into linear motion of the FRC 2017 gear onto the peg. This solution is lightweight, and has a “constant gear ratio” of gear translation to angle of rotation of the motor.

Presentation of a novel means of converting rotational motor motion into translational gear motion for the FRC 2017 game. Appropriately scaled, this mechanism would also have been useful for previous “peg” games, such as Rack ‘N’ Roll and LogoMotion.

scoosh-white-paper.docx (3.28 MB)
pushing-swoosh.xlsx (47.3 KB)

After linking to this in another thread, I re-read the white paper, and realized that an update was in order. At the end of the paper, I note that the scooch did not get a proper competition test because of software issues. During summer 2017, my son Gustave (aka Gixxy and G3) held a week-long camp for Command-Based Java programming with the practical task of rewriting code for this robot. Properly programmed, the scoosh performed well as a gear receiver, holder, and deliverer. Doing it again, I would have upsized to an Andymark PG motor, put a fourth spring on each door, and constructed a floor intake, even if it meant no overhead intake.

Glad to hear you got it working, and learned some lessons. We also learned the hard way how important an active gear release was in 2017. Even though your mechanism didn’t get much field time, the graphs in your paper are useful for other teams designing cams.

Ahhh, the lost art of cam and follower design.

I love watching the students discover the amazing motions that are possible from these old school technologies like cam and followers or un-even 4 bar linkages.

Back in the day, mechanical and hydromechanical control systems used cams to control complex systems. For example, for several decades, jet engines were controlled with such devices. There are some important lessons to learn from this that can be applied to current digital (software) control systems. For example, the cam designers would always add extra travel to the end of the cam profile. That way, if the control system moves a little bit outside of the original design space, the follower will not “fall off” the cam and cause the control system to shut down the device. For software, we need to make sure we accommodate for inputs that fall outside the originally conceived design space and tell the controller what to do in this situation. This is an important lesson for software design today, that is easy to “picture” when you consider a cam and follower control system.

Not super complex controls wise, but most IC engines are completely timed with CAMshafts. And for FRC, I especially love cams for catapults.

Well, doesn’t this sound familiar!

A student and I spent a few hours beating ourselves up trying to solve this problem properly (like you did) last year, before giving up and taking the easier (“good enough for government work”) solution. I ended up telling the student to design it so that it started in the right spot, ended in the right spot, and had a curvy bit in the middle. The point of contact on the gear wanders a bit.

Looking at the dates on our GrabCAD, we were apparently solving this 6 days after you posted the solution here. Really wish I’d checked CD!

Edit: Video

An FTC team I was mentoring used cams on their bot for Res-Q a few years ago. They had a collection tray that was mounted on a hinge and would ride very close to the floor when intaking the cubes. When they wanted to climb the mountain, they needed to raise the tray up to get the additional ground clearance to get over the rungs. They mounted two servos with cams that would push the tray up when they wanted to raise it. Using cams mounted to a servo was nice because the servo would rotate 90 degrees and you could easily design a cam to do a decent amount of lifting in that 90 degree profile.

I have not seen a lot of opportunities to use cams on FRC bots. But I keep looking.

Thanks for all the feedback and insights! I didn’t realize at the time that I was making a cam; I’ve always thought of them as solid and going in one direction only, though I realize that isn’t necessarily the case. I just ran with one of the student’s ideas and found an analytic solution in a CRC Handbook’s integral tables.

In particular for Matt: If I had not found an analytic solution, we’d have likely taken some solid core wire, a wooden plank, and a small square, drilled a hole the desired distance from one edge of the plank, and free-handed the thing along that edge about a quarter inch at a time to come up with the shape. That’s pretty much just refining what I did with the twist tie.