Code tweak for more reliable Encoder based motions.

[Philbot]

As our ream starts to build some of our robot’s automated sequences, we’re still noticing some glitches in the encoder based motor behavior.

In our case, we are running an automated sequence where a chain-driven fork lift, and servo articulated bucket are moved through a sequence of actions.

The motions are stored in an array of “position” clusters.  When we run the sequence, one out of 5 or 6 motor movements will go wrong.  They would either not be performed, or the motion was terminated prematurely.

I started doing some simplified testing and discovered than in many cases the TETRIX Motor Status VI was reporting, “Done” prematurely.  However, the actual motions did complete properly if MY code was modified to ignore the “done” status.    By “Done” I mean that the “Move in progress” goes False.

On investigating the actual logic for what the VI was doing, it appears that the code “defaults” “Move in progress” to False if there are any problems with the I2C communications to the Motor Controller.    So if there is a glitch, the move will be terminated by my program.  The code also does a test to see if the “I2C with Retries.VI” returns an empty array.  If you drill down into the code you can see that the low level VI generates a 0 padded array of the requested length if there is an error (so it will NEVER be empty).  Better to just check the “Success?” flag.

It seems that there has been some considerable attempt made to detect an error in the code, but on detecting an error, the wrong status seems to be returned.

Eg: If you are telling the motor to move a set distance, then you are waiting for the motion to complete.  If a random comms error occurs, the last thing you want is for the code to report that the motion is complete.   This will definitely mess with any pre-programmed sequence.  Instead I think you want the code to say:  “I’ve got a problem… but let’s keep going anyway”.

So, just for fun I tried flipping the error logic to return a “Move in Progress” of True.

This simple change made a marked improvement on reliability, but there were still some glitches.  So I started wondering if the data coming back from the controller was always reliable.

Specifically I wondered if I could tell if the “0 that indicated the move was complete” could be validated by some other control bits.  In fact it could.  The Hitechnic Controller mode register should contain 10b in its two lower bits to indicate that it’s moving to position.  So the “Busy” 0 in the MSB is only valid of the lower bits are 10.    So I changed the status code to look for 0xxxxx10 to indicate the move is complete, otherwise it signals that the move is still in progress.

Now I get 100% completion of the motor motion before the “Move in progress” Boolean goes False.  (No Glitches)

I’m hoping this means the end of bad arm sequences and the robot running into the wall during autonomous.

Here is a snippit of the code I use in "TETRIX Motor Status.VI"

The code under discussion is in the lower Case Structure.

The False case just returns TRUE.

Phil

[Philbot]

Here is a pic of the code I use to detect an actual "Done" State.

The FALSE case just returns a FALSE for Move Done since we can't tell if the move is done if the I2C read fails.