Hi, im having some problems with the feeder, we planned to keep a cargo ball inside of it and we use a distance sensor to detect when a ball is in the feeder, the idea was that whenever the sensor detect the cargo, the feeder will stop to store the cargo, but we want the feeder to stop with the cargo in the same position every time, the problem here is that when the sensor has detected the ball, the motors of the feeder take time to stop, making it so inaccurate and the ball position is not the same everytime, can u guys help out on how can the motors stop kinda instantaneously or to make up another method to store the cargo
This is a pretty vague question - if you want more specific advice, it would really help to post a picture or video or your system.
Without completely understanding your problem, though, if you want the cargo to index to a set position it would be relatively easy to make an actuated hardstop for it, rather than stopping the motors.
Are your motors on coast mode or something? On brake mode the motors should stop almost instantly.
So assuming angular momentum off all the wheels, belts, etc. in your indexer isn’t insanely massive, the best advice I can give is (in order):
- Ensure speed controllers are set to brake mode
- See how repeatable the amount of distance error you have is, if it is predictable go ahead and just factor that into the code
- Use a smaller faster motor with a big reducation vs a larger slower motor with more torque, rotor inertia and reduction have a LOT to do with stopping a system fast, even with something heavy on the other end (something something, falls off with the cube power, something something, not my area)
3 Likes
We have had great success aiming a line-break/photo-interrupt sensor across the game piece’s path.
See a recent write-up here: FRC95 2022 Build Thread - #35 by JamesCH95
the motors are in brake mode, the sensor is running at 5ms, but the problem is that the roboRIO is taking too much time to teell the motor controllers to stop the motors
The ball does not skid much and it is not due to the inertia of the motors, they are in brake mode and the sensor is running at 5ms, the wheels and the pulleys are going at 1600 RPM, but the problem is still happening even at 600 RPM, the pulleys have a reduction of 3:1, and the RPM mentioned before are the speed of the wheels and belts, the main problem is that the motors dont react fast enough to stop at time
a video of it occurring would be SUPER helpful
Is it possible, even with the 5ms polling rate of the sensor, that there is something in the code that is delaying the motors being commanded to stop? Or to ask another way, is there some lag somewhere in the code?
we think that is the time that the roboRIO takes to procces the data and the time it takes to send the signals to the motor controllers
it aproximately takes 40ms
yes, very helpful.
So I am not in control systems, but from a mechanical standpoint it looks like you are putting a fair bit of energy into that ball.
What happens if you:
- slow it way down (say 300 rpm)
- move the sensor further out if possible
one last question from me, how are you determining (with the distance sensor) what a ball is? are you just checking against a known value, when the ball breaks anything other than that value? or are you looking for a specific value (i.e. the distance sensor returns 4 inches)?
The reason I ask: say your intake funnel geometry is 20 inches at it’s widest, and that is where you are reading. Does your logic check for the first instance it sees a value under 20 inches? Does it check for when it sees a value < 20 inches then the original 20 inches (i.e. the ball completely passes the sensor)?
1 Like
What motor controllers are you using and how are they hooked up (CAN or PWM)? What rate is your main loop running at that’s polling the sensor?
3 Likes
That is… really fast I think. Also a very very short distance to stop the ball in.
I don’t have a timescale on the video, but since you know the record framerate and everything… have you measured how long the ball is in that tunnel position when the intake is running at its nominal speed? What I’m trying to get at here - since we know the software will indeed have some delay, what kind of time scale are you looking at to detect the ball and alter its velocity?
With this number, you can start to do some “worst-case stackups” on sensor response time, code execution time, motor controller response time, and maximum-achievable acceleration of the motor/gearbox/intake/ball system.
Just looking at the video, it seems mechanical has designed a system which is just barely at the edge of what software could theoretically control. It’s a hard uphill battle to convince folks who view software as a big black box that it does indeed have limits. But getting some numbers behind your software’s response time requirement will help build that story.
The rule of thumb I try to give to my mechanical team: If a student running the mechanism with a hand drill and watching with their eyes can’t reasonably control the mechanism, it’s unlikely software and electrical could build a control system to do much better. However, the only reason this works for us is the subteams have built credibility on both sides such that even if we don’t understand the requirement, we still attempt to achieve it.
3 Likes
it does work, but it’s still kinda inaccurate,somethimes the feeder takes out the cargo and then stops and most of the times it is not always stopping at the same position and what we want is to stop the cargo at the same position everytime to have the completly control of it
for the other question, we have a distance sensor in the first part of the feeder, we know that there’s a cargo when the sensor return a value of < 300mm, the feedback it returns when there’s no ball is 320-ish
We’re using the Spark Max throught CAN, for the velocity control we use the internal velocity control with the setReference method, we changed the rate frequency of the sensor polling through an addPeriodic method at 5ms
out of curiosity why are you running it so fast?
It is in case that if 2 cargos enter the feeder, make sure that they will not jam
this is a bit of a dumb question but, does it jam if you run it slowly?
So far this is what we tested, Here are the videos
In the videos you can see the inaccuracity of the indexer, it’s still having some delay problems
PD: We decreased the velocity to 300RPM (indexer velo)