ValueError: math domain error on example-gripper.py
Closed this issue · 23 comments
Roys-iMac:open-dobot roykolak$ python application/fpga/python/example-gripper.py
--=========--
('Initializing with steps:', 0L, 0L, 8000L)
('Reading back what was set:', (1, 0, 0, 8000))
('Current estimated coordinates:', (50.90000000000002, 0.0, 78.0))
--=========--
--=========--
maxVel 700.0
accelf 400.0
moving from 50.9 0.0 78.0
moving to 260.0 0.0 180.0
moving by 209.1 0.0 102.0
distance to travel 232.65169245
slices to do 76.2646203115
accelSlices 38.1323101558
flatSlices 0
accelXYZ 359.507378258 0.0 175.369452809
segmentAccelXYZ 104.55 0.0 51.0
maxVelXYZ 274.17693702 0.0 133.744847327
segmentFlatXYZ 0.0 0.0 0.0
segmentToolRotation 0.0
==============================
slice # 1
moving to 50.9719014757 0.0 78.0350738906
nextToolRotation 0.0
radiusTool 50.9719014757
radius 0.0719014756515
ik base angle 0.0
jointX 0.0719014756515
jointY 0.0
actualZ -24.9649261094
hypotenuse 24.9650296509
hypotenuseSquared 623.252705472
q1 -1.56791623508
Traceback (most recent call last):
File "application/fpga/python/example-gripper.py", line 32, in <module>
dobot.MoveWithSpeed(260.0, 0.0, up, speed, acceleration, 0)
File "/Users/roykolak/Projects/open-dobot/application/fpga/python/DobotSDK.py", line 468, in MoveWithSpeed
q2 = math.acos((lengthRearSquared - lengthForeSquared + hypotenuseSquared) / (2.0 * lengthRearArm * hypotenuse))
ValueError: math domain error
digging into it myself, but thought I would report it!
The recommended starting pose is for both links to be at approximately 45 degrees (not strictly, +-5-10 degrees is fine): http://dobot.cc/en/download/document/Dobot%20User%20Manual_201600314_Final.pdf , Step 3
The math domain errors occur when you are trying to make dobot do pose that is outside it's normal range or starting the app from a not recommended pose.
In your specific case it seems that one of the accelerometers cannot be read. Please check it with calibration-tool.py. If you are using Python 3.x then take calibration-tool.py from master, I have just updated it.
Follow the instructions in calibration-tool.py. You should be able to see angles changing for both rear and front arms when moving the arm manually (hold the "Laser Adjustment" button, aka "Stepper_En", to move the arm around freely).
If you are not seeing one of the angles changing then one of the following is the reason, listed in probability decreasing order:
- accelerometer connection is poor
- accelerometer is not connected
- accelerometer is not functional
- a bug in firmware
hmmm... No matter where I move the arm when holding down 'Laser Adjustment', the calibration-tool.py output is always the same. (Using Python 2.7)
Rear arm: 90.000000 | Forearm: 90.000000 | End effector height: 63.000000 | Raw rear arm: 0 | Raw forearm: 0
Holding 'Laser Adjustment' and moving the arm does not change Rear arm and Forearm angles.
I checked all the connections and they seems okay. Something to note, I'm able to run example-driver.py and I do see the arm move in a patterned share. So that tells me that the arm can accept commands.
I have started going through the steps in calibration-tool.py, but hit a snag on Enable accelerometers reporting mode. How do I enable reporting mode?
Enable reporting mode exactly as it is described in calibration-tool.py:
4.1. Press and hold the "Sensor Calibration" button
4.2. Press and release the "Reset" button
4.3. Start this tool (still holding "Sensor Calibration" button)
4.4. Wait for the accelerometer data to start flowing on your console/whatever_you_use_to_start_this_tool
4.5. Release the "Sensor Calibration" button
Let me know if this is not clear and what confused you so I could rephrase it. You are not the first person getting confused about how to enable reporting mode.
But your Raw rear arm: 0 | Raw forearm: 0 tells me that neither accelerometer can be read. Did dobot-tools (the original software for windows) ever work for you?
Yes, the arm does accept commands and the data flows all right in the opposite direction too, otherwise you wouldn't see the angles:
if ret[0]:
print("Rear arm: {0:10f} | Forearm: {1:10f} | End effector height: {2:10f} | Raw rear arm: {3:4d} | Raw forearm: {4:4d}".format(\
driver.accelToAngle(ret[1], offsets[0]), driver.accelToAngle(ret[2], offsets[1]),\
toEndEffectorHeight(driver.accelToRadians(ret[1], offsets[0]), driver.accelToRadians(ret[2], offsets[1])),\
ret[1], ret[2]))
ret[0] is 1 when the arm confirmed command and returned the requested angles.
Ah I see. I didn't see those sub numbers!
so.. we tried and failed to use the dobot via the iOS app (in bluetooth mode) and via the dobot-tools windows app (in usb mode). I am worried that we received a bad arm at this point.
Well, it seems that only the accelerometers are bad as the arm does move.
You can check if the gripper would work with the following code:
from DobotDriver import DobotDriver
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')
def execute(gripper, toolRotation):
ret = (0, 0)
while not ret[0] or not ret[1]:
ret = driver.Steps(driver.stepsToCmdVal(0), driver.stepsToCmdVal(0), driver.stepsToCmdVal(0), 1, 1, 1, gripper, toolRotation)
for gripper in range(208, 480, 1):
execute(gripper, 0)
for toolRotation in range(0, 1024, 1):
execute(480, toolRotation)
You can still use the arm without accelerometers. You, actually, already did by executing the example-driver.py that doesn't care about the starting pose (does not rely on accelerometers - just sends commands). You'll just need to hack SDK a little bit (fake the accelerometers readings) so that the starting pose is faked and then start your code when the arm is exactly in that pose.
Let me know if you want to give it a try, I'll guide you through.
The gripper and rotator does seem to function. If I was to test the laser, w/o movement, is it correct that I can simply comment out the movement lines to create something like this..
from DobotSDK import Dobot
import time
dobot = Dobot('/dev/tty.usbmodem1421', debug=True)
def repeatUntilQueued(on):
ret = (0,0)
while not ret[0] or not ret[1]:
ret = dobot.LaserOn(on)
# dobot.MoveWithSpeed(200.0, -50.0, 100.0, 50)
repeatUntilQueued(True)
time.sleep(2)
# dobot.MoveWithSpeed(200.0, 50.0, 100.0, 0.75)
repeatUntilQueued(False)(The reason I ask is because it is not turning the laser on)
correct. but be careful with the laser! keep your hand on the switch to turn power off in case something goes wrong!
hmm... I can get everything to work except for the laser and accelerometers.. this is very strange
is pump working too?
yep, I confirmed that
well, SPI, that accelerometers are connected to, obviously works as it is the same SPI that commands to the FPGA board are sent by. How are your accelerometers labeled? The chip itself, not the PCB it is soldered on. If you have a good camera to take picture with that would be best.
Not exactly sure if this is what you meant, but here are someshots!
This is the accelerometer https://cloud.githubusercontent.com/assets/9306/15102102/f0a81abc-1560-11e6-9892-57d96049e988.jpg
It is completely different from the one I got. That explains why they are not read.
On that picture I can only see the label on the LC125A 44K chip. Of course there is no datasheet on it - probably another piece of clone of TI's SN74LVC125A, which is just a tri-state buffer. But the accelerometer must be the smaller, square chip with leads on all four sides, which is blurry on the picture. What is the labeling on it?
BTW, the FPGA (top) board is black in your case. Is it v1.1?
Mine is green.
Ah okay, this is making sense now. Yes I have v1.1
The accelerometer says...
M(or N or H?)P65
680LC1
L1549
Hm, that looks like another MPU-6500 clone.
I'll give it a try to read from it, but I can't promise anything as I don't have the device.
I'll make an experimental firmware version with support for MPU-6500 for you and if it reads anything then I'll make an effort to make it stable. If it doesn't read anything on the first try then I won't proceed unless someone sends me that accelerometer.
BTW, in #21 dobot is v1.1 and there are no problems with accelerometers, so it doesn't depend on the board version.
So there is quite a variety of that dobot junk in the wild. I tore down the mechanical part yesterday to try to eliminate the looseness in the joints - there are ball bearings in some joints and those are pretty loose themselves + there are plastic washers (white ones) to push on the side of those bearings. I assembled them in a different way and it improved accuracy a lot, but there is no cure for the looseness of the motor gear - dobot is just a pretty junk.
Thanks for the pictures, CquoTahi. It is highly unlikely that accelerometers are the reason for jerky behavior in your case.
well that's good to know... this bot is really getting me frustrated. I'm going to switch back to the official firmware and try to get it running via windows one last time..
The root of the problem has been identified as completely different set of accelerometers installed on the arm.
Closing this issue as the topic starter is not going to check if the MP65-based accelerometers would work with an experimental firmware.
Same problem here. I have got two MP 65 accelerometers with arm. In accelerometer reporting mode I am constantly getting:
Rear arm: 90.000000 | Forearm: 90.000000 | End effector height: 63.000000 | Raw rear arm: 0 | Raw forearm: 0
hey @rgrbic out of curiosity were you able to use the official dobot software to interaction w/ the arm? I am having trouble w/ both the windows software and the ios and android apps
Yes. I tried windows application. In application set speed to 9600 and user input to 45.