Slipping isn’t a problem for auton accuracy. Its just not as efficient from a power transfer point of view.
I think the pilons strafing is an example of the quote above. They’re an excellent team and they were able to make non-tank work, but that doesn’t make it optimal.
It’s actually a huge problem for auton, and it’s one of the reasons motion profiles are so effective. Think about what’s happening when the wheels turn. If there is slippage, the robot is gonna think the robot is moving even though only the wheels are turning, not the robot itself. This means you will always undershoot the target and get progressively more out of line (exponentially, in fact, after each movement progresses).
Many teams fail to recognize this which is what makes slew rate control and motion profiles so effecttive over PID because PID only accounts for after the robot has accelerated to max velocity and is approaching its target, not the initial movement so even only using PID can be inaccurate. Or you could combine the two, or just use tracking wheels and not have to worry about it. It is a robot dependent thing though if your robot is very well balanced and maximizes traction, you don’t really need to worry about it.
This as well. If the wheels don’t maintain contact with the ground, the robot itself will not accelerate.
Yea sorry I’ll clarify. Slipping is not an issue because of tracking wheels. I was assuming the use of tracking wheels.
I mean, you can just use gyro/accelerometer and ultrasounds to do position if u don’t have enough space in your chassis for tracking wheels
That’s what we did in SS (along with line sensors) when we had x-drive and we ended 3rd in programming skills so it is reliable 
You mean taking the third derivative of acceleration to find position? I think there’s too much drift in even the new inertial sensor for that to match the accuracy of tracking wheels.
Unfortunately, the new IMU (inertial sensitive) is only a consumer grade product, meaning you can’t exactly get accurate results to do position tracking from deriving displacement from acceleration. On top of that, you need to account for 0 acceleration when velocity is constant. Perhaps you don’t need that much to precision for vex, but I think it’d be significantly easier to just use tracking wheels (there are also more uses with tracking wheels). As for ultrasonic sensor, I’m not sure how effective it is considering I’ve never used one.
I feel like space for tracking wheels should not be an issue for any team. If you want very reliable autonomous routines, you would make space for tracking wheels. My chassis is 25 holes wide and I still managed to fit three tracking wheels. It’s very tight on space but it works really well. if anything, the argument for not using tracking wheels would be having to overcome obstacles and platforms like we had to in turning point. Tracking wheels would interfere with clearing something that large I’d assume. But that is not the case for this year’s game.
The main reason we did this was to prevent the intake from potentially gripping two cubes side by side as well as aligning to goal zones during autonomous. (1961Z)
Yea with an angled front, just hitting the side wall automatically lines you up for deposit. Quite convenient… if rollers don’t hit first. If they do, there’s not much of a point.
I just did the slash cuz they’re one sensor now
Like I said in star struck we used 2 gyros a couple ultrasounds and a line sensor and made a reliable, high scoring, programming skills. We ended up getting 3rd in programming skills with no tracking wheels
the main issue that tracking wheels solve is inconsistencies due to wheel slippage.
but you can also eliminate wheel slippage by accelerating slowly. you could probably use the inertial sensor to make sure that you are accelerating slowly enough that your wheels don’t slip.
Wheel slippage doesn’t matter if you don’t use the intergrated encoders (imagine 
in between each word)
That was also on v4, a much different system than v5.
Refer to this thread:
Which is better? A db4 hybrid lifting just intakes with a cube lock or hybrid lifting first stage (4cap)
I’d say lifting a mini tray lets you tower swap and rapidly score towers without having negative effects on your stacking ability so that’s probably better.
I doubt this will be possible because the tray needs to tilt forward when the lift is up for clearance. If you have the tray tilted forward (even if only slightly), small changes in acceleration will knock the cubes out of the tray. So you could probably get away with driving forward with a cube lock but the moment the robot stops, the cubes will fly out (with this particular design).
Oh your totally right, the bracing would hit. There’s a chance you can get away with just bracing the bottom and center because your only lifting 1 cube, but that’s certainly a conflict.
That, or you could make a super compact dr4b and extend the arms beyond the gears and brace it from behind. I’m not sure how well that would work considering the load, but if it’s compact enough, it should suffice. I hate seeing really wide dr4b. It’s hard to brace a wide lift well.
Has this drivetrain design affected you negatively in any ways? My team going to make a second drivetrain of this style and start building on it, I would like to know if there is anything I should watch out for.
We haven’t had any issues with this base style, but I might recommend to make your base longer than 25 holes. This allows you to require smaller antitips and fit the components (brain, battery, tilt mech, etc.) easier.