Results 1 to 6 of 6

Thread: Strange behavior of OpenCM9.04

  1. #1

    Strange behavior of OpenCM9.04

    Background of project: I put together a PhantomX turret and have an OpenCM9.04 B attached to control it. The 9.04 receives serial commands over hardware UART serial3 via a connected XBEE series 1 radio. The 9.04, the AX-12As, and the XBEE are powered through the +- inputs of board using a 3S lipo battery. I have a home built XBEE transceiver that sends commands compatible with the Commander library, which is modified to work on the 9.04 serial3. I have used this XBEE TX/RX solution before for other (hobby servo) pan/tilt turrets and robot control with (and without) the Commander library with great success. This is my first time using Dynamixel servos and the OpenCM9.04 and OpenCM IDE.

    Description of problem: The problem is very strange (to me at least) so I will be careful to precisely explain its manifestation. I wrote some simple code to test out the system and I usually do in situations when testing RX/TX code I had the serial commands being received by 9.04 being printed to the serial monitor for debugging. The code worked just fine however only under the following circumstances:

    A.
    1. Plug 9.04 into USB
    2. Switch external 3S supply ON (The switch is the one on the bottom of 9.04 and the battery is a freshly charged to 12V, good quality lipo)

    B.
    1. Plug 9.04 into USB
    2. Switch external 3S supply ON
    3. Unplug 9.04 from USB

    The system will not work under these circumstances:

    C.
    1. (Only) switch external 3S supply ON

    D.
    1. Switch external 3S supply ON
    2. Plug 9.04 into USB

    Attempts at debugging: I have 2 USB cable I previously modified, one to supply on power with the data lines cut, and the other with the +5V line cut. I experimented by first connecting the power only USB cable to 9.04 and supplying it with +5V then switching on external 3S supply. Result: system works fine. It also works fine in I supply +5V, switch on 3S, and immediately turn off +5V. To be thorough I also tested the signal only USB cable and the system didn’t work but I could see the serial commands coming it successfully on serial monitor.

    So really I am not sure if this is a hardware or software problem. Both of the voltage regulators on the 9.04 are rated for 800 mA so I don’t think it could be a brown out problem. I also checked all the voltages around the board with DMM during the testing as well and didn’t notice anything peculiar.

    Code:
    Code:
    /*
    First test of modified Commander library with pan/tilt turret
    using writeWord method
    
    Only works if the CM is initially connected to (PC through) the USB?
    */
    #include <Commander.h>
    //Create Commander object to handle incoming messages
    Commander command = Commander();
    
    //Create Dynamixel object for servo control
    #define DXL_BUS_SERIAL1 1
    Dynamixel Dxl(DXL_BUS_SERIAL1);
    
    //Define all the constants and global variables
    #define PAN 1
    #define TILT 2
    
    #define GOAL_POSITION_ADDRESS 30
    #define GOAL_SPEED 32
    
    //Define the midpoints and noise level for the incoming joystick
    //signals in x (pan) and y (tilt)
    #define PAN_MIDPOINT 0
    #define TILT_MIDPOINT 0
    #define NOISE 15
    
    //Define the start position/last position for each servo
    int P_LAST_POSITION = 512;
    int T_LAST_POSITION = 512;
    //Also define the max and min values to move servos
    #define MAX 1023
    #define MIN 0
    
    
    void setup() {
      //For debugging
      //SerialUSB.begin();
      //Initialize RX and servo objects
      Dxl.begin(3);
      command.begin(38400);
      //Wait a bit for things to settle
      delay(500);
      
      //Set servos to center positions
      Dxl.goalSpeed(PAN, 1024);
      Dxl.goalSpeed(TILT, 1024);
      Dxl.jointMode(PAN);
      Dxl.jointMode(TILT);
      Dxl.writeWord(PAN, GOAL_POSITION_ADDRESS, P_LAST_POSITION);
      Dxl.writeWord(TILT, GOAL_POSITION_ADDRESS, T_LAST_POSITION);
    
    }
    
    void loop() {
      //If there's a command available
      if(command.ReadMsgs() > 0){
        //Check if the pan is greater than zero and outside noise
        //threshold
        if ((command.walkV - NOISE) > 0){
          //Turn the servo CCW
          if (P_LAST_POSITION < MAX){
            //Update the last position
            //SerialUSB.print("Current PAN position ");
            //SerialUSB.println(P_LAST_POSITION);
            //SerialUSB.print("Moving PAN to ");
            P_LAST_POSITION = P_LAST_POSITION + map(command.walkV, NOISE, 128, 1, 5);
            //SerialUSB.println(P_LAST_POSITION);
            //Turn proportional to joystick value
            Dxl.writeWord(PAN, GOAL_POSITION_ADDRESS, P_LAST_POSITION);
          }
        }
        //Or if it's less than zero and outside threshold
        else if ((command.walkV + NOISE) < 0){
          if (P_LAST_POSITION > MIN){
            //SerialUSB.print("Current PAN position ");
            //SerialUSB.println(P_LAST_POSITION);
            //SerialUSB.print("Moving PAN to ");
            P_LAST_POSITION = P_LAST_POSITION + map(command.walkV, -128, -NOISE, -5, -1);
            //SerialUSB.println(P_LAST_POSITION);
            //Turn proportional to joystick value
            Dxl.writeWord(PAN, GOAL_POSITION_ADDRESS, P_LAST_POSITION);
          }
        }
        //Likwise for the tilt
        if ((command.walkH - NOISE) > 0){
          if (T_LAST_POSITION < MAX){
            //Update the last position
            //SerialUSB.print("Current TILT position ");
            //SerialUSB.println(T_LAST_POSITION);
            //SerialUSB.print("Moving TILT to ");
            T_LAST_POSITION = T_LAST_POSITION + map(command.walkH, NOISE, 128, 1, 5);
            //SerialUSB.println(T_LAST_POSITION);
            //Turn proportional to joystick value
            Dxl.writeWord(TILT, GOAL_POSITION_ADDRESS, T_LAST_POSITION);
          }
        }
        else if ((command.walkH + NOISE) < 0){
          if (T_LAST_POSITION > MIN){
            //SerialUSB.print("Current TILT position ");
            //SerialUSB.println(T_LAST_POSITION);
            //SerialUSB.print("Moving TILT to ");
            T_LAST_POSITION = T_LAST_POSITION + map(command.walkH, -128, -NOISE, -5, -1);
            //SerialUSB.println(T_LAST_POSITION);
            //Turn proportional to joystick value
            Dxl.writeWord(TILT, GOAL_POSITION_ADDRESS, T_LAST_POSITION);
            
          }
        }
      }
    }
    I should also say that I tried all the basic example sketches in IDE for Dynamixels and they worked fine. Maybe implies a software problem? Like I said I am new to controlling Dynamixels.

    Any help would be greatly appreciated!

    Thanks in advance,
    Gabe

  2. #2

    Re: Strange behavior of OpenCM9.04

    Okay, I found the problem. I removed the following portions of code:
    Code:
    Dxl.goalSpeed(PAN, 1024);
        Dxl.goalSpeed(TILT, 1024);
        Dxl.jointMode(PAN);
        Dxl.jointMode(TILT);
    Everything now work fine. I'm still not sure why the addition of these commands would cause the observed behavior. I would still appreciate any advice about this problem or suggestion for improvement.

    Thanks

  3. #3
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,299
    Images
    27
    Rep Power
    278

    Re: Strange behavior of OpenCM9.04

    1024 is an invalid speed value for joint mode, and is CCW at speed of zero for wheel mode (bit 10 is direction, bits 0~9 are speed; so, 0~1023 are valid speeds). I also seem to remember the jointMode() function not working correctly, but that may just be glitchy memory.

    Something about the problem you described seems very, very familiar, but not sure if it was OpenCM related (might have been SerialUSB initialization hanging if not connected at powerup?). I know mixing USB and AC-DC power supplies can cause the USB to re-enumerate when first connected together because of differing ground potentials (had that issue a lot when debugging OpenCM/CM-530/USB2Dynamixel with an SMPS and no power switch connecting the SMPS to the dynamixel bus), but should not happen with a battery or SMPS connected through the OpenCM power switch.
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    bleh
    more bleh

  4. #4

    Re: Strange behavior of OpenCM9.04

    Ah, thank you for the insight Tician and for clarifying the proper usage of setting goal speed in joint mode. I just found the documentation as well on the Robotis site.

    I did consider that the SerialUSB might have been a problem and I had tried the code without initializing it but the problem was still present. Maybe the characteristics of the on board switch cause excessive bouncing during the initialization? For curiosity I am going to try using a Pololu power switch (which has good debouncing) between battery and the 9.04 and will just leave board switch closed.

    Now that you mention it I think I read about a similar problem on the PJRC forum with regards to the Teensy platform. And I think it did have to do with differing ground references. I will try to find it.

    Thanks again for the help!

  5. #5
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,299
    Images
    27
    Rep Power
    278

    Re: Strange behavior of OpenCM9.04

    With the switch connecting only the positive side of the SMPS/battery, there should be no difference between grounds to cause the USB device to reset/disconnect and re-enumerate except during the initial connection of the USB and battery/SMPS cables.

    There is a P-MOSFET connecting the 5V regulator and USB5V, so that the USB can be powered by the 5V regulator through the internal diode and the USB will power the 5V bus (supplement/replace the 5V regulator on VBAT) after VBAT drops below ~6.6V (an LMV321 op-amp turns the P-MOSFET on to connect USB5V direct to 5V bus). Maybe some sort of brown-out when everything tries to power up simultaneously (dynamixels and OpenCM) and/or sketchy switching properties of the rather cheap switch? There is no on-board voltage sensing of the battery, so the STM32 of the OpenCM is completely oblivious to what is actually powering it. There is also plenty in the inherited USB software that could be causing issues since much of it is always initialized even when SerialUSB is not utilized in the sketch.
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    bleh
    more bleh

  6. #6

    Re: Strange behavior of OpenCM9.04

    I've had really bad experience with SerialUSB. Specifically, if you write too much at once, or if you try to write more than a little bit when there is no USB connection, will hang the board.
    What I do now is to send a byte from the host computer, and not write to the SerialUSB device until I've received that byte.
    Additionally, I only send up to X bytes (I think 32?) per byte I receive, and send bytes from the host one at a time at some reasonable pace. That way, I know that too much data will not build up in the USB buffer.

    I *think* the reason for this is that the USB buffer ends up waiting for something that never happens if it overflows the maximum USB endpoint packet size before draining what's been sent, but I haven't had the time to actually fix it in the original Maple code...

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Dynamixel AX12A Strange problem
    By richardw347 in forum DYNAMIXEL & Robot Actuators
    Replies: 4
    Last Post: 01-15-2014, 09:31 AM
  2. Phoenix code...strange effect...
    By KingPin in forum Humanoids, Walkers & Crawlers
    Replies: 13
    Last Post: 03-04-2013, 04:30 PM
  3. Question(s) Behavior control program question
    By Dmonious in forum Software and Programming
    Replies: 4
    Last Post: 07-16-2008, 03:04 PM
  4. Sexed Robots - Strange... yet interesting project
    By Alex in forum Robotics General Discussion
    Replies: 0
    Last Post: 10-01-2007, 10:40 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •