View unanswered posts | View active topics It is currently Fri Jul 25, 2014 11:11 pm






Reply to topic  [ 12 posts ] 
Bluetooth Stalling Motors. 
Author Message
Rookie

Joined: Tue Mar 11, 2008 7:33 am
Posts: 11
Post Bluetooth Stalling Motors.
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:
Code:
task readMessages()
{

   nxtDisplayTextLine(2, "Reading");
   static int nLastPosMsg = 0;
   static int nLastNegMsg = 0;
        time1[T1] = 0;
        joyDirection = 90;
        joyPower = 90;

   while (true)
   {
     nMessage = message;
     if (nMessage != 0)
     {
        //++nNearEndRead;// Keep a running count of the number of messages successfully read

        
        if (nMessage != (nLastPosMsg + 1)){
            ++nReadOutOfSequence;
             PlaySound(soundLowBuzz);
        }
        nLastPosMsg = nMessage;
        joyPowerBT  = messageParm[1];       //Get Power value
        joyDirectionBT  = messageParm[2];   //Get Direction value
        
        ClearMessage();
         nElapsedTime  = nPgmTime;
      }else{
        ++nRcxNoMsg;
                }
      nxtDisplayTextLine(6, "Power: %d", joyPower);
      
      if(time1[T1] > 3000){
         if(joyDirection == 270){
            joyDirection = 90;
         }else if(joyDirection == 90){
            joyDirection = 270;
         }
         time1[T1] = 0;
      }

      wait1Msec(1);
   }
}

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.

Code:
task sendMessages()
{
   const int kMinTimeBetweenMsg = 25;
   long nInterMsgTime;
   static long nLastSendTime = 0;

   while (true)
   {
      //
      // Delay between messages.
      //
      if ((nPgmTime - nLastSendTime) < kMinTimeBetweenMsg)
      {
         wait1Msec(6);
         continue;
      }

      if (bBTBusy)
      {
         ++nSendBusy;
         wait1Msec(5);
         continue;
      }

     ++nNearEndSent;
      ++nMsgXmit;
      if (nMsgXmit == 0)
         nMsgXmit = 1; // Don't send illegal value
     sendMessageWithParm(nMsgXmit, power, direction);
     nLastSendTime = nPgmTime;
   }
   return;
}


Thu May 22, 2008 8:10 am
Profile
Rookie

Joined: Tue Mar 11, 2008 7:33 am
Posts: 11
Post 
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


Sat May 24, 2008 7:21 pm
Profile
Expert
User avatar

Joined: Fri Nov 09, 2007 4:51 am
Posts: 121
Location: Hungary, Europe
Post motors
Can you quote the motor control parts of your program?


Mon May 26, 2008 5:29 am
Profile
Rookie

Joined: Tue Mar 11, 2008 7:33 am
Posts: 11
Post 
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. :)


Mon May 26, 2008 6:55 am
Profile
Rookie

Joined: Tue Mar 11, 2008 7:33 am
Posts: 11
Post 
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.


Wed Jul 16, 2008 3:46 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3163
Location: Rotterdam, The Netherlands
Post 
Surely a motor that is cut out on time is preferable to a brick that has lost its Magic Smoke?

Regards,
Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Wed Jul 16, 2008 6:26 am
Profile WWW
Rookie

Joined: Tue Mar 11, 2008 7:33 am
Posts: 11
Post 
Lol, afraid not. However... that did happen in a later incident... :roll:


Wed Jul 16, 2008 6:39 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 614
Post Re: Bluetooth Stalling Motors.
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".


Sun Aug 10, 2008 1:39 am
Profile
Rookie

Joined: Tue Mar 11, 2008 7:33 am
Posts: 11
Post Re: Bluetooth Stalling Motors.
Yup, I know his work well.
His website is my NXT-hack bible. :D


Sun Aug 10, 2008 4:16 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 614
Post Re: Bluetooth Stalling Motors.
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.


Tue Aug 12, 2008 11:55 am
Profile
Rookie

Joined: Tue Mar 11, 2008 7:33 am
Posts: 11
Post Re: Bluetooth Stalling Motors.
Nope, it's brand(-ish) new. :mrgreen:


Tue Aug 12, 2008 8:18 pm
Profile
Expert

Joined: Sun Sep 09, 2007 10:12 am
Posts: 116
Post Re: Bluetooth Stalling Motors.
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

_________________
http://www.apcsguarda.com
My Project: http://www.robotc.net/forums/viewtopic.php?f=15&t=712


Thu Sep 04, 2008 7:03 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 12 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.