Staying Straight while going forward and motorCoast not working

VEX IQ General Discussion
1 
 
while(true) {
   setMotorBrakeMode(LeftDrive, motorCoast); //Motor Coast 
   setMotorBrakeMode(RightDrive, motorCoast);
  
  distanceMoved = getMotorEncoder(LeftDrive); // Left P Control
	error = distanceSet - distanceMoved;
  SpeedLeft = error*kP;
  
  distanceMoved1 = getMotorEncoder(RightDrive); // Right P Control
	error1 = distanceSet1 - distanceMoved1;
  SpeedRight = error1*kP1; 
  
  if (abs(SpeedRight)<2){SpeedRight = 0;} 
  if (abs(SpeedLeft)<2){SpeedRight = 0;}
  
  /*angleMoved = gyroValue        // changes speed according to Gyro Value
    angleError = (angleSet - angleMoved)*3 */
  
  setMotorSpeed(LeftDrive, SpeedLeft - angleError);
  setMotorSpeed(RightDrive,SpeedRight + angleError);
}}

Hey I was wondering if anyone had any ideas to drive straight at a fast pace. Both of our wheel drives work virtually same the however we are having trouble due to inertia at the end of our command. We’re using a P control loop for each wheel side and as you can see above have also tryed using the gyro error to keep us straight (commented out). However due to the sudden brake mode of vex iq motors their is still inertia at the end which is not accounted for by the encoders. We’ve tryed using the motorCoast command but for some reason it does’nt seem to be working as both drives are still stiff at the end of the task.

Any help would be appreciated, Thank you!
Arav

1 Like
2

Check out this thread, although it is not VEX IQ it can be implemented in a very similar way: P & PID loop coding help ROBOTC mainly - #3 by Connor
Also, when pasting code on the forum make sure to use ``` before the code begins as well as after the code ends to make things neater. :slight_smile:

3

Unrelated, but I’m curious about the backgrounds of the students writing this code. Are they getting to this level of sophistication just from competing in Vex or are they taking some classes at their school or some kind of enrichment camps or something? None of my middle school kids are approaching anything like this or the other question posted about brain refresh rate.

4

I work with the schools “Code Club” on things like this. Those kids then spill into VIQ as coding roboteers

1 Like
5

We’ve got a long way to go

1 Like
6

Thanks for the complement :blush:

I mostly just watch coding videos and look at guides and VEX forum posts it looks a bit complexed but tbh you can learn stuff like this quite quickly if ur interested just by reading for a bit

Hope that helps
Arav

1 Like
7

I don’t think any of our students are quite that committed to coding yet, either.

8

I am doing VEX EDR, but I saw this thread and thought it may be a cool idea to introduce PID for the middle schoolers. By understanding how PID works, you can open the gates to more advanced coding such as filtering code and, hopefully in the future, get a better understanding of vision tracking in VEX IQ that will likely be legal in the future (Or it is legal right now?).
For me, I go around contacting teams that I know who are knowledged of the coding platform and I build up knowledge myself. As time goes on, the knowledge gets passed on team to team to become better and create a knowledgebase of information.
:slight_smile:

1 Like
9

Sorry about not pasting code correctly did’nt know you need three ‘. :thinking::upside_down_face:

I was wondering if you could elaborate on the problem on my P loop as it is stopping when it reaches the the encoder value correctly it just isn’t staying straight as after it ends it holds its position but the robot still moves because of inertia which isn’t counted into the encoder so thus does not get corrected would adding a derivative increase stability? I think the problem is the motorCoast not working but don’t really know I can send a video or full code if it would help

Thanks in advance
Arav

10

If you want to get a bit more precise and ensure that the robot itself can correct its angle depending on most circumstances, you could apply and tune a PID to the gyroscope to help correct the value (we can help you with that if you’d like). The wheels on robots can slip, but the gyroscope can help a lot with ensuring that the robot is aware of the slippage and correct itself.
In terms of the motorCoast command, it is only applied when the motor has a value of 0. It should be working when the position is reached, as what I can see with the “if(abs(SpeedRight)<2){SpeedRight = 0;}” But what I think is going on is that when you tell the motor to coast, the motor goes forward causing the encoder to realize that the robot is continuing forward, making “abs(SpeedRight)<2” return false and activating the P control loop again.

On another note, if you are having only a single command with the “if” statement, you don’t require any curly brackets.
if(abs(SpeedRight)<2) SpeedRight = 0;
Hopefully this helps :slight_smile:

2 Likes
11

You can also use the [ code] brackets

I like them better than the three ```.

