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+)?

[CquoTahi]

Ok I will check v1.1.0 on my PI set up.

During the issue I tested on: Windows 7 Pro 64bit PI model B (Single core version).

Side information:During testing on Pi in pure console mode (no GUI), the UART result is all ok (all is 11111111111111111 no 0 observed). Jerky could be from the Pi execution is not fast enough (single core) and cause Arduino to wait for command too long and stall other activies like pumping movement command.

If I let PI send command continuously for 1-2 mins then interrupt the example_driver script. Observation is Dobot movement is smooth at the last few seconds, probably Arduino now free to pump the movement command to FPGA.

Currently I also have issue related to accuracy with opendobot v1.0.0, This blocking me to move further and use opendobot. Even with photo interrupt installed,I am not able to have a repeatably movement (error is +/-3mm in XYZ). I intended to calibrate the accelerometer but since you mention in #23 my acc-module is not work with open-dobot. Any method to make the accuracy better?

[maxosprojects]

The problem described in #23 was that accelerometers couldn't be read which lead to "math domain error". That error simply mean that the arm configuration being tried to compute is impossible. You haven't mentioned you had the same problem. Run calibration-tool.py to see if accelerometers can be read and if not and you are still interested in open-dobot then comment on #23 and reopen it. Technically, photointerrupters would provide way better accuracy than those accelerometers and the arm wouldn't need to be in a specific configuration when the program is started (~45 degrees both links). The photointerrupter I used is dumb easy to mount using some hot glue but no less reliable.

I assume the described above was for 1.0.0. If so, then it should be mostly fixed by 1.1a

I have also found how to address slow pyserial behavior. Will push the fix tomorrow and update the alpha firmware.

As for the accuracy - it may be related to the comm problem. However, depending on the task you are making dobot execute you may not get accuracy you'd like simply because of the mechanical design flaws. There is a way to improve it a bit, but the gears on the motors is the problem that can be fixed only by replacing it.

Let's not get ahead with assumptions too much and mix multiple issues in one topic. To put things in order here are the options for you to with to address various concerns:

• reopen #23 for accelerometers
• raise a separate issue if you are interested in using photointerrupters instead of accelerometers
• raise a separate issue for the accuracy; don't forget to add the kind and the version of the operating system used when experienced lack of accuracy (including whether it is 32 bit or 64 bit), what are exact steps and scripts to reproduce (script having multiple repetitions or script executed multiple times), any other useful information

Computations in open-dobot are bound to motors' steps, not millimeters. So, technically, the precision should be 1 motor step which in physical distance is variable depending on the angles - the greater the angle the greater distance end-effector travels, but in most cases accuracy should still be way less than 3mm. Le't discuss in a separate topic.

[CquoTahi]

Ok, let me update the result of v1.1.0 alpha: -Tested with Pi Model B, (Single core): Result is ok, no jerky observed, i think you can promote the solution. -I also quickly try the calibrate-tool.py, result is same as #23. I am not able to read raw data either.

[maxosprojects]

Please check https://github.com/maxosprojects/open-dobot/releases/tag/1.1.0 on windows where you had jerky dobot in the first place. Make sure to use latest open-dobot python files (not only latest firmware).

[maxosprojects]

This has been tested on Windows7 32-bit running in VirtualBox (probably the toughest environment to test on) and everything is running smoothly. Closing this issue as there is no response from the topic starter. Promoting to release.