No it does not move at all.
gripper closes and opens and joint 3 falls down
No it does not move at all.
gripper closes and opens and joint 3 falls down
Will this work under Windows python3.5
What is dobot.xyz(x, y, z) and time.sleep() ?
Where do I get them?
I suspect the joint doesn’t fall down, but just moves down (not like in free fall, as the motors are not released - you can see the difference when pressing the middle button, called
stepper en, on the blackbox).
I’m afraid you may have a broken firmware or arduino.
dobot.xyz(x, y, z) makes dobot move to absolute x, y, z coordinates in dobot’s own coordinate system. If you dobot looks straight ahead when turned on then the python gist would make it move forward and back once at a specific height (-40 in this case). time.sleep() introduces a delay in between sending commands so that t decrease chances of dobot dropping subsequent commands for unknown reason https://docs.python.org/2/library/time.html#time.time
FYI, for cleaner experiment make sure you first turn the power switch on on the blackbox and only then plug the usb cable into your computer - that makes dobot read the accelerometers correctly and figure out its initial configuration.
The python gist won’t work in python3 without changes. Specifically, you would need to wrap the arguments to
Better install python2.7 - it’s not a big deal - they can live together if installed right.
Alternatively, you can run a VirtualBox Ubuntu 14.04 VM as a sandbox environment (or even a windows vm https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/ for that matter) and install whatever python version you want there. Though free windows vms expire after 3 months.
PS: the advantage of that python gist is that it reports you back dobot’s status.
I may fork the original Processing sketch later, apply all fixes, enable dobot status logging and give it a try under windows. Stay tuned.
No middle button (stepper_en)
my buttons Reset, Laser adj, Sensor cal
my dobot a kickstarter dobot
Dobot runs under — dobottools_v1.0.1_20160204
no idea what firmware is loaded in it?
I’ll load up python 2.7 and give it a go.
I took off the front face of that blackbox so long ago that I forgot it was ever there My bad, sorry. The button is still middle, but called “Laser Adjustment” on the front face (which is labeled as Stepper_En on the circuit board, if you look under the top lid, which makes much more sense as it is in fact setting Stepper_En on the stepper drivers that disables the drivers and you can freely move the arm around).
Mine is from kickstarter too.
Wait a second. You’re on windows. Does dobot work using any of the dobot windows apps? I was still in Linux context (as the topic suggests).
If you’re on windows and none of the windows apps work for you (make sure you hold the X+ X- etc buttons, and not just click them), then you should try to flash the firmware again. If even that doesn’t help, then you have a hardware problem.
Apps I use to control Dobot that work
DobotApplication_1.0.1 running under Windoze 7 pro
it may be using arduino 1.0.6
video of me driving with dobottools at:
due to the post from X.Junjie and noteb it is now much more clear, how the Dobot is interacting with the PC.
Thanks for releasing the Protocol documentation and the source code of the DobotTools.
Since I am using an older version of Qt (v4.6.3), there is still a bit of work for me, but I got the DobotServer working.
So it definitely uses 256K baud and the packages look like stated in the documentation, so all is setup for using Dobot under Unixes like Linux or Mac, etc. That would have been a no go, for me.
When I finished my work I will release it on github.
The next problem I see is that Dobot might randomly loose some commands, like noteb stated. Without fixing this it is hard to believe that we will get a reliable working robot arm.
If I understood the comment on Kickstarter correctly, the Dobot Team is NOT going to open source the arduino sketch source code nor the FPGA code, please correct me if I missed something.
Beside the fact that it was promised in the campaign and the communication policy and speed of updates of the last month (which I can fully understand due to the small team, and the amount of work they have done/ to do) I would really appreciate a rethinking of this decision.
The community is able to help here a lot, since beginner can get help from more advanced users, which frees the Dobot Team from the burden of writing tutorial or answering the similar question again, and again, or just getting bugfixes for free.
Without the source code the community is not able to help, and all which remains to do is to cry out for bugfixes and support.
Kind regards TK
I tried your python gist on a Fedora 23. Sadly I could not make it work.
I tried changing the baudrate to 9600, and the device seems to be /dev/ttyACM0.
Ok, I changed the baud rate to 256000, and then the dobot moves!
I’m not sure it moves the right way, but at least it moves.
Glad it worked for you. Not sure why it works with any baud rate under Ubuntu and MacOS but not under Fedora and Windows. I specifically avoided setting 256000 rate in the python gist as it depends on the version of pyserial module you have installed - the 256000 is not standard and is not available in older pyserial versions, as well as it is not available in Arduino IDE.
The direction of movement is determined by the coordinates you pass to dobot.xyz(x,y,z). Refer to documentation to see which axis is which.
This is the end of my journey with dobot as it is as I’m going to replace the top board with RAMPS (as more and more owners opt to) to get full control of the device I paid for (quite a lot for the value tbh) to be open (as was promised).
I will hook the accelerometers too (just for initial reading) and create a proper firmware to be able to control it via ROS. I’m going to use powerful inverse kinematics (IK) and trajectory planning open-source projects (that are available to ROS) that would simplify the firmware drastically and enable much more than the dobot proprietary firmware will ever be able to do (not even talking about bugs and fundamental flaws). ROS modules can be written in C or python, so it’s quite nice for the for a non-trivial repeating job (or even for such).
The reddit dobot forum would be a better place for now to share the progress on that as I suspect it won’t be welcomed here by the forum owners.
Interesting, I was thinking the same thing. I will follow over to the Reddit forum then and follow your progress. (Although I’m more of an old-school mailing list guy myself)
I got DobotTools working under Qt4 (had to change some calls to new interfaces, e.g. TimeDate), but dobot is loosing steps in an unreliable way. I decided to NOT take more effort in this closed source black box…
I have ordered a RAMPS v1.4 board and will switch over to open-dobot project on reddit/github.
Looks more promising to me.
Hi, we just released a version using 9600 Baud rate rather than 256K, which seems to be more robust in our previous test. and we do encourage you to use 9600 firmware and do the development.
and yes, we are currently not openning the source at this moment, but it does not mean we are not going to open it in the future. I value your advice a lot, and I will take it into the consideration. Thanks a lot!
As mentioned in upper post, the 9600 Baud is much more stable in communication. and replied in another post, we are working on the protocol, so that it may fits your need better in the future.
Your idea with ROS is very welcomed here. I worked with ROS before, and its a wonderful platform for robot.But I am not sure if there is a problem for you to directly communicate with Dobot controller through the current protocol. And after we upgrading the protocol, you can just upgrade the node for communication, rest nodes coulde be the same.
thank you for your answer and your reconsideration.
Will give your new sketch a try…
Can you at least give some advices about the architecture of the arduino sketch?
What is the FPGA doing?
Some info about the protocol ATMega <-> FPGA ?
I have figured out the protocol Arduino talks to FPGA. In my repo https://github.com/maxosprojects/open-dobot/tree/master/FPGA-SPI-protocol/purec you may find a C sketch that controls dobot by sending commands directly to FPGA board with all existing hardware. This sets up the required pins to enable this. As a precaution, disconnect accelerometers before flashing, for now.
I have also just released initial version of open firmware that you can use to send commands directly to FPGA from your machine via the USB. https://github.com/maxosprojects/open-dobot/releases/tag/0.1 if you don’t feel like compiling it yourself. The source is at https://github.com/maxosprojects/open-dobot/tree/0.1/dobot-firmware/fpga
There is a Python driver in the sources, which is stable. The Python example makes one motor (connected to the middle stepper driver in the blackbox) go back and forth with acceleration/deceleration.
For now it only controls the movements (the three steppers) with some magic numbers that I haven’t figured yet how are they translated to frequency. Let me know if you figure them out. I’ll add few more magic numbers with corresponding frequencies later.
Try to achieve this with original proprietary firmware
There is one major limitation with the way the system was designed because of the way FPGA was programmed - it doesn’t seem to be possible to move the arm precisely at speed. The problem is the following: the FPGA executes commands from Arduino in 20ms cycles (one command every 20ms - 50Hz). If you set the speed for a motor at 50Hz (50 steps/second) then you can tell it to move one step in any cycle - one command setting 50Hz, which with 50Hz command rate makes it move only one step - the precision you’d want. However, when you set the speed at, say, 250Hz - it’s 50 steps per cycle. So if you were planning for the arm to make a curve at speed then you simply can’t change the direction it’s moving before the cycle completes (the last command finishes) and you can issue next command with frequencies adjusted to the changing direction in the curve - it overshoots and diverges from the curve. I guess this also applies to making a straight line at speed given the non-linear end-effector translation to motor speeds. So if you are using the standard firmware then refrain from high speeds when trying to make a straight line.
Due to the Lenovo Error Code 1802 on my device, I am having issues with this in my LINUX. is there any other OS which I can try to get it done?