Arlobot DHB-10 motor board bug with encoders



  • 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:

    I have added some new photos and videos

    * 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,
  • 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.
  • Hi @VonSzarvas,

    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.
  • VonSzarvasVonSzarvas Posts: 1,110
    edited March 6 Vote Up0Vote Down
    Hi @Alkarex

    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).
  • Alkarex wrote: »
    @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.
  • Hi @Alkarex

    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.
Sign In or Register to comment.