Let’s just say I’m getting pretty desperate to get my hands on those nice single roller 2.75 inch Omni wheels that have been discontinued so I can do position tracking.
Should VEX bring back these wheels for sale?
PS I already know that it is possible to cut the newer 2.75 inch Omni wheels to fit in the same space, but I don’t have the proper equipment or trust in myself to cut them.
Whats wrong with using the 3.75"? Just about every team uses them now
Mainly cause those are a different width than the old Omnis and I don’t have space for them on my chassis. If I’m wrong, please correct me.
Don’t use tracking wheels. It’s not necessary with v5. You can get extremely accurate results with IME’s. I don’t know why this topic keeps getting brought back to the forums. If you can negate wheel slippage through code then there is absolutely no reason to use separate wheel tracking. That was primarily for v4 in which there were no built in encoders. If you find that you absolutely need separate tracking wheels, then feel free using it. Trouble shooting odometry is not very easy, but best of luck.
You can get accurate results with IME’s… as long as your wheels don’t slip. Most simple autonomous routines (such as teams using motor.move_relative(distance) or even the Okapilib Chassis Controller class) will experience wheel slippage at the start of each movement as the wheels rapidly accelerate.
The solution Invictus used was to use motion profiling. Using that took plenty of tuning, smart memory management to avoid memory overflow errors, a special routine to reset the robot’s heading… Arguably it was more work than just slapping a few tracking wheels on the bottom, using Okapilib’s built-in odometry, and tuning a few constants.
But there were encoders for v4 that were part of the motor. The integrated motor encoders would screw directly on to the back of the motor housing. They were much easier to set up than regular old quadrature encoders, because teams didn’t have to design any mounting/chain/gearing necessary to connect them to the motor. Yet teams still elected to go with the regular old encoders and tracking wheels, because they provided a strong improvement in accuracy over encoders integrated into the motor.
Using the integrated motor encoders will tell you about your robot’s movement forward and backward. There is no way to use integrated encoders to tell you about your robot’s movement side to side. A 3-wheel tracking setup, on the other hand, provides this information, which can allow teams to develop routines in case their autonomous gets pushed off course (perhaps by centrifugal force when doing a tight turn, by their alliance partner, or by an opposing robot crossing the center line).
From what I know, the IME’s were just bad and faulty. Using quad-encoders would probably be worth the time and effort to put in over the IME.
Yup. The v4 IME’s were utter garbage which is why no one used them.
You actually can do this but it won’t be as accurate as a 3 wheel tracking system because of wheel slippage. Regardless, your robot shouldn’t be traveling horizontally unless you travel along an arc in which case you’d use a motion profile to have a very smooth changing acceleration. There is no defense in autonomous, other than your alliance partner, but assuming they will stick to their side of the field then this shouldn’t be an issue.
Hence why I said you wouldn’t use the built in velocity control.
It’s not that easy. You have to get an accurate model of your chassis and it is prone to inaccurate sensor readings. You need to know the exact geometry of your robot to successfully use odometry. Also, I am not a fan of using pre-built controllers. This is not the best way to learn how to code, nor is it the best way to code in general. Those controllers aren’t perfectly universal, if you need to make a very specific change for your robot then you can’t. Not having the right understanding of code is gonna lead you to a lot of frustration, I would highly encourage you create your own controllers.
At the end of the day, the best solution for one robot isn’t the best solution for every robot. This is coming from experience. Just because one team was successful with odometry and another team was successful with motion profiling doesn’t mean you will be. I believe my solution is more space and weight efficent, and a great catalyst for learning to code in the same way an actual engineer would.
By that argument, odometry isn’t simple. If you jump from “motor.move_relative” to odometry then you’re in for a very bumpy ride. Not only do you need to track the robot’s position, but you need to have the robot decide where to go from there. That is the hard part. In which case, you’d still need PID to control the robot’s movements or somehow find a way to autonomously generate a motion path on the fly based on variable displacement.
I think a good middle ground would be to just have a sideways omni on the chassis to track side to side turning and that’s it. You can use the imes to track back and forth motion with a reasonable degree of accuracy
This is true given properly tuned motion controllers. Coming from experience, a lack of a horizontal wheel will be burdensome to troubleshoot. You won’t know what exactly went wrong and if it was because of the lack of a horizontal wheel. To ensure your wheels aren’t slipping, you can have the robot travel slowly and design your robot with respect to center of mass. A perfect weight distribution will best optimize this. Basically, whatever you add to the front of the robot should be added to the back in terms of weight. (To a degree but you get the point). The IME’s are technically perfect mathematical models of the robot’s position, but in practice, this is almost never true.
The old 2.75" wheels aren’t strictly necessary to use position tracking - in fact, I’d avoid them if you can, because using them effectively requires filing down the wheel hub between each roller to avoid friction when they slide, which is not fun. The 3.25", while a bit wider, work just fine - we used these for position tracking in Starstruck without issue.
Exactly. This is why I think comments like this:
aren’t really productive. Each team has different experience, different resources, and different goals. For some teams, tracking wheels are a good option. For others, not so much.
the reason people implemented tracking wheels was likely to not use encoders for their drivetrain in the first place
It is productive though. This topic has been posted several times with the same views expressed each time. I don’t think this topic needs to be revisited every week for the fact that learning how to code your robot is more important than unknowingly putting tracking wheels on your robot without knowing why you’d do it or what problem you’re solving.
Tracking wheels use encoders… that’s what enables them to “track”.
The reason why I said your comment was unproductive was because the goal of this thread is to talk about how best to adapt to the unavailability of narrow Omni wheels that are better for use for tracking wheels.
You made a post stating that the OP should not use tracking wheels whatsoever. I trust that the original poster has probably put serious thought into deciding whether to use odometry or motion profiling. You evidently did not trust them.
I was simply pointing out that there are arguments both for and against the use of tracking wheels. That is why I did not respond to your post with counterarguments. Like you said, people have debated this plenty.
It would be one thing if you left a comment saying “I don’t think you should use tracking wheels, and here’s why.” But your original comment, stating “don’t use tracking wheels,” doesn’t help anyone learn the tradeoffs inherent in odometry systems, when they are useful, and when they are not. You also stated that “there is absolutely no reason to use wheel tracking,” which is objectively false for reasons I’ve already pointed out. There are pros and cons to both sides.
It is fine to have your own idea of what is best. It is fine to try to respectfully convince others of your idea. But you should not insist that others follow that idea, without even acknowledging the arguments for either side.
Whatever floats your boat man. Sometimes playing devil’s advocate is more productive than trying to enforce an unrealistic notion. I feel like this forum has constantly brought up a 3 tracking wheel assembly ever since pilons successfully used odometry. They said they spent years perfecting that code. I’m just being realistic, and offering a more viable option. Working to develop something (like odometry) that can be easily solved with more simple options (PID) that work just as good if not better might be stubborn.
This is taken out of context - it took us years from when we started until when we won worlds with it. It only took 2 or 3 months of from start to having decently working motion algorithms. And that was without any external resources other than Khan Academy, Wikipedia, and enrollment in high school physics courses. I’ve seen other teams with a moderate level of experience develop similar systems in a similar time frame since then.
I agree that position tracking isn’t strictly necessary and shouldn’t be pursued by every team at every skill level, but it’s entirely wrong to say that it’s a waste of time or that no one should do it. It’s not unrealistic, nor unproductive. It’s evidently realistic because multiple teams have been able to implement it, and I’d argue it’s productive because it provides an opportunity to learn a lot about programming, control theory, physics, and calculus & vectors, while also potentially contributing to your team’s performance. I’m not saying you need to implement position tracking, but I’d appreciate if you didn’t discourage others.
I also take issue with this:
Tracking is not an alternative to PID, it’s an alternative to assuming that your robot moves perfectly without incidental turning or slipping. We still use PID in nearly all our motion algorithms. Also, I have never seen any non-tracking solution perform nearly as consistently as one based on 3-wheel tracking, without significantly limiting speed or some other factor; if you have one, I’d be interested in seeing how it works.
There is such thing as a project that’s beyond reasonable scope for a team, but that depends on the team’s existing experience level and willingness to put in effort on advanced topics, not on the opinion of someone from another team on the forum.
Yeah, this is what I meant. The PID most teams use in Vex tracks linear movement but is still prone to inaccurate sensor readings from slippage and slop.
I’ll use more conservative wording next time. I just assume most teams on the forums are newer considering the context of this thread and other threads like it.
As for the this:
I was once conversing with a computer science professor about odometry and the way it’s set up on a Vex robot. He said you could get away with just an accelerometer, gyro ( and maybe IME but I don’t quite remember). As for the code, I couldn’t give it to you because I don’t have it written, and the conversation wasn’t exclusively in terms of vex so I can’t guarantee this would work with the limited capacity of Vex parts.
Yes, theoretically, you can get exact position by just double integrating a 3 axis accelerometer, but in practical terms this is extremely hard to be reliable in general, and the limits of the EDR system don’t help.
The current gyro is actually pretty similar in terms of how it works, it measures angular velocity (I wanna say) and integrates that into current angle. The Cortex/M0 Microcontroller does this for you, behind the scenes.
As @MayorMonty said, this is hard to get reliable in practice. I actually implemented this in FRC in an attempt to get position tracking working there, on a much better accelerometer and gyro than the VEX one, and found that any amount of vibration (such as from a motor spinning) just threw it off as a result of the double integration. It’s very difficult to get any integration-based algorithm to be accurate when your data comes in discrete samples (we worked on a 500-microsecond cycle if I remember correctly).
Just to be clear, the reason why I said it would be hard for any other system to approach the accuracy of position tracking is that the other systems that were being discusses simply didn’t take as much into account as position tracking does. When you’re driving the robot at full speed, wheels will slip and the robot will drift a bit. “Normal PID” algorithms by nature assume that neither of these are true. The position tracking algorithm accounts for drift, and the non-powered wheels eliminate slippage from affecting readings. If you want to match the accuracy of position tracking, you need to take both of those issues into account somehow.