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

[MousKitos]

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.

[drachels]

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.

[MousKitos]

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

[KurtEck]

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:

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

[KurtEck]

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.

[drachels]

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.

[drachels]

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

[drachels]

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.

[KurtEck]

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.