Hi, my son is having a problem with Robotc 2.16 and turning. Firmware is RobotC v8.11. He is using this code:



About 50% of the time this works, but the rest of the time the program gets stuck in the loop, typically with the motor encoder at 397-399. The bot just sits there with a high-pitched whine coming from the motor. Nudging it slightly will complete the move and exit the loop. Fresh batteries and changing the motors didn't seem to help. This is on a basic castor bot which is pretty much http://www.nxtprograms.com/NXT2/castor_bot/index.html, running on a flat smooth surface, so there is not a big load on the motors.

Is there any way of tweaking the PID parameters so it won't get stuck like this? He tried varying the initial motor[] value to 50 and 100 but this didn't help. He is currently detecting the stall in the loop and exiting, but then the turn is not as accurate:

You should also check for the runStateHoldPosition state, not just the runStateIdle, that might help you in this case.



I tested this and it seems to work just fine.

- Xander

Thanks very much for that Xander, that is really interesting. Looking at the Poll Brick window when the move is stuck, both motors are in Runstate Hold, should that be happening? If it exits the loop at that point then the move will not be complete but at least it's a fast way of detecting that it's stuck.

e.g. for this move with nMotorEncoderTarget[motorB] = 400 the Poll Brick window says:

motorB speed 70 PID 0 Mode "ON(Brake) 3" Regul sync Runstate Hold tach user 399 tach move 399
motorC speed 0 PID 0 Mode "OFF(Brake) 2" Regul sync Runstate Hold tach user -2014 Tach Move -402

Similar pairs of Tach Move numbers when it gets stuck for other moves e.g. tach move 398 and -401, 399 & -402

The problem is that it's so tantalizingly awesome when it does complete the turn accurately, you can do eight spins in a row and still end up facing exactly the same direction.

Well, you told the motor to move to a specific position, that's what it did. The Firmware will then attempt to keep the motor there, in other words, have the motor hold its current position

What exactly do you mean by stuck, is the motor holding position itself or are you blocking it somehow?

The regulator will try to get as close to the intended target as possible, so you may end up off by a couple of tacho counts. There is a feature within the bowels of ROBOTC that has enhanced ramping (which can improve your final target count) but doesn't work very well at all with synchronised motors. One of the developers implemented it for me to use for a very large robot arm for a show case. Unfortunately it was never finished to include multiple motor support. I ended up having to make my own (the shoulder joint of the robot needed two motors).

Video of built in ramping: http://www.youtube.com/user/xandersolda ... 8YIsW3cBTc
Video of home made ramping: http://www.youtube.com/watch?v=J8Pvr5QoJkU

The robot I needed it for: http://www.youtube.com/user/xandersolda ... qHRcFdoLxM

Regards,
Xander

By "stuck" I mean stuck in our program's loop waiting for runstateIdle. The motor has stopped and is holding, but not quite at the position we asked for (399 instead of 400).

The thing is that if you physically nudge the wheel connected to motor B, the encoder position will reach 400 and the motor goes to runstateIdle and we exit our loop. To me this suggests that the motor PID control and the nMotorEncoderTarget control are not quite in sync, shouldn't it still be trying to get to 400 rather than holding near 400?

That is, to me it seems like one part of the RobotC control software is waiting for the robot to reach the target and change the runState, but another part has decided to hold it just short of the target. Is the motor sync maybe averaging out the overshoot of the motorC encoder to -402 with the undershoot to 399?

Thanks for the video links, that robot arm is amazing!

Hoping to bump this up to get a response. If one has already been posted somewhere else I apologize

I'm seeing the same thing, just as described above. I've included my code. This is just a simple go forward then backwards, rinse and repeat. The code is out of my scratchpad program so there may be other stuff there that isn't used in the actual go forward/back part.

Battery level doesn't affect it. Batteries are at 7.83VDC and still happens. Nudge the wheels and it takes off. Reviewing the data in the debugging window, the wheels is stopped just before the stopping point so the endcoder target is never reached and it just sits in the loop waiting, and waiting.

Please send an email with a detailed description of the problem -and- the program to support@robotc.net.

You're not the only one with this problem and the more people bug the developers to fix this, the higher it gets put on the priority list

- Xander

Thanks Xander, I will get an email off to them and hope the others seeing this issue do as well.