11-24-2014 07:24 PM
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:
[oops - gonna have to upload the rest of the files separately - only 3 attachments allowed]
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:
11-24-2014 07:26 PM
here're the other 2 vi's
11-24-2014 07:59 PM
We're apparently not the only ones either:
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:
11-25-2014 09:43 AM
Based on the code samples, it appears you are using LEGO motors as opposed to TETRIX motors. Am I correct?
11-25-2014 09:53 AM
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.
11-25-2014 11:07 AM
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.
11-25-2014 11:26 AM
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.
11-25-2014 11:44 AM
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.