1 Like
12

Thanks for such a detailed reply. I tryed using the gyro

if (abs(SpeedLeft) > 95)SpeedLeft = 95;
 if (abs(SpeedRight) > 95)SpeedRight = 95;
  angleMoved = gyroValue ;       // changes speed according to Gyro Value
  angleError = (angleSet - angleMoved)*1.5 ;

 setMotorSpeed(LeftDrive, SpeedLeft - angleError);
 setMotorSpeed(RightDrive,SpeedRight + angleError);

with something like this and a P control loop as seen above. What are the advantages of using a full PID for the gyro correction and forward commands as I have actually written a PID for forward but stopped after tuning for a while as i realized the robot was not staying straight . The gyro code doesn’t seem to be making a difference. My guess is that as the distanceSet is set to go to 100 encoder ticks no gyro corrections in speed are actually being acknowledged as the P control is updating the speed already with new values do u know how to incorporate the gyro error into the distanceSet so the corrections will go through

also when you said you thought the motorCoast may not be working due to
“activating the P control loop again” wouldn’t that mean the robot would start oscillating or a eventually reach the Coast mode, which is not happening to ours.

Thanks again!

Arav

13

By building and tuning a PID, you can make incredibly precise movements down to the degree, which also reacts and corrects the wandering forces that could exist. There is a chance that the robot will not drive straight when given independent PIDs per side for the drive, because the motors on both sides are being independantly controlled which could cause the robot to tilt back and forth as an oscillation while going. If you have a gyroscope, I would suggest adding all of the motor encoder values together and only have encoder forward/backward PID, Then having the gyro also have a PID to manage turning corrections. This will be more reliable.

Not necessarily. To start everything off you gave the motor only 2 degrees of freedom to coast. By doing abs(encoder) < 2, you are actually doing the same thing as abs(encoder) <= 1 (Which is an encoder range between -1 and 1) as you are using integers that don’t have decimals. Also, the code is using just a P loop, so there’s no correction to the course of the target in any way other than a fixed voltage. The Derivative helps maintain the speed as much as possible by adding or subtracting by a specific amount if the system is going too slow or fast to the target, and the Integral will constantly add more and more power to the motor within the smaller margins to ensure that the position reaches exactly at the target desired.
Hopefully this makes sense :slight_smile:

2 Likes
14

Okay Thank you for the advice I was wondering what you meant when you said

What do u mean by adding all the motor encoder values together ? Also would’nt the gyro corrections still be discounted by the forward PID control. Sorry for all the questions i’m quite new to this. :slight_smile:

15

When you are turning, you are adding power to one side and subtracting from the other. If you are going to integrate the gyroscope, you will need to set a maximum speed for the motors to make sure that there is enough room for turning. That’s a good point I forgot about that.
You’re very observant! :slight_smile:

This is what I mean by adding all of the motor encoder values together

while(true) {
   setMotorBrakeMode(LeftDrive, motorCoast); //Motor Coast 
   setMotorBrakeMode(RightDrive, motorCoast);
  
  distanceMoved = (getMotorEncoder(LeftDrive) +getMotorEncoder(RightDrive))/2; // Left P Control
	error = distanceSet - distanceMoved;
  Speed = error*kP;

  
  if (abs(Speed)<2) Speed = 0; 
  
  /*angleMoved = gyroValue        // changes speed according to Gyro Value
    angleError = (angleSet - angleMoved)*3 */
  
  setMotorSpeed(LeftDrive, Speed - angleError);
  setMotorSpeed(RightDrive,Speed + angleError);
}}
3 Likes
16

Thank You so Much You’ve probably saved me hours of work :smile: . The robot now officially stays straight going forward. The key was finding the average between the two sides. The only problem is the motorCoast which is still not working. I found this Motor PID regulator - #10 by nenik forum post that literally explains my issue however no solution was found. Does that mean PID using encoders to go straight in IQ is impossible ?

17

You can definitely use PID for straight in IQ. My team has been having issues with incorrect speed values being sent back from the smart motor. The wheels are clearly stopped but read as high as 3-4 rpm. Maybe try to increase the threshold to a little higher. Their robot will not move below about 5 anyhow,

1 Like
18

Please don’t reply to a dead thread. I see that you want to add to this conversation, but this is not the thread to do so (it hasn’t been replied to in over 2 years.)

5 Likes