I previously made a forum post about getting autonomous values by recording driver values. Here is the link to that forum post: Vexforum Post
When I try to run that auton code, the robot jerks forward and the motors don’t move the proper way. I previously had a wait command for 20 miliseconds but that did not seem to make any change. How would I make it so that the motors move smoothly like they did in driver control? Why are the motors jerky? Is there any way to fix this?
Here is a picture of the code:
Note: Previously, I had the final rotateFor set to true instead of false but that also did not make a difference.
I have the driver control posted in the previous forum post if you want to look at it. It might give you a better understanding of what the code’s doing. Every loop of driver control, each of the seven motors print the change in the rotation of the motor and the speed that it did that rotation. My idea was that it would just run through all of the code and copy exactly what the driver control did (which in this case was driving back and forth). I’m not sure why but the motors jerk back and forth.
The motors in drover control activate with input. Here, the motors activate by themselves, meaning that your code is probably (somewhere) telling the wheels to jerk back and forth.
For my auto , I used time and motor rotations.
Ex
Timer start
If (timer<2 seconds)
Then {
motor1 rotateFor 3 revolutions
motor2 rotateFor 3 revolutions
}
Else if (timer>2 seconds){
motor1 rotateFor 3 revolutions (backwards)
motor2 rotateFor 3 revolutions(backwards)
}
1 Like
The code is meant to be an exact copy of what the driver control is doing while it’s running. The only reason I could think as to why it would be jerking back and forth is if repeated commands like this don’t work well.
Just asking a noob question, do the three loops shown in the code look correct to you? Should I make the final false value true for each loop? Or is there something else that looks wrong? Any advice helps.
What do you want your code to do?
And what does it do instead? (I know you already said that but could you elaborate)
You need to have a sleep between each block of motor commands
Sure, let me put it into detail:
At the start of every loop in driver control, I have all of the motors reset their rotation values. Then at the end of the driver control I have the total rotation recorded and speed the motor was going at for that rotation recorded. Here is a picture of that:
Sorry if it’s small, open it in a new tab and that should be good.
The output just means that it’s printing that output to an “output.txt” file on the sdcard inside the brain.
Those output values are printed and look similar to the picture in my first post. My idea was that the robot would just run through all of the auton code and then it would be almost exactly what was done in driver control. What actually happens is that the robot doesn’t follow any of that and just jerks back and forth (maybe the motor values are conflicting). What part of the code looks like it’s conflicting? 'Cause I think that is what’s causing this issue.
Note: I’d previously tried adding a wait command between each block of code but that did not appear to do anything. Next I tried setting the final motor rotation value to true but that also did not appear to do anything.
First off, instead of setting rotation to zero like that, I would advise using the motor stop command, if vexcode has it.
Second, are you skimming the output file for data, for example,
Motor1 rotateFor x degrees, where x is the rotation recorded during driver control
2 Likes
It’s not really meant to stop the motor. The rotation zero means that for that loop the driver control did not use that motor. Making it motor stop might actually break it more.
What do you mean skimming the output file? I basically copy the entire 8000+ line auton file into Vexcode and build that.
1 Like
RotateFor has some very small values for the amount of rotation to perform. It is trying to rotate, say, 1 degree at whatever velocity. Once it rotates 1 degree, the motor stops, having reached its desired location. And even before it gets to that rotation, you are immediately issuing the motor another command.
This is why you see the jerking.
Your basic premise is sound, the implementation needs refinement.
1 Like
How would you suggest I go about it? Should I begin adding up the some of the blocks? For example, if I have three blocks with the driveTrain rotating 0.2 revolutions all three times, should I just make it one block doing 0.6 revolutions? I suppose it’s all down to testing, but I want to have an idea of how to approach it.
Scrap everything that I just said lol.
I misunderstood.
For the rotations, if there’s nothing you want to do before you hit 0.6 revs, then just straight up going to 0.6 revs would be better
Take this with a grain of salt though
1 Like
I think Taran posted his approach. You might review that and see what he does differently, given that his implementation behaves as expected.
You have about half the concept, but are missing the whole picture. You’ll have an Ah Ha moment, I’m sure.
1 Like
Taran? I’m not sure who that would be.
Without trying to give away the game, in driver control, do you use the rotateFor function or do you use something else?
We use the motor.spin() function but I don’t see how that would help here. I would need to run the spin command for a set amount of time and that’s really dependent of the battery remaining constant because the motors spin slower at lower battery. How are you suggesting use motor.spin? Is there a way to use revolutions in it or am I just completely off?
You are about 90% of the way there now. Spin does not take rotatioms
Are you suggesting to use time instead of rotations? I’m not sure how else spin could Be used
1 Like