Hey everyone!
I'm currently working on a robot with Omni-directional wheels, and I've had it working fine by just writing in the program to go at a certain power in a certain direction, and it will do that with no problems.
Just recently, I made a Philo-style joystick that calculates the direction to travel and speed depending on the angle and amount I move the joystick. I figured out how to send this via bluetooth. (The bluetooth is a 2nd task on each NXT brick, continuously sending over the data to global variables.)
When I first tilt the joystick, it works very nicely and moves in the desired direction, etc. But then if I move it back into a different direction, it will sort of stall. It jerks in the direction for a moment and then the motors stop, then jerks again, then stops; repeating. The weird thing is, is that the motors go perfectly if I lift it off the ground, then as soon as I add pressure to the wheels by replacing it on the ground, or holding the wheels with my hand, all power from them disappears, then returns about a second later.

I did some further testing, to try and target the source of the problem. First, I replaced the actual bluetooth coding in the bluetooth task with a simple while loop that changed the direction from Forwards to Backwards every 3 seconds; to see if it was an issue with double tasks. No problem there, it moved forward 3 seconds, then back 3 seconds. No stalling.
I then set up the bluetooth tasks again, and put the same while loop into the joystick NXT. So that it simply changed the direction forwards and back each 3 seconds as before. The robot starts off fine, but then continues to stall as soon as it first changes direction.
So, the last test I've done, is to put that looping program BACK into the bluetooth-read task on the main robot, but I kept the bluetooth code, so that the bluetooth functions were still running, but were not updating any of the important values. It stalled.

So all I conclude from this is that the act of send-receiving bluetooth messages is somehow causing the motors to stall if they are under enough resistance... It's also worth noting that when it's stalling, and push in the right direction will keep it going okay until it changes its direction again.

I know it's an awkward problem, but I hope someone might know the cause behind this.

Cheers!
-Kit

Bluetooth send-receive tasks:

The joyDirectionBT and joyPowerBT are variables I've just set up to store the receive values. The joyDirection and joyPower are the ones that affect the motors.

Update:
It seems that I was mistaken before when I thought it worked fine when the bluetooth task was not running.
But that's not the case, it still continues to stall even if I have nothing related to bluetooth in the code.
Why could it be doing this? Is there a built-in function that stops the motors if they are under too much force?

Thank you,
-Kit

Can you quote the motor control parts of your program?

Thank you for your interest. But I've made the decision to use doubled-up RCX motors for the robot now. It's for a Robocup Soccer competition and time is running away from us. So we've just had to bite the bullet and change though.
For anyone experiencing similar problems, I've deduced that it's a built in function that removes all power from the motors if too much force is applied against them when they are running at higher voltages. I should also note that I had the voltage running at about 10-11V, which was probably overwhelming the motors.
@elemes; I made a basic "motor[motorA] = 100;" program. If I held onto the wheel it would suddenly go "limp" and then try to go again after a second, then go limp again if I still had pressure on it.
In the end, all is/will be well.

Ok, well, my mistake.
It wasn't the bluetooth in the end.
It was that the current that the NXT motors were pulling was higher than what the NXT can handle, and so they just cut out momentarily.
Which... is a bit stupid. Seeing as the motors are made and designed for the kit.
So I'm using RCX motors now. Just in case anybody is/was having the same problem.

Surely a motor that is cut out on time is preferable to a brick that has lost its Magic Smoke?

Regards,
Xander

Lol, afraid not. However... that did happen in a later incident...

I believe there are also thermal cut-off devices integrated into the motors. A stalled motor will heat up reasonably fast and I think there's a temperature based cutoff device in the motors.

I may be wrong on this. Philo's web site is likely to have the definitive answer. Philo is the acknowledged world-wide leader in all things about LEGO motors. I think the web site www.philohome.com. Do a google on "philo lego motors".

Yup, I know his work well.
His website is my NXT-hack bible.

I have never run into problems with the NXT motors cutting out with heavy current drain. Not being the h/w designer, I can only speculate, but I would have thought that the "H-Bridge" electronics used to control the motors should have handled everything but a stall current.

Are you perhaps using a very old NXT; specifically a pre-production model that was distributed to one of the 100 Beta trial users? One of the last hardware changes made for the production models was to beef up the H-Bridge drive capability. NOTE: if your NXT is a new purchase, then you don't have to worry about this; none of the pre-production models were every sold.

Nope, it's brand(-ish) new.

With the new code of RS485 by ogait, you could link them on RS485, and would be faster and better to use...

see it on:

http://www.robotc.net/forums/viewtopic.php?f=1&t=697&p=3092#p3092