How to get multiple Move A Fixed Distance vi's to work?

[jncameronjr]

OK, I've seen other postings where people didn't have luck with this vi.  Hopefully, the debugging I'm working on will help the community in figuring it out.  I'm looking start with a really simple FTC autonomous prototype to drive (straight) down the ramp, turn (towards a goal - hopefully we'll have a sensor too), deploy goal grabber, then drive backwards a specific distance and orientation (to the parking zone), then spin to deposit the goal.  So, the first challenge was drive forward, turn and back up.  This should've been a 30-minute exercise.  We probably have dozens of man-hours invested so far - with no luck.

So, I've included a series of vi's:

• 3movedistance_test doesn't work: it only goes forward; in fact it doesn't go exactly 360 degrees
• ditto on 2movedistance_test
• 1movedistance_test seems to work fine
• when I dial down the power on 1movedistance_test to 20%, one motor moves ~360, the other moves ~120

[oops - gonna have to upload the rest of the files separately - only 3 attachments allowed]

• 3movedistance_parallel - I can dial down the speed to 1, and both motors turn exactly 180 - it looks like they're taking turns though, they individually index about 30 times

That's phase 1 of the research.

Phase 2 was to get the sledgehammer out and skip the Move A Fixed Distance vi, and use the Wait For Rotation vi with a standard Move Motors vi.  MoveDistanceJC has the following characteristics:

• at 80% power, Motor B goes ~2-1/4 revolutions (obviously greater than 0.1") and Motor C goes 2-1/3 revolutions
• at 50% power, Motor B goes ~1-1/4 revolutions and Motor C goes 1-1/3 revolutions
• at 20% power, Motor B goes ~1/3 revolution and Motor C also goes 1/3 revolutions

[jncameronjr]

here're the other 2 vi's

[jncameronjr]

We're apparently not the only ones either:

1. Mike5027 2014.10.06
2. Mike5027 2014.10.09
3. 4644Mentor 2012.02.23
4. robuff 2012.02.24
5. philbot 20211.05.03
6. FTC7785 2013.10.21

The vi help is sparse in detail.

These are the only 3 possible workarounds that I could find that got me started on the variation in MoveDistanceJC:

1. How to calibrate NXT motors to travel the same distance?
2. LabVIEW example: Motors
3. FRC704 2011.02.13

[garrett8357]

Based on the code samples, it appears you are using LEGO motors as opposed to TETRIX motors. Am I correct?

[garrett8357]

For the most up to date help, press ctrl+H to open the Context Help window.

For 3MoveDistance_test, the power and distance terminals are not wired for Lego Port C. This means you are sending the default values, which are 360 distance and 75 power, the same values you are sending to Lego Port B. So the first Move a Fixed Distance VI should send both motors forward one rotation assuming you have reset the encoders. 

The other problem with the VI is you are asking to move an absolute distance of 360, but I think you intended to move a relative distance. If you have moved 360 counts with the first block, then the second block does nothing because you are already at 360 counts.

What is the VI supposed to do? If you wanted to go forward one rotation and then turn, try using the VI polyselector to choose Relative distance for both blocks.

[jncameronjr]

Yes, I am trying to have the software development work in parallel with the hardware development.  So, Programming learns the principles of LabVIEW on a LEGO tribot while Drivetrain develops the final chassis/motor assembly.

[jncameronjr]

Garrett, thanks for your thorough and quick responses.

I was looking at the <Ctrl>H quick help and also the advanced help.  I guess maybe  I'm/we're too tired to read it logically, but I apparenlty didn't understand the help graphics correctly.  I couldn't understand "relative" to what.  Relative to "0" which is initialized at the beginning of the overall vi, or initialized at the very beginning of the match [if we have other functions before these], or initialized to 0 at the beginning of each individual function?  With your explanation, I will try Relative tonight.

I don't understand your wiring comments because I don't have access to LabVIEW right now, so I will play with that tonight.

THANKS for the input!  I guess I can put my ME sledgehammer away now?

PS I'm not sure that explains why 3movedistance_test & 2movedistance_test  don't go exactly 360, but it might explain the odd behavior in 1movedistance_test vs 3movedistance_parallel

PPS I'm still not sure of the odd behavior in MoveDistanceJC with the Wait For Rotation function - I'll see tonight if these comments apply to that also.

[garrett8357]

Hi  jncameronjr,

I have a guess for why  3movedistance_test & 2movedistance_test don't go exactly 360. Say the motor rotates slightly as you are putting the robot on the ground. The encoder count may have changed to be 45. Then, when you move to the absolute distance of 360 counts, you are only actually moving 315. If you want to make sure the encoders are at zero, you have to use the Reset Encoders VI. The main reason why the absolute distance options were included in the module is that they are higher performance with the TETRIX motors, but in general, relative distance is the more intuitive.

Below is an example of what I meant when I said that the default values were being used because the terminals were unwired. 

Is the problem with MoveDistanceJC that you do not stop the motors after the rotation has been reached? Try adding a stop function after each of the Wait for Rotation VIs, and see if that fixes it.