I continued to be a bit frustrated with the LabVIEW encoder VIs so I became determined to figure out how and when they work.
I discovered quite a few things through experimenation and disecting the VI’s.
I’m still not convinced I have figured out the way to overcome the occasional glitch, but I decided to write up my finding for anyone else trying to get the encoders working.
I have been studying this paper the last few days. Thanks so much for putting it out. Hope to do some tests this week.
Our team has two issues with Labview/Motor controllers/encoders. They are:
1)Reset encoders only works roughly 80% of the time, even when called twice. So frequently in autonomous the robot turns when it should have gone straight or vice-versa.
2)The motor controllers/encoders lock up (probably need a better term) and the robot just sits and jiggles back and forth. The only way we’ve found to get out of this is to cycle the power to the motor controllers. This just about ruined us in competition because if you lock up in autonomous, you’re dead in teleoperations.
Does anyone else have these problems, especially number 2? Does anyone know if the problems exist if you use RobotC?
Back to the paper, we will soon be trying Phil’s unblocking versions to see if this helps the situation.
We have both of these problems, and are trying to develop strategies to mitigate them.
Once such strategy is NOT to reset the encoders. If you never reset them, that problem goes away.
Something that is becoming clear to me is that for some reason the communications with the motot controller is VERY sensitive to battery voltage. Although these are nominally 12V batteries, when charged they get all the way up over 14V.
I’ve found that if the battery voltage gets close to 13V we seem to start getting more of the problems you are describing. Seems like that shouldn’t be the case but it’s what I’ve found. That’s one reason I created the Battery monitoring VI. I need to know when that occurs.
We have two batteries and so we always have one on charge when using the other. After about an hour of testing you HAVE to change the battery otherwise you start getting those dropouts and “shimmies”.
Another thing we found is that we get MUCH better reliability in AUTO, if we actually power down the NXT and 12V before each run. This emulates what happens on the field so maybe they discovered the same thing. If we just run the auto program three or four times in a row, successive runs seem to mess up, even if we reset 12V power and restart the NXT program. It’s as if the NXT and motor controller get left in a bad state if you just stop the program and restart it. I can’t explain it.
Bottom line, the NXT/Motor-controller communications are NOT solid enough (for a real competition), and the trick is finding the way to mitigate the problem.
From what little I’ve seen, it seems that Robot C has simmilar problems.
We’ve found the same connection to battery voltage, although we find the voltage has to stay considerably above 13V, more like 13.7 to minimize troubles. Sometimes we think it is related to the NXT battery voltage also.
I’ll share the one trick that we developed at the VA Tournament. We hooked a Lego motor to the 12V switch. Then if the motor controller acted up we could remotely switch the power on and off. This saved several matches.
We haven’t been switching off the NXT between practice runs as the bluetooth is such a pain to hook up.
We have been trying code that uses this strategy based on the examples in your paper. We read the encoder, add the number to it that we want to go to, run the constant speed vi until the encode reads the new number and stop.
Most of the time this is working really well. It definitely has gotten rid of the jerky motion that won’t die without killing the power.
But sometimes either the encoders don’t read or the loop processes to slowly and the robot goes way past where it is supposed to stop. It is somewhat random as it will work one run and not the next. It is frustrating and time consuming.
Have you seen this? Do you have any ideas how to fix it?
Thanks,
I’m not Phil and I’ve only worked with Vex and FRC encoders… so, for what it’s worth.
You sometimes get this if your encoder is spinning too fast for the computer to keep up with it. Adding a gear to a half-speed shaft running just for the encoder can fix this. In other words, if your encoder is on your drive axle, add a small gear to the drive shaft driving a big gear on another axle with an encoder on the shaft. The second shaft doesn’t do anything except drive the encoder running at half speed.
If it’s more subtle than that, let’s wait for someone who knows what they are talking about.
I still see times when for some reason the NXT stops being able to talk to the Motor controller. When it happens, it usually continues for about 2.5 seconds, and then corrects itself. Not helpfull if you are planning a complex sequence.
The encoders keep running insider the speed controller, but don’t get seen by the NXT untill after the bus fault clears.
Are you keeping track of your 12V battery voltage? My experience is that these “random” problems occure much more if the battery voltage is let go below 13.5 V (some have said 13.75V)
This isn’t a great lot of help, but we’ve just resigned ourselves to keeping the battery charged and putting up with random motions.
I’ll say that we also get our best results if we power down BOTH the NXT and 12V betwen each run. It just “seems” to help. The glitch seems to occur whenever we forget this power-cycle step.
