Results 1 to 9 of 9

Thread: Arbotix Pro erratic after apt-get update & upgrade on my RPI3

  1. #1

    Angry Arbotix Pro erratic after apt-get update & upgrade on my RPI3

    My basic image on my RPI3 is hros1-v3-rasbian-jessie-12-09-16.img

    All communications are good ( dxl_monitor in reference )

    But after one apt-get update and upgrade ( classical with RPI, I do often on alls of mine, other applications )

    After one long upgrade, all communications will be erratic with the Arbotix Pro ( many fails )

    So alls communications are unusable, and all my projects are unusables too..

    Surely you have also encountered this problem. But I do not know, what "good" update causes, this slowdown on the USB port, which ultimately causes problems.

    I (We) need uninstall something who make the trouble, But I do not know which one

    An Idea ?

    Thanks for your help.

  2. #2
    Join Date
    Sep 2015
    Location
    Enterprise, AL
    Posts
    54
    Images
    4
    Rep Power
    20

    Re: Arbotix Pro erratic after apt-get update & upgrade on my RPI3

    Hi MouseKitos,

    I realize this is right at 3 years late, but based on my recent trials and tribulations with trying to get a Pi4 to work with an Arbotix Pro, I would venture a guess that your problem is due to the new compiler that is included in Jessie during the slightly greater than one year that has elapsed since your image was created.

    Over the past few days, I have used the same v3 image and it works on a Pi3, as long as I do NOT do any upgrades. As soon as I upgrade, my Framework breaks. Next thing I need to try is using that image in my Pi4, but I'm not sure if I'll be able to get it running without any upgrades.

    Since my Pi4 is very noticeably faster than a Pi3, I would love to get the Framework working on it with the latest Pi OS, but since the code in JROS1-Framework is so "poorly" documented, my progress is very slow. It would have really helped if the original programmers had include comments in the code. It has been my experience that many programmers seem NOT to know that a compiler skips over comments.

  3. #3

    Re: Arbotix Pro erratic after apt-get update & upgrade on my RPI3

    In fact, my HR-OS1 don't move since 2 years ( Too busy by other things..)
    Maybe, one day, I will start with one fresh "empty" image, copy all sources and recompile all to see if it's work

    If you do that, please advise us if it's work

  4. #4

    Re: Arbotix Pro erratic after apt-get update & upgrade on my RPI3

    Sorry my HROS1 has been sitting in dust for several years now. Probably not likely to be resurrected anytime soon.

    But back then I know I had played with a few different processors, like Edison and RPI3 and I believe an ODroid.

    If it were me now, probably the first place I would look at is the file fuild\LinuxArbotixPro.cpp,

    Probalby in the function: bool LinuxArbotixPro::OpenPort()

    It is trying to set the baud rate to 1mbs, which is a non-standard baudrate. It has been a long while since I looked at this, but the usages of tcsetattr may work differently depending on processor especially for non-standard settings. I know I ran into this before, but don't remember what the differences were.

    If I look at my also old Raspberry Pi project that I have played around with different Linux boards where I had ports of the Hexapod code base and the like:.

    Looking in that code base where I am trying to open up a serial port at some baud rate I do see I have a couple different ways:
    Code:
    int dxl_hal_open(int deviceIndex, float baudrate)
    {
        struct termios newtio;
        struct serial_struct serinfo;
        char dev_name[20] = "/dev/ttyDXL";
        uint32_t int_baud = baudrate;
    
    #ifdef DEBUG_WIRINGPI
        wiringPiSetup () ;
        pinMode (WPD_WRITE_PIN, OUTPUT) ;
        pinMode (WPD_READ_PIN, OUTPUT) ;
        pinMode (WPD_READ_DATA_PIN, OUTPUT) ;
        pinMode (WPD_FLUSH_PIN, OUTPUT) ;
        pinMode (WPD_CLEAR_PIN, OUTPUT) ;
    
    #endif
        // Build in support to explit device - /dev/ttyDXL
        dxl_hal_close();    // Make sure any previous handle is closed
        
        if((gSocket_fd = open(dev_name, O_RDWR|O_NOCTTY|O_NONBLOCK)) < 0) {
            // We did not find our explicit one, lets try the standard default USB2AX file name
            sprintf(dev_name, "/dev/ttyACM%d", deviceIndex); // USB2AX is ttyACM
            
            if((gSocket_fd = open(dev_name, O_RDWR|O_NOCTTY|O_NONBLOCK)) < 0) {
                fprintf(stderr, "device open error: %s\n", dev_name);
                
                // Lets also try ttyUSBx to see if we have different board...
                sprintf(dev_name, "/dev/ttyUSB%d", deviceIndex); // USB2AX is ttyACM
                if((gSocket_fd = open(dev_name, O_RDWR|O_NOCTTY|O_NONBLOCK)) < 0) {
                    fprintf(stderr, "device open error: %s\n", dev_name);
                    goto DXL_HAL_OPEN_ERROR;
                }
                g_use_tcdrain = 1;    // FTDI device use tc Drain.
            }
        } else {
            // DXL found see if FTDI as to know if we should use drain.
            char szProcFD[20];
            char szPath[30];
            int ich;
            sprintf(szProcFD, "/proc/self/fd/%d", gSocket_fd);
            ich = readlink(szProcFD, szPath, sizeof(szPath));
                
            // Hack look for /dev/ttyUSB... actuall only look at USB    
            if ((ich > 0) && (szPath[8]=='U') && (szPath[9]=='S')&& (szPath[10]=='B'))    
                g_use_tcdrain = 1;        // FTDI use drain...
            else    
                g_use_tcdrain = 0;        // Others ACM S2.. Don't appear to.
        }
    
        if(gSocket_fd == -1)
            return 0;
    
        
        gfByteTransTime = (float)((1000.0f / baudrate) * 12.0f);
        
        memset(&newtio, 0, sizeof(newtio));
        // First try to set the baud rate directly.
        switch (int_baud) {
            case 4000000:
                newtio.c_cflag        = B4000000|CS8|CLOCAL|CREAD;
                break;
            case 3500000:
                newtio.c_cflag        = B3500000|CS8|CLOCAL|CREAD;
                break;
            case 3000000:
                newtio.c_cflag        = B3000000|CS8|CLOCAL|CREAD;
                break;
            case 2500000:
                newtio.c_cflag        = B2500000|CS8|CLOCAL|CREAD;
                break;
            case 2000000:
                newtio.c_cflag        = B2000000|CS8|CLOCAL|CREAD;
                break;
            default:
                newtio.c_cflag        = B1000000|CS8|CLOCAL|CREAD;
                break;
        }
        newtio.c_iflag        = IGNPAR;
        newtio.c_oflag        = 0;
        newtio.c_lflag        = 0;
        newtio.c_cc[VTIME]    = 0;    // time-out ? (TIME * 0.1?) 0 : disable
        newtio.c_cc[VMIN]    = 0;    // MIN ? read ? return ?? ?? ?? ?? ??
    
        tcflush(gSocket_fd, TCIFLUSH);
        
        if (tcsetattr(gSocket_fd, TCSANOW, &newtio) < 0) {
            printf("tcsetattr 1000000 failed try indirect %d\n\r", errno);
    
            // Try doing it indirect by setting to 38400 and
            // see if the USB driver supports setting non-standard
                    // Try back at 38400 and setting attribute...
            newtio.c_cflag      = B38400|CS8|CLOCAL|CREAD;
            if (tcsetattr(gSocket_fd, TCSANOW, &newtio) < 0) {
                printf("tcsetattr failed %d\n\r", errno);
                goto DXL_HAL_OPEN_ERROR;
            }    
            
            // Get the settings...
            if (ioctl(gSocket_fd, TIOCGSERIAL, &serinfo) < 0) {
                printf("TIOCGSERIAL failed %d\n\r", errno);
                goto DXL_HAL_OPEN_ERROR;
            }
            
            serinfo.flags &= ~ASYNC_SPD_MASK;
            serinfo.flags |= ASYNC_SPD_CUST;
            serinfo.custom_divisor = serinfo.baud_base / baudrate;
                
            if(ioctl(gSocket_fd, TIOCSSERIAL, &serinfo) < 0) {
                printf("TIOCSSERIAL failed %d\n\r", errno);
                goto DXL_HAL_OPEN_ERROR;
            }    
        }
        
        return 1;
    
    DXL_HAL_OPEN_ERROR:
        dxl_hal_close();
        return 0;
    }
    Again this is in my "Raspberry_Pi" project up on github.

    With this version my code first tries to directly set the Serial port to 1mbs and only if this fails does it try the indirect approach of 38400 and setting different speed... Maybe now you can simply go direct with the newer compilers.

    Good luck

  5. #5

    Re: Arbotix Pro erratic after apt-get update & upgrade on my RPI3

    Forgot to mention a few more things, that if it were me, I would be checking.

    I believe the Arbotix Pro uses an FTDI chip to communicate over USB...

    So I would make sure you have an FTDI driver installed, and not sure if there needs to be any updates or the like to udev rules or not.

    Maybe? Or maybe you need to make sure dialout and the like are in the groups for which user you are using.

    Also again it has been forever since I played with the HROS1 (probably 5 years). So I don't remember how robust the Dynamixel library code was and specifically how timing sensitive it is.

    Things like: how much code you have that may be like:
    < Send out a dynamixel request> from RPI to Arbotix Pro
    Wait for time N for a response to com back.

    FTDI may have longer delays than others. So most of my code that does things like that:
    When I send out the DXL packet, make sure the packet is sent before I start my timeout.
    This is sort of equivalent to on Arduino doing something like: Serial.flush();

    Now on Linux: you might do something like tcdrain() to do that. Which the FTDI driver actually has support for and knows when the last bits have been sent by the FTDI chip...

    But in the above code I showed, I check for FTDI and only do the drain when it is FTDI. As I found with some other Serial types, like /dev/ttyACM0 I don't think the driver has native code for the underlying IOCTL but instead just puts in a very long pause, assuming that the stuff will shift out in that time frame.

  6. #6
    Join Date
    Sep 2015
    Location
    Enterprise, AL
    Posts
    54
    Images
    4
    Rep Power
    20

    Re: Arbotix Pro erratic after apt-get update & upgrade on my RPI3

    I sympathize. Mine has sat untouched for almost five years. If you get the last, hros1-v3-rasbian-jessie-12-09-16.zip, image, and use it on a Pi3, it will compile and work as long as you DO NOT upgrade the Pi OS. I have not tried it in my Pi4 yet. Too busy with other things.

    The reason I say not to upgrade is because you will wind up with a newer version of the compiler, which produces a bunch of errors and a boatload of warnings when you run make on the Framework. It will partially run if you fix the errors, but in may case, I am not even sure that the way I have fixed the errors is actually correct.

  7. #7
    Join Date
    Sep 2015
    Location
    Enterprise, AL
    Posts
    54
    Images
    4
    Rep Power
    20

    Re: Arbotix Pro erratic after apt-get update & upgrade on my RPI3

    Hi Kurt, In what little spare time I have, I have started to try and dig through your stuff on github.

  8. #8
    Join Date
    Sep 2015
    Location
    Enterprise, AL
    Posts
    54
    Images
    4
    Rep Power
    20

    Re: Arbotix Pro erratic after apt-get update & upgrade on my RPI3

    As an experiment, I have placed the latest Raspbian OS on my Pi4 and tried to compile the HROS1-Framework. It fails. I fix the errors and it partially works for only one servo, even though multiple servos are connected.

    I then checked to see which compiler was installed and found that it was g++8. I did the same check on my working Pi3 and found that it was using g++5. I then installed g++5, 6, and 7 on my Pi4. The g++5 compiles the original HROS1-Framework without errors, but the resulting code has the same problem as the code generated by g++8. That is it only runs one servo no matter how many are connected and it also do not retrieve any data from the servos.

    When I get the chance, I guess my next step is to try and get some of the code Kurt has on his github account to work on the Pi4, most notably his AX12_Test.

  9. #9

    Re: Arbotix Pro erratic after apt-get update & upgrade on my RPI3

    Note: about 5 years ago, I was experimenting with controlling the Arbotix Pro using a serial port instead of USB.... Why on one AP the USB connector tore off and took the etch for the port with it...

    At the time I was experimenting also running it at 1mbs or 2MBS...
    I had code in place (fork/branch) that would first try to connect using B1000000 directly instead of B38000 and secondary setting...

    Code was up at: https://github.com/KurtE/HROS1-Frame...tixPro.cpp#L97

    It looks like there is code in place in the framework to call tcdrain so that should work.

    Other things maybe to look at are timing related. Don't remember if the framework was using any timing APIS that are being depreciated.

    But again those are the two places I would start looking at, if it were me.

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. Interesting RPI3 with the HROS1-Framework.
    By LloydF in forum HR-OS1 Development and Discussion
    Replies: 6
    Last Post: 12-09-2016, 01:58 AM
  2. Arbotix - Update Hardware Serial to capabilities of Arduino 1.0.5 capabilities.
    By KurtEck in forum Arbotix, Microcontrollers, Arduino
    Replies: 4
    Last Post: 04-09-2014, 11:31 AM
  3. Replies: 4
    Last Post: 04-09-2014, 11:31 AM
  4. XV-11 firmware upgrade!
    By Chunk in forum Robotics General Discussion
    Replies: 15
    Last Post: 09-29-2012, 02:41 PM
  5. 1HV Upgrade Kit coming soon!
    By Droid Works in forum Humanoids, Walkers & Crawlers
    Replies: 10
    Last Post: 07-20-2008, 11:00 PM

Posting Permissions

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