I am having trouble using the competition template. I have an auto program in mind but it wont let me insert any of the program flow options unless I right click and close the auto mode. If I do that I cant program auto mode. Am I missing something?
Well after reviewing the problem and talking with computer people I found the problem.
How can I make 2 motors rotate in opposite directions at the same time for a given time? I am using v2.0 and the comp. template. I cannot use “Y” cables.
Well you start both motors but invert the dirrection of one of them. Maybe I’m missing something here but I don’t think that would be that hard to figure out…
I had the same idea but, if you say (4,255) (?m/sec) (4,127)/(5,0) (?m/sec) (5/127) it reads it top to bottom so one side moves then the other.
Well, have you actually tried that? The way easyC does motors is you turn them on then turn them off. So if you wanted to run both at the same time for the same amout of time/distance you would start them at the same time. Then put in a wait command for a certain amount of time then stop them. If you wanted to do it for distance you would put them in a while loop and run the loop until that amount of rotations has happend. True it reads top to bottom but it’s so fast you wouldn’t notice that one was started before the other.
The problem is that it has to start at the same time or the alingment will be messed up leading to catastrophic failure at the end of the process.
5 times in a row, try using the robot with software that turns on one motor first. Mark it’s final position and orientation at the end of each of the five trials.
Then alter the software to turn the other motor on first. Try using the robot 5 times again. Again mark it’s final position and orientation.
I’ll bet that uneven friction in the robot, minor variations in starting orientation, the slop in the motors, and drive train (the little bit of wiggle/slack that exists in the path from computer to floor through the drive train), how warm the motors are, uneven surface & wheel conditions, etc. will be far more important to where the robot ends up than are the few microseconds between when the computer issues one PWM command and when it issues the other.
Also, depending on how the circuitry works, the individual motors might always get their pulse trains in the same order, simultaneously, or in the order they appear in your program. Without investigating how the master processor and the hardware work, we really have no information about which motor will see a command before the other, if the commands are not purposefully separated by around 20 mSec. The processor we program (there are two in little gray box) is pretty “far” from the actual pwm output circuitry.
Go for it.
I’ll bet that uneven friction in the robot, minor variations in starting orientation, the slop in the motors, and drive train (the little bit of wiggle/slack that exists in the path from computer to floor through the drive train), how warm the motors are, uneven surface & wheel conditions, etc. will be far more important to where the robot ends up than are the few microseconds between when the computer issues one PWM command and when it issues the other.-Qoute
They aren’t on the drivetrain. They are used for something that requires a lot of power to operate properly. There is a common axle between the motors and so if they dont start at the same time the axle will be farther back/forward on one side when compared to the other. You’ll see it soon blake but for now I think I have the problem fixed.
It’ll be fine, I used 3 motors on my FVC and two shared an axle. There’s no problem.
I would think that Voltage would also effect the performance as well.
Voltage definitely affects the robots. I’ve found that the robot will quickly change how far etc it goes and then level off.
We are integrating sensors into our auto program for a much more consistant auto program. We are using 2 limit switches and 2 optical shaft encoders.