My team is building a 2020 robot as a off-season challenge.
And we are going to have a shooter with an adjustable hood on a turret.
As part of the robot design, we will have a conveyor mechanism to get the balls from the intake to below the shooter, and a separate conveyor mechanism to take the balls vertical into the turret (shooter).
And now we have a dilemma about rather we will make both conveyor mechanism’s on the same motor or not.
if we will, it would make a consistent path for the balls straight from the intake to the shooter.
I am worried that by doing that two things might happen.
Either the balls would not be equally spaced in the conveyor, and that would make sometimes a situation that in order to get balls from the intake you would have to push balls in to the shooter, which can cause problems if the shooter isn’t in the right speed or if the turret isn’t in the correct angle.
And the other thing is that I’m afraid that by doing one straight path from the start to the end (intake to shooter), you wont be able to control your shooter feedrate, and it would be dependent on the rate that the intake picks up the balls.
My simple solution is to make the two conveyor’s with a different motor for each one, so that one would serve as a magazine, and the other would determine the shooter feed.
But my teammates think that Adding a motor for that is useless and unnecessary (even though it’s just a cim motor).
It really depends on whether you need to hold the Cargo before releasing or not. If you need to hold (say, to get into range), then a second motor is essential. If you can just let fly from wherever, it isn’t necessary.
One other benefit of separating the two (in terms of consistency), having a motor that rotates with the turret feeds and feeds the ball to the flywheel is important. This ensures when the main flywheel engages the ball it is not pulling it free in different orientations from the conveyor geometry below when the turret is at different angles. That handoff is a violent event, how the ball is presented to the flywheel does impact consistency.
There is a thought to add a beam break sensor in the start of the conveyor so that we will “pull” balls in pulse’s only when we need. So that way you can arguably say that the magazine will stay tight.
In that situation you can technically say that most time both conveyor’s will run at the same time, and theoretically there aren’t supposed to have any problems.
But i still think that even if you add a beam break there are a bunch of advantages to separate the conveyor’s, and I also think that my worries are still walid.
Could you potentially use something other than another full conveyor set like a pair of wheels? That could be less to drive and potentially let you use a smaller motor. You may also even be able to use a smaller motor to drive that top conveyor in the current set up although I’m unsure of how to do the math for proper gearing.
For our Infinite Recharge robot we had a single conveyor motor, but the top of the conveyer used a larger size polycord pulley. This meant that when the balls reached the half way point of the convayor they sped up, which in turn spaced them out a bit.
But for feeding the balls into the shooter we did also have a pneumatic ‘kicker’ which perform the final push of the ball from the conveyor into the shooter. We reasoned that consistently feeding the ball into the shooter would give us more consistent aiming and we did average a high percentage of inner target shots in that game. However, it is hard to say exactly how much difference this system made as we did not prototype a kicker-less system for comparison.
So correct me if i didn’t understand, but you were able to achieve high accuracy percentage to the inner goal because you had a system other then the main conveyor to control the shooter feedrare?
Yes that was our theory. The idea was that consistently feeding the ball into the shooter would give more accuract aiming and a separate mechanism that did just that with a single ball would be best. But as I said we really didn’t do anything to test whether our more elaborate system was making a difference. I suspect it may have been over-engineered.
As a point of comparison in the following year for Rapid React, we just had the conveyor to push the balls into the shooter, but we did have a separate motor for the top and bottom of the conveyor (as you suggested). This was done for pretty much the reasons you outlined in your original question - concern about jamming and wanting to decouple intaking and shooting. Note that robot performed very badly, but that was because the camera failed not due to a poor shooter. You can see the full CAD here (#6996 2022 CAD) if you are interested (no CAD for our Infinite Recharge robot unfortunately).
It would be interesting to hear what others think about this. My guess is that it depends on the game. From one of our mentors with more experience that me, I know that shooting accurately in Steamworks, which involved a large number of small hard balls, was terribly difficult. I seem to recall that to do well some robots used a mechanism similar to what a paint ball gun uses to prevent jamming.
Try looking for the CAD of top teams to see what they did in shooting games. That is usually a great way to get some idea of what works.
If you are using NEO you can set the motors to follow each other. This will make it run consistently (if you want it to run at exactly the same speed) I think it would be much better to use 2 motors. I recommend you to watch 148’s 2022 robot reveal video. They had a nice system for the conveyor system.
We used a gravity hopper and a single roller to stage a ball at the bottom of our vertical elevator. We used beam breaks such that if a ball was at the bottom of the elevator but none was above it, the elevator advanced that ball one spot and if another ball was in the hopper it would be advanced to the bottom elevator spot. the top ball was stopped about 1/3 of the way into the turret just at the feed roller of the shooter. We kept the main wheel of the shooter “idling” at our minimum shoot rpms<1>, when the shoot button was pressed the shooter rpms were set to the correct value for our distance (from limelight) and when it hit that speed (±fudge) the shooter feed roller and elevator advanced everything forward until a ball was shot If the shoot button was still pressed, and there was another ball in the elevator, it waited for the rpms to recover from the previous shot and advanced again, repeat until no balls or button unpressed.
this approach won a week one regional in 2020 and our skills challenge group in 2021. Here’s some video from the regional (we start as the center red robot)
<1> for quicker spin up, but it also turned out to be more battery friendly.
Our weak spot was probably getting the turret rotated onto target as quickly as we would have liked (which conveniently we got to work on in 2022 because it was a similar game )
The best way to control this is by using sensors to selectively turn the conveyor off and on. In 2020 my team used beam breakers at the top and bottom of our conveyor path. The logic was any time the bottom sensor saw a ball we’d run the conveyor until it didn’t, but at any time we’d stop running the conveyor if the top sensor saw a ball. We did have a separate hopper that was controlled with the intake to hold 2 balls when the conveyor filled up since our conveyor couldn’t handle 5 balls.
Btw IR balls are large and you can hold 5 of them which is tricky to package in one straight conveyor, I’d heavily recommend you start making some layout sketches ASAP because you may quickly find your current conveyor packaging idea won’t work.
In the past teams have included the extra feeder wheel(s) you are discussing as part of the shooter itself geared directly off the main shooter wheel. This may be an option here as this prevents the need for an extra motor.
Lastly here’s some general advice for IR specifically:
The goal is kinda massive and there’s a protected zone right in front of it, your design criteria of an adjustable hood isn’t as important as you might think.
IR balls are sticky and squishy and like to jam if you give them the chance. You need to eliminate gaps along your shooter path where they could get stuck.
IR balls benefit from having active conveyance on both sides of the ball if you are moving even slightly vertically. This is particularly important when transitioning from horizontal to vertical.
Check out 973’s behind the bumper video, it’s got great info and it really shows their ball path. Also they didn’t run an adjustable hood or a turret, just saying.
That’s what we did originally, but it didn’t have the right behavior. The actual conveyor logic was so complex we used a discrete logic table to synthesize code with the correct behavior. Before we did that, we kept getting it wrong on accident.
)