Have you programmed that for full holonomic movement?
EDIT: Didn’t see the other wheel. It should be capable for full holonomic movement.
its an X the last wheel is hiding in the back somewhere
I did get the programming to work and it drives really well
Did you have problems with some of the motors being in reverse and therefore putting out slighty different torque?
yep, its too bad the motors go faster one way. I went through and fixed the values so it went as straight as I could get it, and I got it to work with one joystick with one of the transmitters (I have a problem with the other one) so it’s easy to control.
This has 4 wheels. You can see all 4. There is one hiding.
EDIT: oops losts of posts in the last few minutes.
Got any video?
(Originally posted here.)
hmm… Im not so sure if that’s true. During a summer vex camp we held at our high school, we had the 4th - 8th graders build the squarebots right out of the book. When they were being driven around, they would veer to one side because one of the motors was flipped over. I’m not sure if they fixed that problem or not, but it is certainly noticeable.
Maybe some random coincidence happened where motors on one side were in tolerance going too fast and motors on the other were in tolerance going to slow resulting in twice the error?
From personal experience I believe that at least some vex motors have a winding bias; however this also could be contributed to differences in motors. I was a programing mentor during a vex robotics camp last week and had huge problems with square bots driving in straight lines during auto periods. I had attributed this to a winding bias (the motors on a square-bot are inverted), because if it were a difference in motor manufacture I should have been able to fix it by adjusting the code. Even with adjusted code I found that battery power played a major role in the difference in motors indicating a winding bias.
How much drifting there is on a Vex robot has a lot more to do with friction in the drivetrain than a discernable motor bias.
If you build the squarebot and you notice that it is always drifting to one side, then one of the sides of the robot has slightly more friction than the other one. If you loosen some of the parts and try to shift some of the pieces around by a few hundredths of an inch you may notice that the drift will disappear.
Actually that makes a lot more sense than a winding bias. To add to that the kids that built that vex bots tighted everying to an extreme. Thanks!
but it has happened with every vex robot I have ever seen or made that had at least one inverted motor. The holonomic robot had 2 pairs of reversed motors, and when driven it would “turn” because 2 of the motors weren’t moving as fast. And I do not believe that every robot I have seen had a friction problem on one side.
Kevin these’s a pretty easy way to test this if you’ve got a spare motor. Just hook it up with an optical shaft encoder and add a gear up and a big wheel to simulate torque on a normal robot. Then run it for 1 min forward and 1 min backward and compare your numbers I would like to see this done.
results in. here’s what the shaft encoder read after a minute of full forward and full backward.
4.5 revolutions more when a motor is spinning backwards then when it is spinning forwards for a minute.
I dont think its the motors being biased, its probably differences in friction from the motor to the wheels, every robot in vex seems to have the problem, even FIRST robots with 2WD and castors have this problem without any correction.
I didn’t have any wheels on the motor. The shaft went straight into the encoder and nothing else. And you do have to remember that they are vex motors, which, I’m sorry to say, aren’t the hightest quality motors out there in the market.
I tested 4 more motors using the same program. The motors were consistantly about 3% faster going backwards than forwards.
I hope this settles the question of motor biasing. Also any distances counted without wheels will only be increased by added stress on the motor.
I was a FLL programmer for three years, and when using lego motors every motor ran at a different speed. I don’t think this is something that can be overcome when using DC motors.
I would like to see the code to make that move.