ASCII commands makes ODrive unreachable

Zennix · July 8, 2018, 6:53pm

Hi all,
I try to connect the output of a simulator software to ODrive.
My setting is a 3.5 board with the latest devel branch. Connected is a KEDA motor with mounted AMT102.

The startup sequence is running fine and the motor resposes to the commands through a serial connection.
Everything looks good till this point.

This is the UI of the simulator software:

As you can see, the software sends a initial positioning command, waits for 1 second and starts to send positions every 50ms.
ODrive sets the motor to the initial position and after getting some of the commands, it stops responding.
hex(odrive0.axis0.error) shows nothing, the software hangs.

If you want to test this, use HTerm, it’s a pretty terminal programm for serial connections.
Make a file with just one command like: p 0 32000 0 0 (+CR)
In Hterm you can send this file coninuously.

grafik

As shorter the delay between the repetitions, as earlier ODrive hangs.

I don’t know how to debug the code with VS Code, setting stop points…
Maybe somebody can tell me what I can try to get this running.

Thanks / Zennix

Zennix · July 12, 2018, 6:24pm

Hi,

I clicked a little app together to get a better test. You need dot net 4.6.1 to run it.
https://drive.google.com/open?id=1kKuIi_Zo5Npc25uD6jVV-5sX5PyVmX6X

grafik

you can send your commands in defined intervalls and repetitions.

greetings / Zennix

Zennix · July 15, 2018, 6:37pm

Hi all,
after some more digging I found, that remarking the following block in ascii_protocoll.cpp solves the problem.

else if (cmd[0] == 'w') { // write property
        char name[MAX_LINE_LENGTH];
        char value[MAX_LINE_LENGTH];
        int numscan = sscanf(cmd, "w %" TO_STR(MAX_LINE_LENGTH) "s %" TO_STR(MAX_LINE_LENGTH) "s", name, value);
        if (numscan < 1) {
            respond(response_channel, use_checksum, "invalid command format");
        } else {
            Endpoint* endpoint = application_endpoints_->get_by_name(name, sizeof(name));
            if (!endpoint) {
                respond(response_channel, use_checksum, "invalid property");
            } else {
                bool success = endpoint->set_string(value, sizeof(value));
                if (!success)
                    respond(response_channel, use_checksum, "not implemented");
            }
        }

I know, that block shouldn’t be used, without sending a “w”. But that’s what I found. After remarking it, I was able to send thousands of commands with a distance of 10ms. I’m not really confirm in programming ST32, maybe somebody can tell me why that happens. Maybe the If else is to long and the serial receive interrupt fires before the routine is finished.

Greetings / Zennix

CFluck · July 16, 2018, 7:45am

Hi Zennix,

I think I may have the same problem as you do (explained here).
So I was wondering what you mean by “remarking” the block of code ? Did you suppress the “else if” so that this block is always called even when you don’t send “w”?
So I guess that if this is what you do, it means that you can only write property, but you can’t read anymore.

Thank you for your work!

Zennix · July 16, 2018, 9:42am

Hi CFluck,

looks like, we have the same problem. I commented out the hole block shown in my post, so everything is used but ‘w’.
I couldn’t test if removeing other unused parts of the function will fix it too.

Greetings Zennix

CFluck · July 16, 2018, 9:52am

Hi Zennix,

Thank you for answering!
did you also try to read out some parameters ? or did you just send position commands ?

Zennix · July 16, 2018, 11:12am

Hi CFluck,

sorry, no. My use case only sends position commands.

Greetings / Zennix

madcowswe · August 4, 2018, 8:45am

@Zennix I have made a github issue for this bug. Can you please keep your test probram available at that google drive link, and we will use it when we get to addressing this issue.

Thanks.

Zennix · August 4, 2018, 5:40pm

Hi,
sure, I will keep it available.

Greetings / Zennix

Stijn_Carelsbergh · March 21, 2019, 11:00pm

Hi zennix,

Is this problem still present? I’ve started to word on the program of my simulator. If the problem is still present, do I have do download the end stop branch, after that comment out the problem you mentioned and after that compile it and load it to the ODrives?

Thanks in advance

Cheers

Carelsbergh Stijn

Zennix · March 22, 2019, 11:31am

Hi Stijn,

There is no progress on this issue.

You are right. Get the end stop branch and comment out as described.

Greetings / Zennix

Stijn_Carelsbergh · March 22, 2019, 12:26pm

Hi

Thanks for the reply,

Can you tell me something about the command that you are sending true SimTools to the ODrive?

Is there a guide on how to compile the code and write it to the ODrive with the st-link?

Thanks

Cheers

Carelsbergh Stijn

Zennix · March 23, 2019, 8:18am

Hi Stijn,

depending which decoder you are using you have to find out, how many steps will be made for a full travel of your actuator. With this information you can set the output bit range.

With the endstop branch you can do a initial find zero run. After that, the actuators stops at position 0. Now my game-engine startup output sets the actuator to it’s middle position. In my case 262143.
Now Simtools send a position command every 20ms.
Stopping the game, sets the position of the actuators to middle position again.

Building the firmware with VSCode is described here: https://docs.odriverobotics.com/configuring-vscode.html
How to handle the ST-Link is shown here: https://docs.odriverobotics.com/odrivetool.html#device-firmware-update

Greetings / Zennix

Stijn_Carelsbergh · March 23, 2019, 8:23am

Hi

Thanks for the reply.

Can you tell me how you came up with the command p 0 262143 <13>p 1 2621143 <13>
Or is this something from the internet?

When you start up your system, do you first turn on your platform to do the encoder test and so on and after that start up the SimTools?

Cheers

Carelsbergh Stijn

Zennix · March 23, 2019, 8:32am

Hi Stijn,

p is the normal ASCII position command of ODrive. https://docs.odriverobotics.com/ascii-protocol.html
<13> is a carridge return ASCII sign to show ODrive the command is finished.

Yes I always start the sim before I start simtools.

Greetings / Zennix

Stijn_Carelsbergh · March 23, 2019, 8:39am

Hi

Thanks for the fast reply

And the 0 and 1 are the Axis?

Can you also answer this question?

Cheers

Carelsbergh Stijn

Zennix · March 23, 2019, 8:46am

Yes

p -> Position command
0 or 1 -> Axis
2621143 -> position
<13> -> ASCII return

Robin · May 7, 2019, 5:32pm

I’m still having trouble with serial ASCII commands. I’m using Simtools to send commands to the odrive. This works for a while, but suddenly the motors stop moving. I was able to reach the odrive through odrivetool and was also running a plot. Both showed no errors. odrv0.axis0.error was also 0x0000. I could still control the odrive with pos_setpoint. COM3 was still available in PuTTY, but the odrive didn’t respond to serial commands anymore.

Is there a way to debug the serial protocol? The serial buffer for example? I don’t see any relevant properties I could watch in odrivetool.

EDIT: After unplugging and reconnecting the usb cable, the serial connection worked again.
Still looking for the problem and solution…

Robin · May 8, 2019, 9:21am

I think I found the problem. It seems that the driver, usbser.sys, that is being used for usb-serial communication is unreliable. That’s why reconnecting usb solves the problem.

Can anyone confirm that?

I’m going to try to use a Teensy 3.2 as usb->serial->step/dir interface. Because I might combine the odrives with other servo drives in the future, I can keep using the step/dir interface.

Wetmelon · May 8, 2019, 8:21pm

Can you give us any info about that?

usbsys.ser on Windows 10? USB 2.0? I don’t really know what’s relevant here.