amir
New Member
Posts: 1 
|
Post by amir on Feb 2, 2018 15:34:10 GMT -7
Hey, I just purchased a Dobot Magician and I my goal is to control it using ROS. I have searched a lot but could not find any ROS package that can be easily modified. So, I am going to use the python code in open_dobot and implement it as a ros node later.
However, I could not find a detailed document about what should I do step by step to be able to use the open-dobot package. Should I purchase any other part to be able to use open_dobot? That would be awesome if anyone can help me with that by proving me what should I do from start.
Thanks
|
|
|
|
Post by Max on Feb 2, 2018 17:44:29 GMT -7
open-dobot is mostly a firmware for dobot 1.0 There is almost nothing you can take from it for magician as hardware is fundamentally different. Have you looked at dobot.cc? There is something about "ROS demo" at the bottom. Also, there is a description of the protocol if you need to dig deeper. If that's not enough, start with dobot on github. Someone might have posted a ROS driver for magician or 1.0/1.2 (protocol is similar). For instance, a quick look through github shows a python driver for magician. And here is an example of a ROS driver for another arm |
|
|
|
Post by matthew on Feb 5, 2018 15:03:07 GMT -7
Hi Max,
I am in a similar position as Amir, hoping to use open-dobot with the Magician. You said that the hardware is fundamentally different, but do you think it would still work with the main board replaced with the RAMPS/Arduino/GY521 setup?
Thanks
|
|
|
|
Post by Max on Feb 5, 2018 15:30:18 GMT -7
Hi Max, I am in a similar position as Amir, hoping to use open-dobot with the Magician. You said that the hardware is fundamentally different, but do you think it would still work with the main board replaced with the RAMPS/Arduino/GY521 setup? Thanks I see no reason why it wouldn't. But I recommend to first try to accomplish whatever you're planning with native hardware and firmware using their protocol. If you still want to try open-dobot for some reason, then I would recommend using SPI accelerometers. Looks like this is exactly the kind installed on magician (and dobot 1.2). You will need to implement the driver in open-dobot, which you can mostly steal from the open-source code that they released for dobot 1.0/1.2 You can see how SPI accelerometers are read in open-dobot for fpga (dobot 1.0) in accelRead() in fpga.cpp. You'll need to replace accelRead() in ramps.cpp with the code that reads MP65 |
|
|
|
Post by matthew on Feb 6, 2018 19:16:40 GMT -7
Thanks for the response Max, I appreciate the good advice.
Do you have a link to the open-source code that you mentioned?
Also, would you happen to know if there is any existing reference for the pin configurations of the MP65 accelerometers? The Magician's accelerometer pins are all bundled on a single header along with the IO's for the end-effector attachments.
Alternatively, I would be able be able to use the GY521 accelerometers without modifying the firmware, correct?
Thanks again
|
|
|
|
Post by Max on Feb 8, 2018 20:58:54 GMT -7
Can't find their code neither on their site, nor on github anymore. Maybe they removed it again. Good thing I made a copy right away github.com/maxosprojects/dobot1-stock-fwAbout pin configuration - that's a tough one. Can't help with that. My guess would be that all attachments sit on the same SPI bus together with the accelerometers and are only selected when needed. GY521 worked for me... with a lot of pain, though, from the interference, because they are I2C. Ferrite beads in that configuration solved it. |
|
|
|
Post by matthew on Feb 9, 2018 19:00:38 GMT -7
Thanks for the link!
The motor wires and the header with the accelerometers are all bundled into the same cable, and at the RAMPS end, won't they also be exposed to the same interference as if I were to use I2C? Is SPI more noise tolerant than I2C?
|
|
|
|
Post by Max on Feb 10, 2018 22:24:22 GMT -7
I2C is kind of passive - it works by pulling the wire to the ground, so you're responsible for pulling it to vcc via a resistor to make it all work. It is done that way to remove the need for "select" wire - any device can start talking at any time and to avoid one device setting low (shorting to the ground) while another device is setting high (shorting to vcc), it is left floating and any device can pull it to the ground instead.
That relatively weak signal is very susceptible to interference.
On the other hand, devices on SPI set "strong" low and high which isn't that susceptible to interference. That I actually observed with an oscilloscope and in the same setting SPI had no problem communicating while I2C couldn't at all.
If you decide to go with I2C accelerometers, the wires on the motor end are exposed enough for a ferrite bead. Don't remember how it is on the motherboard side, but I think you could separate them to put beads on.
|
|
