My team built an x-drive and we have been having problems with it when it starts from rest it veers off course mainly to the left side of the robot. We have tried counter balancing to make it even as well as measured the wheels to make sure that they are the correct distance away. I also tried making the code compensate the initial veer off course but the initial veer off course is not consistent every time, it veers off a lot one time, and not so much the next. It makes the robot almost impossible to code without a ton of sensors and any tips would be very helpful. I attached a video of the problem I am having. I would also love any programming tips that would help us get around this issue.
While you can mitigate drift in code, the root of the problem is mechanical, and that should be what you try to solve first.
The most likely culprit in you case is that one side of your drive has more friction than the other, which causes it to accelerate slower, giving you that drift you notice. You can test for this in a few ways, the easiest probably being to pick your robot up off the ground, spin all the wheels at full power, and then suddenly cut power to them all simultaneously. Observe how the wheels come to a stop, wheels with more friction will stop first. If there is a substantial difference in time between when one side stops spinning compared to the other, that’s the difference in friction causing your drift.
after trying to solve your friction problems, there are options for programming the robot to drive straight. In autonomous, you can use an inertial sensor to correct the drift of the robot by adding the angle of the sensor to one side of the drive and subtracting it from the other (that way the robot will automatically adjust its angle while driving in a straight line)
It isn’t about when they start and stop, it’s about how much time they take to get to full speed. If one side of your drive is spinning faster for a bit before it gets to full speed then you will veer off course for a bit and then it will straighten out (like in your video)
You could use the built in motor encoders in motors to print out the speed on the brain, but I don’t know how to program that or if there is a better solution.
The side with the battery looks to me like it is accelerating faster.
It can be that the base does not sit perfectly flat on the ground or that the center of gravity is off center. X drives need both to drive well.
Put the base on a hard surface and see if you can slide paper under any of the wheels. If you can, you need to tweak your frame.
Looks like you can put a 1x3x1 vertically below your base side to side and see if it tips forward or backward. Repeat front to back to see balance for side to side.
Vexcode and PROS both have functions, like motor.velocity() in Vexcode and motor.get_actual_velocity() in PROS to get the velocity of any motor. If you are looking to print the velocities, use std::cout to print the values to the terminal.
Query the motor speeds in a loop. If they differ by more than X percent, set a flag/variable and record the current values for all motors. Repeat this on a good bot that drives straight to get baseline values.
Swap brain ports… maybe there’s a current limiting issue (which explains why it happens are max current (startup)).
Swap motors… maybe one is weak. (see above)
Also, I’d bet there could be a problem with the code… the order in which motors are activated. Some are starting quicker than others… depending on where the code is when the joysticks are moved.
