How does team with a long conveyor make full use of it? This season has a two ball limit, but l remember many teams (like 1706 , 1323 and 694) still use a long conveyor. l am curious about whether these teams have made a mechanism (or code) to calculate the number of the balls in their conveyor automatically. l have thought about this problem for a period of time and can’t find a perfect solution since there are many situations. For example, how to combine the calculation of the number of balls in robot and the shooting of the ball. How to make conveyors, intaker and shooter cooperate smoothly without any jam? The available sensors are IR sensor and color sensor.
Personally, we always design around game piece limitations. That means designing in a way to ensure we only pick up the limited number of balls. This year, it meant a relatively short conveyor. When full, we knew exactly where both balls would be, allowing us to put two sensors in place to detect them, and give our drivers some feedback via LEDs. We used a similar system in 2012 when there was a 3 ball limit as well. With the 5 ball limit in 2020, we opted instead on the method below.
With a longer conveyor, it’s not as foolproof, but you can do much the same by counting with an “in” sensor and an “out” sensor. That way you know when a ball comes in, and when one goes out, letting you increment and decrement your counter as appropriate. A range finding sensor pointed along the long axis of your conveyor can help act as a verifier to tell you when it’s empty.
We do have IR sensors for bottom and top elevator sections but from a code standpoint we do not track or note how many balls go through the robot, basically the code says if there’s not a ball in the top, then run the bottom and top stages until there is. Once there’s a ball in the top, make sure to wait about 60ms minimum to give the color sensor time to update and allow the “SmartShooter” class to change it’s intended target if the ball color does not match our alliance color per the FMS/DriverStation.
I definitely think the elevator we used for the balls is too tall this year and probably creates some weakness, the nice thing is taller means flatter shot which means less time of flight and makes shooting on the move easier and does allow it to lower error accumulation from all the sensors for that mode.
As far as ball limitations are concerned, we usually shoot 1 ball quickly enough that if we happen to accidentally grab 3 or 4 we can get rid of them before it’s a rule violation. (An example of this with 3 is Quals 111 of hopper with about 21seconds left) and it also allows us to “slurp” the balls on the sides of the field a little bit easier as the Intakes have more room to let balls relax while the shooter is shooting them out.
As far as jamming goes, we have enough room left for the balls to move around that in the rare cases where 2 balls come in perfectly symmetrical in one intake we can quickly actuate the intake and one almost always beats the other and makes it way in.
Technically our robot can cycle 6 balls at once if there wasn’t a rule violation for it, not optimal at all for this game but sometimes you can’t get it all right. Makes a good show for demos though!
Lots of specific answers here and on the other thread, so I’ll give a more general formula for how to go about this sort of mechanism design:
Start with basic requirements
a. How many gampieces have to be held at once?
b. Where can/should they be held at?
c. Do you need to eject? sequence?
d. Where do they need to enter the conveyor, where do they need to leave?
Design some basics
a. Namely, pick a path, dimensions, and mounting points to transfer the gampiece along that path.
Split the mechanism up. Add the right number of “degrees of freedom” to achieve the gamepiece motion desired.
Figure out how to detect gamepiece positions with sensors
Design a robust software strategy for all permutations of sensor input.
Step 3 is pretty critical - before trying to even discuss software, the mechanical design team needs to be able to show how someone with eyeballs and a brain will manipulate the parts of the conveyor in a way that picks up, moves, and ejects gamepieces in the order & spacing desired. If they’re struggling to actually do this by hand, you’ll have a rough time getting anything to work under software control.
A critical set of questions to ask when doing step 3 - for each “move” that the conveyor requires, does the move require you watch a gamepiece to achieve a certain position? Or could you close your eyes and just count out the right number of seconds, and the piece will achieve the right position?
Step 4 is also very critical, but more electrical/software team focused. That’s where you get to take the “requirement” that comes from step 3, and figure out which pieces of information you actually need to accomplish the control strategy developed in step 3. Some simple conveyors with only one game piece might need a single “thing present” sensor. Others may need multiple sensors, or sensors that can detect the shape of the gamepiece to stop it at different positions.
And finally, only in step 5, do you start writing the software. Be sure to account for all conditions (ex: what if your code resets mid match with gamepieces in the conveyor?). As with most things, start with motors running slow to prove out the concept works, then crank up the speed to achieve performance.
I was mistaken, it is actually 100ms I think we started with 60ms but sometimes we would not catch it in time so we wanted to make sure we never scored the wrong ball into the hub.
I was going to work on making a post for this years code with some details on our thought process and our iterations but our senior programmer left once the summer hit and I have been really busy. So here is a link to the code, in the commands->Elevator->SmartFeed.java file you will see how we implemented the code. Then you can see how this is accessed in the commands->TurretedShooter->SmartShooter.java where we set the target to a seperate location for 100ms if the wrong color is detected (this basically allows it to get time to get rid of the ball before moving back) these values were tuned experimentally.
Thanks a lot! A question suddenly occured to me that if there’s not a ball in the top, you have said you will run the bottom until there is a ball in the top, but how can you make sure that during the process before your ball gets to the top, you won’t intake two or more balls (and you will have three balls in your robot if so)?
Currently there is nothing stopping us from getting more than 2 balls. Driver is trained to shoot one out ASAP if he has 3 balls. Usually its pretty obvious when you pick up 3 due to the openness of our robots super structure / elevator, you can see you have 3 so he makes sure to shoot. He is pretty much trained not to hold any balls longer than a few seconds anyways (If he picks up 1 ball he just shoots it on the way to the next ball(s)) because we always want to get the balls scored as fast as possible so they can clear out of the hub and get back on the field faster. (what we found is holding ball(s) at any time, even just a few seconds, reduces the scoring opportunity for both partners immediately, this is also why triple offense can at times be weak because if one of the bots takes longer to cycle they are removing potential opportunities from their teammates, especially if the opposing alliance has a defender with 2 balls reducing your alliance total to 9)
Conveyor is automatic, but the feeding of the shooter requires to driver to hold left trigger so he can let go when he’s moving less smoothly or being defended.
2 CARGO max. ROBOTS may not have greater-than-MOMENTARY CONTROL of more than 2
CARGO at a time, either directly or transitively through other objects.
A ROBOT is in CONTROL of CARGO if:
A. the CARGO is fully supported by the ROBOT,
B. the CARGO travels across the FIELD such that when the ROBOT changes direction, the
CARGO travels with the ROBOT,
C. the ROBOT is holding CARGO against a FIELD element in attempt to guard or shield it, or
D. the ROBOT is preventing a CARGO from leaving a LOWER EXIT.
Violation: FOUL per additional CARGO. If egregious, YELLOW CARD.
Egregious examples include but are not limited to the following:
a. simultaneous CONTROL of 5 CARGO
b. CONTINUOUS CONTROL of 3 or more CARGO
c. frequent CONTROL of 3 or more CARGO (an approximate count for frequent
in this context is if this rule is violated more than 3 times in a MATCH)
• MOMENTARY describes rule violations that happen for fewer than approximately 3 seconds.
• CONTINUOUS describes rule violations that happen for more than approximately 10 seconds.
If we happen to control the ball for more than approximately 3 seconds occasionally it is a foul so its import the driver knows to get rid of the 3rd ASAP, yellow card if you do happen to hold 3 for more than 3 seconds, 3 times. Or once for more than 10 seconds. Or pick up 5 which is very unlikely as we would have to have 2 in the elevator, 2 in one intake, and 1 in the other.
We have used beam break sensors (IR) in the last two games. We do a 4 motor system, intake, conveyor, index, shooter.
We place a row of holes for the sensors near the top and bottom of the conveyor. The bottom sensor it is positioned at the point where the ball is in contact with both the intake and conveyor.
At the top the sensor is placed so it detects when the ball has sufficient contact with the Index wheel. When the shooter is up to speed the index wheel is controlled by the operator when that has run and the upper sensor has cleared the conveyor runs until it gets tripped again, putting the next ball in the shooting position.
By putting a number of holes we can adjust exactly when the beams are tripped. Using this method it does put a small space between the balls so if they are of the sticky nature they don’t get jammed. It does take some trial and error to get the speed to run the conveyor right, but once that is done we have had good success.
We do not count the balls with this but there is no reason you couldn’t add that to the programming.