I can confirm that we've experienced the original issue reported on this thread across multiple DHB-10s (bought between May-Dec 2017). The error has been produced across many different batteries and charge levels. The DHB-10s would start blinking both LEDs after a minute or two operation.
We never really solved the issue either, but tried a few different things that mitigated the problem:
- We sent GO commands instead of GOSPD at a rate not exceeding 8Hz. We continued to retrieve odometry from the encoders using DIST and HEAD since we need it in our application.
- We imposed a min velocity constraint of GO +-32 +-32 for non-zero commands. Supplying values lower than 20 would cause the error with the 2 blinking lights within a few seconds of operation. Is this expected?
Would the command rate or supplying too low a velocity using either GO or GOSPD to one of the motors cause an error?
@Alkarex: Have the robots operated normally since the switch?
We can also attempt updating the firmware on our robots over the next couple of weeks. I'd appreciate any input.
@piyushk Thanks for the feedback. I am glad to read that we are not alone.
No, there is no significant improvement after all on our side with the new firmware (maybe a slight improvement, but this might be to some other parameters).
Yes, we also currently operate with the GO command, and have noticed that too low power or speed would make the motor board to crash.
When running our applications, we are currently reading the encoders from the Propeller Activity Board WX, but your approach seems to be a good idea.
More info from our side, after a lot of additional testing:
* There seems to be a significant mechanical pressure on the motor axis, as the motor holes and the aluminium holes are not perfectly aligned, which increases significantly the power needed to turn the wheels
Furthermore, the motor axis is not rotating perfectly orthogonal to its base, so the physical constraint is not constant during a rotation.
Using only two screws instead of three, combined with not screwing fully, seems to increase the duration between two crashes.
* Using the new firmware and its STATUS command, we get error codes -3 and -5.
So with the two observations above, our current guess is that the mechanical constraints in the current Arlo models are much higher than expected by the motor board, even when there is no load (wheels not touching the ground). It seems that both a mechanical fix as well as a firmware fix would be needed.
* To make our problem worse, some of our encoders do not seem to work fine (e.g. frequently missing some counts), despite the black plastic disc being clean and correctly centred, and the soldering double-checked.
Thanks for the updated information and photos guys. I've asked the team at Parallax for urgent review.
Some immediate thoughts...
That mechanical issue looks like it should be something...
Although I think you previously mentioned that swapping the motor and encoder cables between A and B sides didn't move the problem to the other channel?
I mean, assuming you've got one motor (say, Left- Ch.A.) with a good block and one with an "off tolerance" block (say, Right, Ch.B), then swapping both the motor and encoder wires for the bad block to the other channel, does that move the problem to the other channel? I think you said before it didn't- that Channel B remained the problem-- although I'm not sure if you moved both the motor and encoder, or just the encoder cables during that test?
David will know better if having one motor under-strain/over-current would impact both channels in the firmware. And he can interpret your status code results, so thank you that those also.
I'll keep watching, and wait for David's help on this.
We have just done some more testing with another brand new set of wheels (from the last robot we ordered in December), and the STATUS messages are sometimes -2, sometimes -3, showing that for that set, both sides have problems.
I assume the issue comes from multiple things. When I tested the motor board with the three Arlo we have, it is always the right channel that is problematic and the STATUS command returns either -3 or -5. I guess the mechanical problem lies on both wheels but only make the right channel crash. I tested on another two new wheel this morning and the error returns -2 or -3. -2 is returned shortly after I reset the motor board without stopping the test program.
Alkarex and zhowan,
Statuses -2 and -3 indicate a fault output from the left and right motor driver ICs, respectively. This should coincide with a steady illumination (without blinking) of the respective motor's Status LED. The fault output from either motor driver can also stop moving the motors, which would also cause a -4 or -5 status, so they are likely artifacts of the -2 or -3 status.
There are two possible causes of a fault output from the motor driver ICs: either too low of a battery voltage or too high of an operating temperature. Both conditions increase in likelihood the longer a motor is operating continuously, and the higher the load the sooner they will occur. Ideally, the battery will maintain a high enough operating voltage until it is depleted, and the operating temperature will never be high enough to trigger a fault.
The firmware updated with the STATUS command doesn't have any other changes, so it is not likely that updating to it will have an effect on fault condition occurrences.
Our machinist is looking into the orthogonality issue, and his preliminary findings are that it may be what is causing your Arlo to reach a fault so easily. He looked into the pocket for the socket head screw and found that two of the pockets are off center, but are also enlarged enough to not be a factor. The main issue he is concerned about is that we do not specify how much torque to apply, but their is a maximum torque above which orthogonality will decrease and the drive shaft may bind.
We are updating the documentation to use a procedure that will ensure the correct tightness. Until we have it ready, try using all four screws, but only finger tightening them. It is possible to check for binding by detaching the wheel and using a GO command, with a value of 127, to continuously run the motor, then monitoring either the encoder speed with the SPD command, or the motor current with a ammeter in series, then adjusting the tension of the screws to get the highest speed or lowest current.
In the event that your DHB-10 is overheating, you can add a heat sink to the board, with a mild non-conductive thermal adhesive, to cover all nine of the transistors in TO-252 packages, which is the largest transistor package used on the board. Advanced Thermal Solutions part number ATS-FPX054054013-110-C2-R1, which is available from Digi-Key, should fit nicely.
On my end, I'm working remotely for the next 2-3 weeks, and do not have access to the robots. I'll try out some of the suggestions in this thread at that time and report back.
Hello David,
Regarding the battery, we always pay attention to it, and we operate mostly with fully-charged batteries. We also measure the voltage of the batteries after crashes, right now for instance at 12.89V.
Regarding the temperature, after our last crash, we have just tried to put a finger on each component of the motor board, and they were not especially hot (not a very precise measurement, I know).
Crashes can happen with a freshly charged, cold robot, in a matter of seconds.
Finger-tightening the screws does not seem like a possible solution, since the black encoder disk will not be well aligned. Here is a photo of what I achieve manually:
Something else: Now that we mainly operate without encoders connected to the motor board, we have also observed some motor board crashes even when no encoders are attached.
Let us know if there is any other test we could do on our side.
About the finger-tightening... are you doing that with the hex-tool, or literally by "finger" only ?
I'm sure David meant to use the tool- but just to tighten only until fully in, (we might say "gently tightened"), as opposed to "hard tightened" when you've really applied a lot of force, and in doing so perhaps distorted the alignment of the motor-to-block slightly.
I'm sorry if you got that already- just I noticed in the photo above one of the bolt heads sticking out a bit- so thought I should share the thought. (This assumes those bolt-heads are supposed to be flush when installed correctly).- updated: checked an Arlo here, and they are flush.
@VonSzarvas In the photo, it was literally finger-only. The third screw cannot be screwed more without a tool and a bit of force (not much, but apparently enough to make the wheel harder to rotate).
@VonSzarvas In the photo, it was literally finger-only. The third screw cannot be screwed more without a tool and a bit of force (not much, but apparently enough to make the wheel harder to rotate).
Your feedback could be a clue.
I've really not experienced the "wheel being harder to rotate", even with our bolts screwed all the way in.
And it seems to me they should be bolted all the way in. If you get wobble, that's got to be as bad as too tight. I think you already discovered that by your previous observation about the encoders not getting properly aligned.
Just thinking along a different line here....
The motor- does that touch any of the delrin parts around it? And does the motor appear to bolt parallel to the block?
What I'm thinking.... If the spacers are all exactly the same length?, and the motor housing is not hitting/touching anything?, then the block and motor should be perfectly square. Is that what you experience? (I'm thinking that if one of those parts is out-of-square, then you could get the "wheel hard to rotate" or binding issue.
Did you get time to check those spacers... if they are all the same length?
If you find one a bit shorter... could you try a small washer (or similar) to bring them up to equal length?
I'm thinking of mechanical issues that might cause the wheels to feel hard to rotate, and not having the motor aligned square to the blocks seems a plausible cause... So that's why I wonder if the spacers might be slightly different lengths (bad tolerance), which could be solved/proven by a washer as an interim test.
.... similarly, if they are all too short you might get motor binding.
So if the above test of spacer length shows they are all the same length, then I'd suggest adding something close to 1mm thick washer on all 3 spacers anyway and test again.
I really hope this solves things for you. It seems like it might.
Alkarex,
As VonSzarvas mentioned, "finger tight" means as tight as you can turn the screw or screwdriver with your fingers, as opposed to gripping a screwdriver in your hand and using your arm to tighten it. In the case of the Allen-head bolts, I would recommend turning the shaft of the Allen wrench with your fingers, as tight as you can.
Also, regarding the mounting, our machinist got back to me on the tightness and did find that it may be possible that the ridge on the drive shaft that fits against the bearing is out of tolerance. If this is the case, tightening down the motor block will put excessive pressure against the bearing, which will add significant load. If this is the case, adding something to shim the spacers, such as one or more washers, can remedy the issue. It will take some trial and error to figure out how thick of washers to use, because if they are too thick, the encoder won't line up. If only finger tightening helps, we can send you a set of washers to try out, or find you a source for them.
Regarding the operation of the DHB-10 itself, the temperature/voltage fault will trigger regardless of whether or not the encoders are in use, but the open-loop 'GO' command may continue to operate after the fault condition has occurred. Because of this, you are more likely to get an error message when using a closed-loop command, like 'GOSPD', but only using open-loop commands will not completely avoid the issue.
In case reducing the tightness isn't enough to stop the fault conditions from occurring, I have attached a modified version of the firmware that runs the motor PWM frequency at 2 KHz, instead of the normal 20 KHZ. This will lead to a 5% or so increase in efficiency, which will reduce the load, leading to both a lower chance of an over-temperature condition or an under-voltage condition.
Alkarex,
I forgot to mention that when using the attached 2 KHz variation of the firmware, the motors while be significantly more noisy than when using the default 20 KHz version. This is why we use the higher frequency; for most customers it is worth the ~5% reduction in efficiency to avoid the audible switching noise.
@VonSzarvas In the photo, it was literally finger-only. The third screw cannot be screwed more without a tool and a bit of force (not much, but apparently enough to make the wheel harder to rotate).
David, thanks for the new firmware. We have adapted it a bit more and landed on a PWM of 10kHz, which seems to be a good compromise for us (still a bit annoying noise, though).
We have experimented a bit with additional spacers. On the inner side, it does not work well, as visible in the following video, but we use them on the outer side for one of our wheels, which helps mitigating the fact that the holes are not perfectly aligned. https://photos.app.goo.gl/r7j0RsqwNtITdeNG2
By implementing a number of measures, we have one robot that is currently running more or less OK (let's hope this will last):
- Use only 2 screws instead of 3 for the wheel assembly, and tightened just enough that it is still possible for the barrels to rotate
- Limit the rate of commands to the motor board, with at least 10ms between commands
- Limit to a max value of 220 for GOSPD command
- Limit to a max value of 100 for GO command
- Lower the PWM to 10kHz in the firmware of the motor board
We have broken a few encoders in the testing process, which we have replaced, as well as some fuses on the power board.
My colleague will do a bit more testing next week, and then there will be a vacation period.
Those washers are a bit on the thick side. If your drive shaft is out of tolerance, it won't move in or out at all, when the block is tightened down. Adding shims (e.g. washers) should just barely let the shaft move in and out. With as much movement as it had in your video, it won't be able to hold the encoder wheel in place, and the encoder wheel will be able to contact the infrared sensor, which can cause incorrect readings.
Regarding your note to limit the GOSPD command to 220; I would keep it even lower than that. The encoders have 144 positions per rotation, and the motors have a no-load maximum speed of approximately 95 RPM, when running at a 100% power level. That comes out to an approximately 228 positions per second with no load. With a load, and especially if the battery is anything less than fully charged, 220 positions per second may be unachievable. Command the DHB-10 to maintain an unachievable speed will create a motor error.
Also, you have mentioned that you needed to replace fuses. Can you provide more details on the circumstances under which they blew? The fuse is large enough, and the DHB-10 powerful enough, that it can indefinitely drive both motors at their stall current. There may be a commonality between the conditions that blew a fuse and the conditions that are causing hardware faults in the motor driver IC.
The fuse is designed to limit damage to the DHB-10 after current exceeds the absolute maximum it is capable of handling, but the fuse does not guaranteed damage will not occur. A situation extreme enough to blow the fuse could have also damaged the DHB-10. If damaged, it may not function as expected, which could possibly be a factor in the errors you are encountering.
In addition to what @Alkarex mentioned, we also change the ACC command to default value (512) instead of 1024. The robot (without any payload) works fine so far even with encoders connecting to the DHB-10. One thing we noticed before is that the robot would crash everytime it changes speed while we hand-push it to the ground. So I will do more test next week to see how it works with payload or force.
@David_Carrier, the 10A fuse broken when we accidently assigned a high value (200) to the GO command which we are not supposed to.
To be sure I ordered a second motor-set with DHB-10,
Propeller board etc. After a week fiddling and exchanging
different parts etc. I think I found a direction to what is causing this.
It seems that DHB-10 motor2 (right wheel) output has a much lower error-tolerance
compared to motor1 output (left wheel) at least 10 fold it seems when using motor feedback (GOSPD?).
To make it even stranger, I am able to blow the 10 Amp fuse by blocking motor1
with my hand (I feel it has very powerful torque, of at least 10 fold compared to motor2).
The fuse wont blow when I block motor2, it will go into error status with very mild torque
(a bit too soon in my opinion).
When I exchange the motor1 and motor2 wiring to the DHB-10 board, the behavior also moves
to the opposite motor/wheel assembly.
In my mind everything seems to point to the DHB-10 controller. I also wasted a lot of time looking
at the mechanical alignment. At least one motor assembly (1 of 4) was indeed creating a lot of friction.
Hope to contribute and to find a solution.
The code I used:
////////////////////////////////////////////////////////////////
#include "simpletools.h" // Include simple tools
#include "arlodrive.h" // Include arlo drive
int main() // Main function
{
drive_feedback(1); //Use feedback / GOSPD ?
while (1)
{
drive_speed(20, 20); // 20/127 of full power to motors
pause(3000); // Go for 3 seconds
drive_speed(0, 0);
pause(1000); // Stop
print("Program done!\n"); // Program done message
Hello Everyone,
I am also experiencing similar issues on my Arlobot, which was purchased late December of last year.
I have been watching this thread for a while, hoping the issue would sort itself out, but not much has happened here recently.
If anyone has learned anything new that has not already been discussed here, I would appreciate it if they could post it.
One thing I have not seen in this thread is a definitive statement as to whether or not anyone at or associated with Parallax has been able to reproduce any of the problems.
It is extremely easy for me to reproduce the problem by running the very first code snippet that was published in this thread: //DHB10-GOSPD.c
The key to solving any problem is being able to reproduce it. That does not seem to be a problem here.
1) I would like to see a statement from someone at or associated with Parallax something like "we have tested 5/10/20 arlo's with the //DHB10-GOSPD.c program, and have observed the problem on x number of the arlo's".
It is very possible that x might be zero, but even that would be good to know.
Today I installed a header on my DHB10 so I could use the prop plug to install the debug firmware provided by @"David Carrier" and was getting STATUS of -2 and -3, indicating that a fault was detected on the h-bridge controller, sometimes followed by a -4 as one might expect. It seems clear to me that one or more things (mechanical, electrical, or firmware) are marginal here.
2) I know nothing about the spin language, but I have spent some time examining the firmware and it appears to me that the firmware faults out based on a single read of the fault status from the h-bridge controller in the PDLoop routine.
I work in automotive electronics, and this is something that would almost never be done. It is too susceptible to noise.
I believe the firmware needs to debounce the MOTOR_L_FAULT and MOTOR_R_FAULT inputs before making a decision to shut down the motors. I do not have an oscilloscope available to get a sense for what the right numbers might be, but sampling inputs every 10msec and requiring 3 consecutive identical samples before changing the state of the debounced version of the signal is pretty standard. This is something I could do myself, but I have limited time and would appreciate it if someone from or associated with Parallax could do it for the community.
Could someone please do this?
Have not had time to look for mechanical issues yet, but seems clear that mechanical issues could lead to increased current draw from the motors, leading to increased electrical noise, which could cause faulting out of the firmware.
All I have time for now.
Any spin experts out there?
Looking at the spin code for the GoSpeed routine, the following statement caught my attention:
KiAcc[LEFT] := KiAcc[RIGHT]~~
I know next to nothing about spin, but looking at the "Sign-Extend 15 or Post-Set '~~'" section of the P8X32A-Web-PropellerManual-v1.2, it seems clear to me that
KiAcc[RIGHT]
will be -1 after the statement.
What is not clear to me is what the value of
KiAcc[LEFT]
will be because of the "Post-Set" nature of the ~~ operator.
If the expression was
KiAcc[LEFT] := KiAcc[RIGHT]~~ + 2
, like in the example given in the propeller manual, it seems clear that
KiAcc[LEFT]
would be equal to the previous/original value of
K1Acc[RIGHT]
+ 2 (not -1+2). Is this correct?
Since the expression
KiAcc[LEFT] := KiAcc[RIGHT]~~
does not contain any additional operations, is this a special case where
KiAcc[LEFT]
will somehow get set to -1 (which I believe is the intent) instead of the previous/original value of
KiACC[RIGHT]
?
Or am I missing something else?
Thanks,
Brad
(I apologize for the formatting.)
For reference:
Pub GoSpeed(LeftVelocity, RightVelocity)
LeftVelocity /= 2 ' Divide by two to convert pos/sec to pos/half sec
RightVelocity /= 2 ' Divide by two to convert pos/sec to pos/half sec
CheckHWVer
if PDRunning < 1 ' Requires use of the PD controller
return @MotorError ' Abort if it isn't running
case LeftVelocity
-32767..32767:
other:
return @InvalidParameter
case RightVelocity
-32767..32767:
other:
return @InvalidParameter
if Mode <> VELOCITY
InterpolateMidVariables
Mode := POWER ' Stop PDIteration from modifying mid-positions
KiAcc[LEFT] := KiAcc[RIGHT]~~
SetVelocity[LEFT] := LeftVelocity ' Then set the motors' powers
SetVelocity[RIGHT] := RightVelocity
StillCnt[LEFT]~
StillCnt[RIGHT]~
Mode := VELOCITY
Your new thread was deleted as it is against forum policy to double post, (post the same question twice). It also confuses forum members as to which thread to respond to.
Thanks for your understanding.
Please note that we are also still plagued by this issue as well. We are increasing our usage of our robots, and will try out the tips mentioned by @Alkarex in his last post over the next month. Any escalation from parallax regarding this issue would be appreciated. Thanks!
@Publison: I apologize for the gaffe. I understand your perspective. My thought was that a narrowly targeted question in what I thought was a more relevant (and different) forum would get a quicker and potentially more accurate response. No worries.
@"Dave Hein": Thank you for the clarification!
I am struck by the inconsistency/asymmetry of the
KiAcc[LEFT] := KiAcc[RIGHT]~~
statement relative to the other nearby statements throughout the firmware. I can not help but wonder whether it should be
KiAcc[LEFT]~~
KiAcc[RIGHT]~~
instead. I do not yet understand what the significance of a value of -1 might be though.
@Publison: I apologize for the gaffe. I understand your perspective. My thought was that a narrowly targeted question in what I thought was a more relevant (and different) forum would get a quicker and potentially more accurate response. No worries.
@"Dave Hein": Thank you for the clarification!
I am struck by the inconsistency/asymmetry of the
KiAcc[LEFT] := KiAcc[RIGHT]~~
statement relative to the other nearby statements throughout the firmware. I can not help but wonder whether it should be
KiAcc[LEFT]~~
KiAcc[RIGHT]~~
instead. I do not yet understand what the significance of a value of -1 might be though.
Sit tight. My email got the attention of three Parallax employees. It is in the mix.
I have my ARLO to test. I need to try and reproduce the problems.
Thinking of what could be different between users that are OK, and others with issues...
Maybe this has something to do with the resistance of the battery connection (length of cable, thickness, termination, or even the battery internal resistance according to age & temperature).
What about trying adding a capacitor at the VIN screw-terminals?
Perhaps something rated >20V and 100uF. Preferably low ESR if choosing an electrolytic, although try what you have available in the first instance. As long as the capacitor voltage rating exceeds your battery voltage by at-least 25%.
Comments
We never really solved the issue either, but tried a few different things that mitigated the problem:
- We sent GO commands instead of GOSPD at a rate not exceeding 8Hz. We continued to retrieve odometry from the encoders using DIST and HEAD since we need it in our application.
- We imposed a min velocity constraint of GO +-32 +-32 for non-zero commands. Supplying values lower than 20 would cause the error with the 2 blinking lights within a few seconds of operation. Is this expected?
Would the command rate or supplying too low a velocity using either GO or GOSPD to one of the motors cause an error?
@Alkarex: Have the robots operated normally since the switch?
We can also attempt updating the firmware on our robots over the next couple of weeks. I'd appreciate any input.
No, there is no significant improvement after all on our side with the new firmware (maybe a slight improvement, but this might be to some other parameters).
Yes, we also currently operate with the GO command, and have noticed that too low power or speed would make the motor board to crash.
When running our applications, we are currently reading the encoders from the Propeller Activity Board WX, but your approach seems to be a good idea.
More info from our side, after a lot of additional testing:
I have added some new photos and videos https://photos.app.goo.gl/QplqmX2viKLQJ6453
* There seems to be a significant mechanical pressure on the motor axis, as the motor holes and the aluminium holes are not perfectly aligned, which increases significantly the power needed to turn the wheels
Furthermore, the motor axis is not rotating perfectly orthogonal to its base, so the physical constraint is not constant during a rotation.
Using only two screws instead of three, combined with not screwing fully, seems to increase the duration between two crashes.
* Using the new firmware and its STATUS command, we get error codes -3 and -5.
So with the two observations above, our current guess is that the mechanical constraints in the current Arlo models are much higher than expected by the motor board, even when there is no load (wheels not touching the ground). It seems that both a mechanical fix as well as a firmware fix would be needed.
* To make our problem worse, some of our encoders do not seem to work fine (e.g. frequently missing some counts), despite the black plastic disc being clean and correctly centred, and the soldering double-checked.
Best regards,
Alexandre
Some immediate thoughts...
That mechanical issue looks like it should be something...
Although I think you previously mentioned that swapping the motor and encoder cables between A and B sides didn't move the problem to the other channel?
I mean, assuming you've got one motor (say, Left- Ch.A.) with a good block and one with an "off tolerance" block (say, Right, Ch.B), then swapping both the motor and encoder wires for the bad block to the other channel, does that move the problem to the other channel? I think you said before it didn't- that Channel B remained the problem-- although I'm not sure if you moved both the motor and encoder, or just the encoder cables during that test?
David will know better if having one motor under-strain/over-current would impact both channels in the firmware. And he can interpret your status code results, so thank you that those also.
I'll keep watching, and wait for David's help on this.
I assume the issue comes from multiple things. When I tested the motor board with the three Arlo we have, it is always the right channel that is problematic and the STATUS command returns either -3 or -5. I guess the mechanical problem lies on both wheels but only make the right channel crash. I tested on another two new wheel this morning and the error returns -2 or -3. -2 is returned shortly after I reset the motor board without stopping the test program.
Statuses -2 and -3 indicate a fault output from the left and right motor driver ICs, respectively. This should coincide with a steady illumination (without blinking) of the respective motor's Status LED. The fault output from either motor driver can also stop moving the motors, which would also cause a -4 or -5 status, so they are likely artifacts of the -2 or -3 status.
There are two possible causes of a fault output from the motor driver ICs: either too low of a battery voltage or too high of an operating temperature. Both conditions increase in likelihood the longer a motor is operating continuously, and the higher the load the sooner they will occur. Ideally, the battery will maintain a high enough operating voltage until it is depleted, and the operating temperature will never be high enough to trigger a fault.
The firmware updated with the STATUS command doesn't have any other changes, so it is not likely that updating to it will have an effect on fault condition occurrences.
Our machinist is looking into the orthogonality issue, and his preliminary findings are that it may be what is causing your Arlo to reach a fault so easily. He looked into the pocket for the socket head screw and found that two of the pockets are off center, but are also enlarged enough to not be a factor. The main issue he is concerned about is that we do not specify how much torque to apply, but their is a maximum torque above which orthogonality will decrease and the drive shaft may bind.
We are updating the documentation to use a procedure that will ensure the correct tightness. Until we have it ready, try using all four screws, but only finger tightening them. It is possible to check for binding by detaching the wheel and using a GO command, with a value of 127, to continuously run the motor, then monitoring either the encoder speed with the SPD command, or the motor current with a ammeter in series, then adjusting the tension of the screws to get the highest speed or lowest current.
In the event that your DHB-10 is overheating, you can add a heat sink to the board, with a mild non-conductive thermal adhesive, to cover all nine of the transistors in TO-252 packages, which is the largest transistor package used on the board. Advanced Thermal Solutions part number ATS-FPX054054013-110-C2-R1, which is available from Digi-Key, should fit nicely.
Regarding the battery, we always pay attention to it, and we operate mostly with fully-charged batteries. We also measure the voltage of the batteries after crashes, right now for instance at 12.89V.
Regarding the temperature, after our last crash, we have just tried to put a finger on each component of the motor board, and they were not especially hot (not a very precise measurement, I know).
Crashes can happen with a freshly charged, cold robot, in a matter of seconds.
Finger-tightening the screws does not seem like a possible solution, since the black encoder disk will not be well aligned. Here is a photo of what I achieve manually:
Something else: Now that we mainly operate without encoders connected to the motor board, we have also observed some motor board crashes even when no encoders are attached.
Let us know if there is any other test we could do on our side.
About the finger-tightening... are you doing that with the hex-tool, or literally by "finger" only ?
I'm sure David meant to use the tool- but just to tighten only until fully in, (we might say "gently tightened"), as opposed to "hard tightened" when you've really applied a lot of force, and in doing so perhaps distorted the alignment of the motor-to-block slightly.
I'm sorry if you got that already- just I noticed in the photo above one of the bolt heads sticking out a bit- so thought I should share the thought. (This assumes those bolt-heads are supposed to be flush when installed correctly).- updated: checked an Arlo here, and they are flush.
Your feedback could be a clue.
I've really not experienced the "wheel being harder to rotate", even with our bolts screwed all the way in.
And it seems to me they should be bolted all the way in. If you get wobble, that's got to be as bad as too tight. I think you already discovered that by your previous observation about the encoders not getting properly aligned.
Just thinking along a different line here....
The motor- does that touch any of the delrin parts around it? And does the motor appear to bolt parallel to the block?
What I'm thinking.... If the spacers are all exactly the same length?, and the motor housing is not hitting/touching anything?, then the block and motor should be perfectly square. Is that what you experience? (I'm thinking that if one of those parts is out-of-square, then you could get the "wheel hard to rotate" or binding issue.
Did you get time to check those spacers... if they are all the same length?
If you find one a bit shorter... could you try a small washer (or similar) to bring them up to equal length?
I'm thinking of mechanical issues that might cause the wheels to feel hard to rotate, and not having the motor aligned square to the blocks seems a plausible cause... So that's why I wonder if the spacers might be slightly different lengths (bad tolerance), which could be solved/proven by a washer as an interim test.
So if the above test of spacer length shows they are all the same length, then I'd suggest adding something close to 1mm thick washer on all 3 spacers anyway and test again.
I really hope this solves things for you. It seems like it might.
As VonSzarvas mentioned, "finger tight" means as tight as you can turn the screw or screwdriver with your fingers, as opposed to gripping a screwdriver in your hand and using your arm to tighten it. In the case of the Allen-head bolts, I would recommend turning the shaft of the Allen wrench with your fingers, as tight as you can.
Also, regarding the mounting, our machinist got back to me on the tightness and did find that it may be possible that the ridge on the drive shaft that fits against the bearing is out of tolerance. If this is the case, tightening down the motor block will put excessive pressure against the bearing, which will add significant load. If this is the case, adding something to shim the spacers, such as one or more washers, can remedy the issue. It will take some trial and error to figure out how thick of washers to use, because if they are too thick, the encoder won't line up. If only finger tightening helps, we can send you a set of washers to try out, or find you a source for them.
Regarding the operation of the DHB-10 itself, the temperature/voltage fault will trigger regardless of whether or not the encoders are in use, but the open-loop 'GO' command may continue to operate after the fault condition has occurred. Because of this, you are more likely to get an error message when using a closed-loop command, like 'GOSPD', but only using open-loop commands will not completely avoid the issue.
In case reducing the tightness isn't enough to stop the fault conditions from occurring, I have attached a modified version of the firmware that runs the motor PWM frequency at 2 KHz, instead of the normal 20 KHZ. This will lead to a 5% or so increase in efficiency, which will reduce the load, leading to both a lower chance of an over-temperature condition or an under-voltage condition.
I forgot to mention that when using the attached 2 KHz variation of the firmware, the motors while be significantly more noisy than when using the default 20 KHz version. This is why we use the higher frequency; for most customers it is worth the ~5% reduction in efficiency to avoid the audible switching noise.
David, thanks for the new firmware. We have adapted it a bit more and landed on a PWM of 10kHz, which seems to be a good compromise for us (still a bit annoying noise, though).
We have experimented a bit with additional spacers. On the inner side, it does not work well, as visible in the following video, but we use them on the outer side for one of our wheels, which helps mitigating the fact that the holes are not perfectly aligned.
https://photos.app.goo.gl/r7j0RsqwNtITdeNG2
By implementing a number of measures, we have one robot that is currently running more or less OK (let's hope this will last):
- Use only 2 screws instead of 3 for the wheel assembly, and tightened just enough that it is still possible for the barrels to rotate
- Limit the rate of commands to the motor board, with at least 10ms between commands
- Limit to a max value of 220 for GOSPD command
- Limit to a max value of 100 for GO command
- Lower the PWM to 10kHz in the firmware of the motor board
We have broken a few encoders in the testing process, which we have replaced, as well as some fuses on the power board.
My colleague will do a bit more testing next week, and then there will be a vacation period.
Best regards,
Alexandre
Those washers are a bit on the thick side. If your drive shaft is out of tolerance, it won't move in or out at all, when the block is tightened down. Adding shims (e.g. washers) should just barely let the shaft move in and out. With as much movement as it had in your video, it won't be able to hold the encoder wheel in place, and the encoder wheel will be able to contact the infrared sensor, which can cause incorrect readings.
Regarding your note to limit the GOSPD command to 220; I would keep it even lower than that. The encoders have 144 positions per rotation, and the motors have a no-load maximum speed of approximately 95 RPM, when running at a 100% power level. That comes out to an approximately 228 positions per second with no load. With a load, and especially if the battery is anything less than fully charged, 220 positions per second may be unachievable. Command the DHB-10 to maintain an unachievable speed will create a motor error.
Also, you have mentioned that you needed to replace fuses. Can you provide more details on the circumstances under which they blew? The fuse is large enough, and the DHB-10 powerful enough, that it can indefinitely drive both motors at their stall current. There may be a commonality between the conditions that blew a fuse and the conditions that are causing hardware faults in the motor driver IC.
The fuse is designed to limit damage to the DHB-10 after current exceeds the absolute maximum it is capable of handling, but the fuse does not guaranteed damage will not occur. A situation extreme enough to blow the fuse could have also damaged the DHB-10. If damaged, it may not function as expected, which could possibly be a factor in the errors you are encountering.
In addition to what @Alkarex mentioned, we also change the ACC command to default value (512) instead of 1024. The robot (without any payload) works fine so far even with encoders connecting to the DHB-10. One thing we noticed before is that the robot would crash everytime it changes speed while we hand-push it to the ground. So I will do more test next week to see how it works with payload or force.
@David_Carrier, the 10A fuse broken when we accidently assigned a high value (200) to the GO command which we are not supposed to.
I confirm that I am having the same problem.
To be sure I ordered a second motor-set with DHB-10,
Propeller board etc. After a week fiddling and exchanging
different parts etc. I think I found a direction to what is causing this.
It seems that DHB-10 motor2 (right wheel) output has a much lower error-tolerance
compared to motor1 output (left wheel) at least 10 fold it seems when using motor feedback (GOSPD?).
To make it even stranger, I am able to blow the 10 Amp fuse by blocking motor1
with my hand (I feel it has very powerful torque, of at least 10 fold compared to motor2).
The fuse wont blow when I block motor2, it will go into error status with very mild torque
(a bit too soon in my opinion).
When I exchange the motor1 and motor2 wiring to the DHB-10 board, the behavior also moves
to the opposite motor/wheel assembly.
In my mind everything seems to point to the DHB-10 controller. I also wasted a lot of time looking
at the mechanical alignment. At least one motor assembly (1 of 4) was indeed creating a lot of friction.
Hope to contribute and to find a solution.
The code I used:
////////////////////////////////////////////////////////////////
#include "simpletools.h" // Include simple tools
#include "arlodrive.h" // Include arlo drive
int main() // Main function
{
pause(3000); // Go for 3 seconds
drive_speed(0, 0);
pause(1000); // Stop
print("Program done!\n"); // Program done message
Regards,
Mars. (BeeClear)
I am also experiencing similar issues on my Arlobot, which was purchased late December of last year.
I have been watching this thread for a while, hoping the issue would sort itself out, but not much has happened here recently.
If anyone has learned anything new that has not already been discussed here, I would appreciate it if they could post it.
One thing I have not seen in this thread is a definitive statement as to whether or not anyone at or associated with Parallax has been able to reproduce any of the problems.
It is extremely easy for me to reproduce the problem by running the very first code snippet that was published in this thread: //DHB10-GOSPD.c
The key to solving any problem is being able to reproduce it. That does not seem to be a problem here.
1) I would like to see a statement from someone at or associated with Parallax something like "we have tested 5/10/20 arlo's with the //DHB10-GOSPD.c program, and have observed the problem on x number of the arlo's".
It is very possible that x might be zero, but even that would be good to know.
Today I installed a header on my DHB10 so I could use the prop plug to install the debug firmware provided by @"David Carrier" and was getting STATUS of -2 and -3, indicating that a fault was detected on the h-bridge controller, sometimes followed by a -4 as one might expect. It seems clear to me that one or more things (mechanical, electrical, or firmware) are marginal here.
2) I know nothing about the spin language, but I have spent some time examining the firmware and it appears to me that the firmware faults out based on a single read of the fault status from the h-bridge controller in the PDLoop routine.
I work in automotive electronics, and this is something that would almost never be done. It is too susceptible to noise.
I believe the firmware needs to debounce the MOTOR_L_FAULT and MOTOR_R_FAULT inputs before making a decision to shut down the motors. I do not have an oscilloscope available to get a sense for what the right numbers might be, but sampling inputs every 10msec and requiring 3 consecutive identical samples before changing the state of the debounced version of the signal is pretty standard. This is something I could do myself, but I have limited time and would appreciate it if someone from or associated with Parallax could do it for the community.
Could someone please do this?
Have not had time to look for mechanical issues yet, but seems clear that mechanical issues could lead to increased current draw from the motors, leading to increased electrical noise, which could cause faulting out of the firmware.
All I have time for now.
Regards,
Brad
Any spin experts out there?
Looking at the spin code for the GoSpeed routine, the following statement caught my attention:
I know next to nothing about spin, but looking at the "Sign-Extend 15 or Post-Set '~~'" section of the P8X32A-Web-PropellerManual-v1.2, it seems clear to me that will be -1 after the statement.
What is not clear to me is what the value of will be because of the "Post-Set" nature of the ~~ operator.
If the expression was , like in the example given in the propeller manual, it seems clear that would be equal to the previous/original value of + 2 (not -1+2). Is this correct?
Since the expression does not contain any additional operations, is this a special case where will somehow get set to -1 (which I believe is the intent) instead of the previous/original value of ?
Or am I missing something else?
Thanks,
Brad
(I apologize for the formatting.)
For reference:
Pub GoSpeed(LeftVelocity, RightVelocity) LeftVelocity /= 2 ' Divide by two to convert pos/sec to pos/half sec RightVelocity /= 2 ' Divide by two to convert pos/sec to pos/half sec CheckHWVer if PDRunning < 1 ' Requires use of the PD controller return @MotorError ' Abort if it isn't running case LeftVelocity -32767..32767: other: return @InvalidParameter case RightVelocity -32767..32767: other: return @InvalidParameter if Mode <> VELOCITY InterpolateMidVariables Mode := POWER ' Stop PDIteration from modifying mid-positions KiAcc[LEFT] := KiAcc[RIGHT]~~ SetVelocity[LEFT] := LeftVelocity ' Then set the motors' powers SetVelocity[RIGHT] := RightVelocity StillCnt[LEFT]~ StillCnt[RIGHT]~ Mode := VELOCITYThanks for your understanding.
@"Dave Hein": Thank you for the clarification!
I am struck by the inconsistency/asymmetry of the statement relative to the other nearby statements throughout the firmware. I can not help but wonder whether it should be instead. I do not yet understand what the significance of a value of -1 might be though.
Sit tight. My email got the attention of three Parallax employees. It is in the mix.
I have my ARLO to test. I need to try and reproduce the problems.
Maybe this has something to do with the resistance of the battery connection (length of cable, thickness, termination, or even the battery internal resistance according to age & temperature).
What about trying adding a capacitor at the VIN screw-terminals?
Perhaps something rated >20V and 100uF. Preferably low ESR if choosing an electrolytic, although try what you have available in the first instance. As long as the capacitor voltage rating exceeds your battery voltage by at-least 25%.