After seeing many teams’ wonderful performance in this season, l am curious about how does your team control your feeder to make it shoot smoothly (l mean when the shooter is ready to shoot ,the feeder will pass the ball immediately). Since when l intake balls , l can’t make sure that the two balls are contiguous. l guess that many teams have a blocker under their shooter to block the balls provisionally and when the shooter is ready to shoot, the blocker will open and pass the balls to the shooter.Besides, l guess that many teams may divide their ball path in two parts and control them seperately. That’s smart. However, if the robot only has a feeder with one motor to control it and the path of the ball is long, it seems that friction can’t be avoided if l want to make the two balls intaked contiguous. So, under this circumstance , is there any good method to control the feeder?
At least this season, balls index very easily and there is no need to overcomplicate indexing. Our feeder is just a belt system driven off a single motor. When the beam break at the front is tripped, the conveyor will move until the beam break is no longer tripped. This will hold two balls and the spacing between them is consistent but also irrelevant.
When we want to shoot, the conveyor will reverse a tiny bit to make sure balls don’t touch the shooter wheel early, and then the conveyor will feed once the hood is at its position.
It doesn’t matter if the balls are touching. The cargo in 2022 aren’t power cells and nothing happens when the balls touch. The shooter will yoink the first ball out before the second ball gets anywhere close to the shooter wheel and just setting the conveyor to the correct speed will shoot out both balls with a consistent and reasonable amount of time between shots.
Do you only use a conveyor to control your ball path? Do you have another wheel below your shooter?
It seems that this method only suits the team with a short ball path.
If you use a motor to control the ball path. When the first ball is at the right place and l want to get the second ball in the right place, l will rotate the belt but at the meantime , if l don’t have a mechanism to block the first ball , it may run away. How do you solve it?
Nope. Only a single motor driving the conveyor including the wheels that feed the shooter.
Why would it not work with a long ball path? The beam break at the front just advances the balls whenever one is added. It worked in 2020 with 5 powercells and there’s no reason it couldn’t scale as long as the indexer is big enough.
Why would it run away? When the first ball is indexed, it ends up right behind the beam break. When a second ball is indexed, It will be on the beam break and both balls will move to their desired position with the first ball in front but not touching the shooter and the second ball touching the beam break.
Does beam break means an IR sensor? l think l have got it but how can l switch between shooting one ball a time or shooting two balls a time? Does it depend on the operator?
The beambreak isn’t used to shoot, just to load the conveyor. To shoot, you just move the conveyor a specified distance.
So when the shooter is ready , l will move the conveyor and no matter how many balls it has now.
Yes. That will guarantee the conveyor will shoot all the balls present.
But ,if l am shooting while intaking, it seems that there is a conflict between them.
There is no reason to be shooting while intaking. If for some reason that is the case, the shooter takes priority.
But l think 1690 is shooting while intaking.
Most teams are not able to do what 1690 does. Shooting while moving is one of the hardest things possible in this game and is not worth considering for a vast majority of the teams. Their conveyor is also segmented to allow them to even do that in the first place.
Generally you follow controls logic which is run the feeder when you dont have a ball, keep running the feeder till the ball has reach the first loading position, then stop the feeder once the trip wire detects the second ball run the feeder till the ball has caped the top trip wire and then stop till shooting, shoot till no more balls in the system
I’m going to explain how my team does it. By no means do we do it the best but it’s what I can explain the best.
Our team calls the mechanism that picks balls up from the ground the intake, and the internal mechanism that moves the balls from the intake to the shooter the transfer. Here is a picture of the transfer.
Lines are belts, arrows are limit switches, boxes are motors. Orange motor drives orange belt, pink motor drives pink belt. Pink is upper transfer, orange is lower transfer. Blue is upper switch, green is lower switch.
We have three states that the transfer can be in: shooting, intaking, and off.
When intaking, we run the upper and lower transfer until we see the switches activate. When the upper switch activates, we stop running the upper transfer, and when the upper and the lower switch activate, we stop running the transfer entirely (and we also raise the intake for a few reasons but that’s not about transfer logic).
When shooting, the transfer runs the same logic as when intaking, until the shooter is up to speed. When the shooter is up to speed, we run both the upper and lower transfer regardless of the switches. (We never optimized the shooter to the point where we had to add delay).
The intake command runs the intake subsystem and the transfer subsystem. The shooting command controls the shooter subsystem and the transfer subsystem. If these commands are run at the same time, the shooting command takes precedence in the transfer subsystem. This doesn’t affect the intake or shooter subsystem at all though because they are separate subsystems. We rarely had good reason to intake while shooting, but it was useful at times.
A few notes:
- The transfer motors are run pretty slow, and their neutral mode is set to brake. If they ran just a little bit too fast, sometimes cargo could slip to far and touch the shooter flywheel.
- There’s constant contact with the cargo in the transfer. You can see in the picture we use grey compliant wheels as well as the belts to insure that we never let go of the cargo.
- The distance between the switches are about 10 inches (iirc). They have to be greater than the diameter of a cargo ball (9.5 inches) or cargo coming in from the bottom would push cargo already staged at the top into the shooter flywheel.
- We should probably switch to beam breaks, but the logic wouldn’t change at all.
- If we cut off the upper transfer, or just had one motor driving both belts (which we realized is what we should have done too late), the logic would not change at all. We would use a sensor on the intake mechanism to hold cargo.
Thanks for giving your solution. Can you give a side photo of your conveyor? Maybe this will help the understanding.
What is the limit switch?
I took the image from our robot reveal, where you can also see the robot intaking and shooting:
Team 5675 used a very simple design this year to move cargo and get it into a position to shoot. It used gravity and a single motor. Our shooter was offset to one side of the robot so we had a very simple ramp to move the cargo to the correct side where it would then stage for the next action. The cargo would settle underneath what we term the “gate”. This was a single motor attached to a couple of compliant wheels highlighted in red in the picture. This would grab the cargo and move it slightly forward until it tripped a proximity sensor, not pictured, but where the yellow circle is. At this point, the cargo would stop until a button was pushed by our aux driver. When the button was pushed, the main flywheels at the top would spin up to the appropriate rpm, then the gate would push the first cargo up where it would hand off to the main flywheel that would pull it through the rest of the way. If we had a second cargo it would quickly follow the first one, as long as the button was held down.
Hope this helps and answers what you were asking.
After experimenting with proximity and colour sensors (and never getting them quite right), our team ended up with a pretty simple sensorless feeding system using two motors (two motors made sense anyway since they had to spin in opposite directions):
- When intaking, only the lower (cyan) rollers spun. These were programmed to continue to spin for a half second after the intake was retracted to make sure balls were pressed up to the top (held stationary) roller.
- When shooting, both the top (magenta) and bottom rollers spun together to feed balls into the shooter. (Note, the lower roller added a very little reverse jog to avoid jamming the two balls together, which was an early problem with the s-path feeder).
I’ve also seen teams use a single motor and pneumatically actuated “gates” to hold balls just below the feeder. Very simple.
Our indexer uses two independently driven sections (two compliant wheel shafts to the upper section and one to the lower section) and two break beam sensors to control the cargo feed. During intake, both sections of the indexer are driven as the first cargo comes in and bring the cargo up to the upper sensor, which then stops the motor for the upper section. The lower section keeps spinning as the second cargo intakes, then it crosses the lower sensor and stops the second motor.
During shooting, the sensors retain the cargo until the flywheels have spun up, then both indexer motors are powered to feed the cargo (already properly spaced out by where they were stopped during intake) into the shooter. It’s a pretty straightforward system and works very well. Here’s the robot with the sections highlighted and two cargo in place and ready to shoot:
We used three beam break sensors and 1 color sensor, and the entire logic for color sorting is very much part of the feeder control, so I’ll include it.
The mechanism has three motors: intake, indexer, and magazine.
There is a beam break in the indexer mechanism over the color sensor and 2 in the cargo storage section where the balls should be. When a ball comes in (passes through the indexer beam break), its color is sampled. If the magazine is empty (both cargo storage beam breaks are not tripped), if the ball is the wrong color it is rejected through the shooter; if it is the right color it is pulled into the magazine until the first beam break is tripped.
If another ball comes in while the first beam break is tripped, if it is determined to be the wrong color it is rejected through the intake. If the ball is the right color, however, the magazine runs until the first ball reaches the top (which also brings the new ball into the lower magazine position).
If a third ball comes in, if it is the wrong color it is rejected through the intake. If it is the right color the indexer stops to allow us to hold it. This was important for if we ever needed to hold 3 balls, which we used for our 5-ball auto.
When it comes time to shoot, we aim the hood and turn to face the goal while reversing the magazine until the top beam break is clear. The moment it is clear, we spin up the shooter and then run the magazine forward at a fixed speed. The intake and indexer also run at full power during shooting to prevent jams and shoot any cargo stuck in the intake-indexer section.
I should note that our magazine is mechanically capable of letting balls at the top slip to get the balls side by side. However, we found that our shooter had more consistency issues shooting too rapidly and having the balls side by side in the magazine was not important.
Edit: we added this mechanism after our first regional. During our first regional we had a fully manual sorting system run by a second driver.