One main feature of driver code I’m going to see a lot is built in auto stacking sequences. What I mean is the driver presses one button and it sets off a chain of reactions that make the intake pick up a cone then the lift goes up just enough so that one cone can be internally stack (if there is a chain bar or 4 bar then also is in the sequence). I bet most teams will assign a variable like coneCount and it tracks how many cones are currently internally stacked. However, isn’t this a very risky way to do this? If a robot can’t accurately track its cone count and is almost guessing with a variable, then complications can arise. Like what if the stack fails or if when the auto stacking sequence is going, the robot misses the stack and the cone is knocked off. Is there a way to combat this problem? Am I actually discussing something that makes sense or are you totally lost in what I’m trying to say? Thank you in advance.
You can have a second driver keep track of everything or the main driver presses a button that says the cone missed. And if the stack completely falls over have a button that sets it to 0
Its also important to have a simple “break” command incase something gets misaligned. All of the questions you ask are good ones and the ability to deal with these situations them will determine how well your autostack is implemented. At our first tournament one of the sensors became unreliable and basically broke out stacking functions. So yes, there are risks…
One solution I have seen is to simply add one to the count every time the auto-stacking is used. There is a button to subtract one from the count and a button to add one to the count manually and a button to reset to 0 once you unload the stack or if the stack falls. There are no sensors needed to keep track on the number of cones this way. With a little practice, it becomes rather natural to use.
My team uses a one button autostack that moves our chainbar back while the driver holds down the stack button and returns the chainbar back to its original position when our driver releases the stack button. The benifit of this system is that the driver can abort a stack at any time by simply releasing the button. Meanwhile, our stack height is controlled by the second controller. We decided against tracking the stack height with a variable because there isn’t an easy way for the robot to give feedback to the driver about the current stack count. Instead, the second controller has settings for groups of cones. Cones 1-5 are on the first setting, cones 6-8 are on the second setting, etc. That way our second driver only has to visually confirm the number of cones stacked and push the corresponding button.
I’ve been using an autostack algorithm since the first competition, and it’s been working very well.
The first version of the autostack used an ultrasonic sensor on the chainbar so that I didn’t have to keep track of the cones on the stack; the arm just kept moving up
until the ultrasonic saw a value large enough to indicate that there were no cones cones in front of it. This allowed the algorithm to be very dynamic as the driver did not have to correct the stack variable if something went wrong.
However, at the last two regionals I’ve used a regular autostack algorithm that does have a variable for the stack, simply because it lets the algorithm to be faster. If I can just specify potentiometer values for each mechanism based on the number of cones on the stack, I can multitask the mechanisms and have it score faster, whereas the ultrasonic-based algorithm went way too high each time before it continued onto the next step, so it was significantly slower.
For a basic algorithm I would definitely recommend using an ultrasonic so that the driver doesn’t have to focus on the stack, but once your robot becomes more optimized and you’re looking for speed, have the driver take the 30 seconds to learn two buttons to add and subtract from the stack variable, it’s worth it.