What’s your opinion on Angle-adjusting flyhweel? Feel free to discuss below!
1 Like
Flywheel rpm is a much better way to vary the disk’s height imo. No added moving parts, simplicity to code.
8 Likes
Yeah, @7686B_Ian’s idea is pretty good. I use that in my auton. I am not sure if changing the speed would be effective in driver control, but you could always try. If you wanted, however, you could use pneumatics to have a two-height angle adjuster.
1 Like
Personally, I think an angle adjustor is more work than it’s worth. The only real benefit to a steeper angle is being able to more gently score discs once the high goal is full, and a catapult is generally better for that. (And, as previously mentioned, changing the speed of your flywheel is a much easier, simpler way to control the height of a disc’s arc.)
4 Likes
If it works in auton, why wouldn’t it work in driver control? Is there something inherently different between the 2 that prevents the use of sensor fusion to change your flywheel’s rpm based on distance from the high goal?
3 Likes
OK yeah that does sound like a good idea. I am just a bit averse to using a lot of sensors in driver control because I think that the driver should be able to have complete control of the robot. If you were using sensor fusion, however, what sensor would you be using?
This is an interesting philosophical moment. We want robots to eliminate drudgery and give us longer weekends. If you enjoy selecting and executing cunning flight paths that the robot wouldn’t be able to identify without changes to programming, manual control of aiming might have value. If you’re just picking where to shoot from and there is precisely one target that doesn’t sequence, then establishing permission with timing description (once, or empty the clip till I let go) and directing your attention back to the ongoing situation is what you’d be looking for?
Flywheel speed would be computed on your vector and derivatives to target. If firing were always from stationary, you could have a precomputed mapping from range to flywheel speed. You’ll get away with error bars because the goal is high and wide, and your vehicle speed might (or could be chosen to) be too low to be relevant as long as you don’t set off or halt hard enough to bounce during the firing process.
2 Likes
I’ve seen one team use a vision sensor to aim and also determine flywheel speed.
If I were to do it, I would use 2 ultrasonic and put them at 45 degree angles. If the value of the sum of those ultrasonic sensors was above a certain point, it would increase the speed, and so on.
Another option is odometry, but tracking wheels would have to be implemented.
You could also use the distance sensors but I don’t know how accurate they are at range and I’ve never used them.
3 Likes
Flywheels, by their very nature, are resistant to RPM changes, especially quickly. Your motor(s) are going to expend considerable energy (heat) slowing down the flywheel. This mentions nothing of the time involved to change/regain velocity.
4 Likes
Ultrasonic needs a good flat surface to bounce back from so you can’t aim at the goal itself.
You could aim and the walls using 2 sensors and use math to compute distances. However, every time a bot passes between you and the wall… there goes your reading(s).
I’d look at optimizing for the resource most limiting: time.
3 Likes
the angle adjustment is hard to accomplish it easier to do it through rpm adjustment. We went the angle adjustment route and it never fully worked so we changed to a fixed flywheel