Tested release v1.0.0 and result is jerky

[CquoTahi]

Hi,

I have just purchased a Dobot and really upset with the way they actually implement.

I have flashed v1.0.0, but during running example_sdk.py is not smooth. The transition is extremely jerky.

My set up:
Python 2.7 from the page you recommended (I never use python before, You can also consider me as noob in python)

Dobot hardware v1.1

I suspect the Python calculation is slow and communication with dobot is not fast enough Or my set up with Python is not correct.

Will it help If I move to Cpython?
Does this compatible with Cpython?

Thanks and Looking forward to your answer.

[maxosprojects]

1. What do you mean by "transition"?
2. What is the configuration of the machine you are running example on? What is the OS it is being run on?
3. Is it jerky from the very beginning?

Unless your machine is extremely slow calculations shouldn't be a problem. There is substantial amount of text being printed by default because debugging is on in all examples by default for curious people. You can disable debugging by setting debug=False (or just remove the debug argument) when instantiating SDK:

dobot = Dobot('whatever-serial-interface-is-in-your-system', debug=False)

Try that and let me know if that helped.

I will also try to execute it on a Rapsberry Pi 2 - probably the slowest possible machine open-dobot can be run on, to confirm that the computation cannot be a problem.

What can be a problem is the communication with dobot or a bug in firmware, though a bug is not likely at this point as it has been extensively tested.

The baud rate is set to 115200 which is more than enough to send couple of commands in one execution window (20ms). Unless there an error happens (because of noise, for instance) while transferring the data via the serial interface (USB that on Arduino side is converted to regular 2-line serial) the commands must be correctly queued. Once queued they are just executed. In case of errors commands are retransmitted but the queue is not filled and on the next execution window dobot is stopped, then one command goes through and it is stopped again.

I can see communication being poor or "Arduino" performing poorly as the board that they claimed being Arduino is not really Arduino, but is just a cheap clone.

There also might be something different in board v1.1 hardware/fpga firmware leading to this, but that I won't be able to find or confirm as I only have board v1.0. So let's start troubleshooting with simple cases.

[maxosprojects]

Just verified on Raspberry Pi 2 - runs perfectly.

Can you also shoot a video and post it somewhere to make sure the arm is initialized in the right pose (about 45 degrees for both arms) and how the jerky behavior looks like in the case of your dobot?

[CquoTahi]

Thanks for your respond.

https://www.dropbox.com/s/s6xrzjs6xm1111s/IMG_7364.MOV?dl=0

you can see the clip about the transition is not smooth. This clip was captured during running example_driver.py.

I tested on2 PCs: 1 is my core i5 laptop windows 7, and another is quad core i7 window 7. Both had the same phenomenons.
I also tried with Debug=False.

From my understanding, there could be 2 case:
1)Ardunio is clone not good and cause UART communication is not smooth?
2)FPGA EEPROM change from dobot v1.1 compare to v1.0.

First I will check the UART communication by replace it with a original Arduino.

[maxosprojects]

No need to replace the board. You can check whether the communication is the problem with the following code. Just replace example-driver.py with this code:

from DobotDriver import DobotDriver
import time
import sys

driver = DobotDriver('COM4')
driver.Open()
successes = 0
i = 0
while True:
    ret = driver.isReady()
    if ret[0] and ret[1]:
        successes += 1
    if successes > 10:
        print("Dobot ready!")
        break
    if i > 100:
        raise Exception('Comm problem')

gripper = 480
toolRotation = 0

freq = [
       0,
      50,
     250,
     400,
     600,
     800,
     950,
    1150,
    1300,
    1450,
    1500,
    1800
]

def execute(keys1, keys2, keys3, direction1, direction2, direction3):
    for key1, key2, key3 in zip(keys1, keys2, keys3):
        code1 = driver.freqToCmdVal(key1)
        code2 = driver.freqToCmdVal(key2)
        code3 = driver.freqToCmdVal(key3)
        for i in range(0, 4):
            ret = (1, 0)
            # Check for return from Arduino to make sure the command was queued.
            # See function desciption for more details.
            while not ret[1]:
                ret = driver.Steps(code1, code2, code3, direction1, direction2, direction3, gripper, toolRotation)
                sys.stdout.write(str(ret[0]))
                sys.stdout.flush()

increasing = freq
decreasing = sorted(freq, reverse=True)
execute(increasing, [], increasing, 0, 0, 0)
while True:
    execute(decreasing, increasing, decreasing, 0, 0, 0)
    execute(increasing, decreasing, increasing, 1, 0, 1)
    execute(decreasing, increasing, decreasing, 1, 1, 1)
    execute(increasing, decreasing, increasing, 0, 1, 0)

Replace COM4 with whatever port dobot shows up on your system.

This code will print out 1 when command was successfully delivered to Arduino, or 0 when there was a comm error. So if there is at least one 0 then Arduino is most probably the problem.

[CquoTahi]

I tested with your example, replaced:
sys.stdout.write(str(ret[0])) with print(str(ret[0]))

Result as below, seem I have to replace with Original Arduino Mega.
Dobot ready! 0 0 1 1 1 1 0 1 1 0 1 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 0 1 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 0 1 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 0 1 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 1 1 1

[maxosprojects]

Although #23 confirms that v1.1 is not jerky, it is still not 100% that your Arduino is the problem, but it would be quite hard to try to confirm that.
There can't be too many Arduinos anyway, so go ahead and try another one :)

[CquoTahi]

Updated:
-Windows 7 Pro & Original Arduino -> Issue still remain.
-PI version 1 & clone Arduino from Dobot -> Issue improved but still Jerky.
-linux on the same PC & clone Arduino from Dobot -> Issue is fixed, dobot movement is smooth.

Conclusion: There could be some issue with Windows 7 set up I have. Result in UART communication is not right.

[CquoTahi]

Forgot to thanks, Thanks Max for your response.

[maxosprojects]

NP

I was able to reproduce the issue using a Windows 7 32-bit VM (VirtualBox https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/mac/) with Python 3.5

The issue on that particular VM is with pyserial being unreasonably slow. Unreasonably because CoolTerm sends data pretty fast - one byte every 2.3 milliseconds via pyserial vs. 84 microseconds via CoolTerm (40x).
That problem also revealed a problem with the firmware that does not manifest under normal conditions.

Under certain conditions the timing is such that SPI commands are skipped leading to the arm to stop in between commands. That manifests as jerky behavior.

The fix for the firmware has been just pushed to master.

Could you please test it https://github.com/maxosprojects/open-dobot/releases/tag/1.1.0 on Raspberry Pi?

Will be looking for a fix for pyserial on Windows. There is a chance you faced the same problem on Raspberry Pi because of pyserial too.

BTW, which Windows version are you using (32 or 64 bit), and which Raspberry Pi (Model A, B or B+)?