I looked at the videos. Looks pretty solid to me? The ball, when it gets fed in, stops somewhere in that back path? I’m assuming the fact it doesn’t always stop in the exact same spot is the problem?
Assuming so…
So a bit of unsolicited advice: “problem” is a dangerous word.
You have to use it sometimes - “My thing has a problem” Is a key way to take ownership and responsibility, and drive results. However, saying it too often places blame in places that have no ability to fix the problem, which in turn causes progress to get stuck.
While I’m not saying software doesn’t have a problem, I’m also saying (from what I’ve seen here) it’s not obvious the problem is actually software driven.
I’d still recommend sitting down with your design folks and defining the physical range where it’s acceptable for the ball to stop in. Literally, pull up the cad model, and draw the volume where it’s ok to park the ball at. Alternatively, have them show you where they want the ball to stop, and ask how far off it can be (0.01 mm? 1 mm? 100 mm ?). For lack of a better term, I’m gonna call this the “success zone”.
Knowing the travel distance of the “acceptable” stop range, and the “running” intake speed of belts, you can calculate the duration the ball will be traveling through your “success zone”. Given this duration, you now have a requirement on the reaction time of the electrical and software system. All of the action of detecting the ball with a sensor, polling and interpreting the sensor information, making decisions, sending those decisions over the CAN bus to the spark max, letting the Spark max hear and react to those new commands, having the voltage and current actually change inside the motor, having the belt-and-ball system actually physically change speed… all that has to fit within your time requirement.
Given that requirement, you’ll know when you can stop optimizing the system, and move on.