FIRST Tech Challenge Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Move a Fixed Distance VI Problem

We are getting erratic results when using the Move a Fixed Distance VI.  What does Relative and Absolute in the VI polymorphic selector mean?

0 Kudos
Message 1 of 11
(10,161 Views)

Relative distance means move Distance encoder counts from the current position.

Absolute distance means move until the tachometer has a value of Distance encoder counts. For example, if you reset the counts, then moved an Absolute distance of 100, it would move 100 forward. If you then moved an absolute distance of 200, it would move 100 forward again.

0 Kudos
Message 2 of 11
(7,652 Views)

We are also having problems with the VIs.  We could get one MoveDistance VI to work.  We could not get 3 MoveDistance VIs to work - it only does the first one. We could get one MoveDistance VI with several Move-Wait VIs, but only with stops in between, but not MoveDistance.  I tried all the help I could find with no positive results other than people saying the VI positively doesn't work.

So, I tried to go with simpler VIs to sledgehammer it (I am an ME, and my last [brief] programming experience was NXT-G, and FORTRAN on punch cards before that).  I tried a MoveMotor (I think that's what it's called) and Spin (ditto) to create a simple move distance.  It works but really weirdly.  I have input values for distance and power (I also tried speed).  [I got a little fancy with the distance and calculated degrees based on wheel diameter {circumference}.  I also saw that the wires were the wrong color {and I was getting error messages about the number precision not being supported}, so I also added an integer I32 Boolean.]  When I change the power, the distance changes (higher power = longer distance).

So, I says to myself, "Huh!?!?!"

We're starting to get very frustrated not being able to have a simple autonomous that drives a specifed distance.

Any ideas?

I also found the following link that seems an order of magnitude more complicated, but it may be a big enough sledgehammer to work?  http://i.stack.imgur.com/ORolt.png

0 Kudos
Message 3 of 11
(7,652 Views)

Hi jncameronjr,

It is hard to determine what is going on without knowing what the expected behavior and the observed behaviors are. If you don't mind posting some of your code, it would be very helpful if you could start a thread on the forums and post a sample project there.

Are you seeing a correlation between Power and Distance using the Fixed Distance VI, or the VI you wrote?

The wires for numerics are orange for floating point types and blue for integer types. The NXT only supports single floating point numbers, and gives a warning when programs contain double floating point numbers. The warnings can simply be ignored by pressing continue, or you can right-click on the offending numerics and change their types (Representation).

0 Kudos
Message 4 of 11
(7,652 Views)

Hi Mike,

Historically, the encoders have been very unreliable when trying to move a fixed distance.  I don't know if that shortcoming has been resolved in the latest release but, based on you question, I'd guess not. 

Question for the NI folks.  Variations of this problem have popped up for at least 5 years in many forums including this one. Could you build a very simple bot with tetrix motors and encoders and test the move a fix distance .vi's?  It would be incredibly useful to have definitive guidance issue.  For reference:

https://decibel.ni.com/content/thread/20533?tstart=30

https://decibel.ni.com/content/thread/20408?tstart=30

http://ftcforum.usfirst.org/archive/index.php/t-258.html

0 Kudos
Message 5 of 11
(7,652 Views)

Hi rsthj,

We do have TETRIX bots and do test the Fixed Distance VIs in automated and manual tests. If you identify any bugs, please do not hesistate to report them so we can reproduce and fix them.

0 Kudos
Message 6 of 11
(7,652 Views)

Hi garrett,

Would you be willing to write a simple encoder-based autonomous--something like drive forward ~5 meters  and run it 10-15 times?  I believe that should be enough to demonstrate the unreliability of the encoder .vi's.  And, by having NI do it, it eliminates the possibility of wonky 3rd party code.   (It has been a few years since my team has messed with encoders and I'd be honestly delighted to be be wrong on this)

0 Kudos
Message 7 of 11
(7,652 Views)

I just tested this program, and it worked very precisely 10 times in a row. The rotations/meter constant will depend on the your robot. I encourage you to try again with the Fixed Distance VI and report any problems you see here or on the NI Discussion Forums.

MoveForward.PNG


Message 8 of 11
(7,652 Views)

Thank you!  I will revisit this with my team tonight!

0 Kudos
Message 9 of 11
(7,652 Views)

This program looks very similar to programs I have tried to use in the past but had issues with.  The issue I have always seen is with the encoder counts going to 0 randomly.  I know someone has said that when this happens the move vi assumes the motors have stopped moving and ends automatically.  Thus, we have random results.

I experienced this last year and in the testing I have done this year I am seeing similar results.  My plan right now is to write my own move vi to try to "ignore" these.  But that seems really crazy to do.  If you are not seeing the same issue, what could I be doing wrong or why do we see these random gaps in the encoder counts?

Thanks

0 Kudos
Message 10 of 11
(7,652 Views)