Ken,
Can I just get the latest firmware to update my boards? Or is there a hardware revision?
At the moment this is a hardware revision.
It may not impact everyone. The issue relates to rapid direction changes and more-so when the 3 motor bolts are not tightened to the same amount, which pulls the motors off-parallel to the motor mounting blocks, putting uneven strain on the wheel shaft.
More likely those with DHB-10's bought in the last year using encoders bought in the last year (identified as those with pre-soldered headers) are affected.
Note... the encoders are not an issue, but just to use those as an approx. timeline.
Earlier in this thread, David Carrier posted a special version of v1.0, which added a STATUS command to return the last error code. (That was the only difference from v1.0).
David's version could be used as direct replacement to v1.0, but it didn't get pushed to an official release.
GitHub:
Some other news.... Parallax are looking into pushing the source code into GitHub, subject to summer work queues/etc.!
Once that happens, someone will get David's update included too. Either me for sure, or whoever beats me to it! (as I think there are a few interested parties watching for the GitHub moment)
Thanks for the update VonSzarvas. I haven't been having any issues, and I believe all my DHB-10s are more than a year old. I never noticed any issues with the aluminum blocks or mounting bolts binding on my Arlo's.
I, also, don't really do rapid direction changes. My code is such that when any of the sensors indicate "getting close to something" I slow down first, then stop or change direction when it get's inside of a second threshold. Helps keep my walls and furniture from getting banged up.
We're starting to send out new DHB-10s to customers who've bought and had issues. Please destroy the old hardware so it doesn't get mixed up in the process.
We're starting to send out new DHB-10s to customers who've bought and had issues. Please destroy the old hardware so it doesn't get mixed up in the process.
This is the reason I will ALWAYS be a Parallax customer! You all are incredible! Amazing customer service.
Indeed Whit, they do their best to take care of the customer and make things right! That's why I love Parallax too!
Plus Ken and Chip and all the others I have met from there are super nice and smart folks! Several of them I count as friends, even if long distance ones.
Update: Our preliminary testing on one robot with the new controller board shows the problem has been resolved. We have been able to:
- Switch back to the closed loop GOSPD instead of the open loop GO commands.
- Increase command frequency back to 30Hz
- Give extremely low values of velocities to the robot without the controller seizing up. We were unable to go below 0.2 m/s previously, but we have now run the robot successfully at all lower speeds.
We will be testing on three other robots in the upcoming weeks, including one we never got to work even with our workarounds in place. I'll report back once that is complete.
I received a new DHB-10 board a couple of weeks ago, plugged it in and ran one of the first tests posted in this thread. Initially, the board did not behave any differently than my original board. It faulted out in about the same amount of time.
I made a change to the firmware requiring 3 consecutive reads of a fault on the HB chip before stopping, tested that, and could not get the board to fault out. Ok, great.
Then to attempt to make sure my firmware was doing what I thought it should be doing, I changed the fault threshold back to 1 and re-tested. I could not get the board to fault out.
I re-loaded the first version of debug firmware from David Carrier and tested. I could not get the board to fault out (I was removing the prop-plug in each case).
I re-loaded the (presumably) original firmware and could not get the board to fault out.
I have been unable to recreate the original fault out scenario since I have reprogrammed the board.
I guess this is good news, but I am puzzled by it. There were no mechanical changes between any of the above tests.
After the testing above, I decided to make some mechanical modifications as well to attempt to further improve my operating margins.
I went ahead and drilled out the large holes in the aluminum blocks to enlarge them slightly. I did not alter the smaller holes that the bolts pass through.
I also spent considerable time trying to improve the centering of the encoder wheel in the optical sensor channel on one side of my platform.
Finally, I added 0.0055" shims (aluminum soda can material) between the window motor attachment points and the standoffs, to relieve some of the pressure on the bearings. There is still a noticeable difference in play, or lack thereof, between the two sides after doing this.
Since doing all of the above, and running with my modified firmware, I have done considerable driving of the robot (all based on GOSPD ) and have not had the DHB-10 board fault out.
It remains to be seen how good the odometry is.
We're starting to send out new DHB-10s to customers who've bought and had issues. Please destroy the old hardware so it doesn't get mixed up in the process.
The picture is our latest production run.
Ken Gracey
Are the boards marked differently? I continue to have a problem with Arlo locking up and requiring a toggle of the Power switch and a POR of propeller to recover. Trying to implement a copy of the Chrisl8 implementation. I initially reported that the encoders were not centered. I see that there are new encoders with soldered leads. If there is a order number, I would be happy to try to center with a new set of encoders as well as upgrade to a new DH-10 board (I already replace the original which did not power up: please see my posts elsewhere). Thanks for additional information.
472 is good. I figured you'd have 104 if you had problems with the board.
If you have 472, then the issue is more likely with the encoder or mounting.
I'd suggest getting Arlo up onto a block, then running a slow wheel rotate and watching to see if it binds or struggles at any point during each revolution. Getting the blocks and motors aligned square is really critical, or you'll get binding at some point in the rotation which can cause locking up. You could also try loosening the bolts a quarter turn (or more) and see if that helps.
472 is good. I figured you'd have 104 if you had problems with the board.
If you have 472, then the issue is more likely with the encoder or mounting.
I'd suggest getting Arlo up onto a block, then running a slow wheel rotate and watching to see if it binds or struggles at any point during each revolution. Getting the blocks and motors aligned square is really critical, or you'll get binding at some point in the rotation which can cause locking up. You could also try loosening the bolts a quarter turn (or more) and see if that helps.
Thanks for the information. Does this encoder set have the leads soldered to the board? The picture looks like the set I have. I see no advantage to connectors for the wiring harness. Soldering straight to the circuit boards increase reliability. Even with the zip ties, I have had to re-connect several times. I will check for wheel alignment. My primary failure occurs on a rapid stop rather than straight line running.
Those encoders do have pre-soldered headers nowadays. Like you said, they were not like that in the beginning. They changed about a year or two ago.
Failing on stop - that's interesting. I'll think about that a bit, and also ask the technician at Parallax who wrote the drivers. He may be able to share some clues.
About the motor stop problem:
Based upon information gathered so far, I put Arlo up on blocks in order to diagnose
the motion stopping problem while running the Chrisl8 code set. I modified the
Test Encoder Connections program to run 50 cycles and the results match actual
test conditions on the floor. Sometimes it functions normally, sometimes it does not.
I then observed the gap between the sensor and the encoder wheel while the wheels
were turning. It appears that the encoder wheel wobbles between the sensor arms on
both the left and right wheels. I also observe that there is play with both the bearing
and the lateral support for both axles. Based upon these result, the assembly instructions
to ensure that the encoder wheel is centered within the sensor applies to my Arlo and
that is not the case as previouly reported.
My measurements show the following: sensor gap 3.14 mm, encoder wheel width 1.62 mm.
Therefore, the available free space to allow for wobbling is 1.52 mm. Since both the left
and right encoder wheels are close to the outside of their respective sensors, it appears
that I need to shift the sensors about 0.28 mm further from the motors.
Based upon that information, I believe the proper solution for my Arlo is to get new encoder
sensor boards with the holes drilled so that the sensor is shifted approximately 0.28 mm
closer to the cutout in the aluminum motor mount block. Another choice is to make the
mount for the sensor board adjustable by using a slot in the sensor board and binder head
screws and lock washers to attact the sensor board to the motor block.
Don't know whether this might be helpful...
Attached is a .zip of modifications to the firmware that I have been running without issue for some time.
This version includes the "David Carrier debug" extensions released earlier in this thread, as well as a new "REBOOT" command and a requirement that three successive h-bridge faults must occur before the firmware will fault out.
I also changed some status clearing code that looked incorrect to me.
No warranty of any kind.
I created a .git archive starting with the original firmware, then adding some Dave Carrier modifications released in this thread, and then adding my own changes.
As I recall, I had to do a bunch of character encoding cleanup as well along the way to make the files work correctly with the git diff command.
You should be able to see the change history using git.
Good Luck,
Brad
Thanks for additional information. I finally sat down and tried to read this entire thread.
My observation: many different Arlos reporting the problem. I did not see a great deal of feedback that those reporting the problem also reported that the problem has been resolved.
Also, I do not see a summary report with specific checklist proceedure for preventing/resolving the issue.
It would make me more comfortable to understand the approximate percentage of Arlos which are performing well in the field.
@bebement Thank you for your contribution to this thread. I have not tried your code yet. I have been swapping DHB-10 boards and trying different tightness of the wheel screws. I am presently using a DHB-10 board with date stamp 1646. What is the date stamp on the modified board sent to you by Parallax?
Many thanks,
Kevin.
@kg1
The number under "Rev A", is 1809. My original board was 1646, just like yours.
The small eight pin IC above "Motor 2 Status" has 472 on it. The original board had 104 on it.
Regards,
Brad
Thank you Brad. 1809 is an important date if one makes further purchases from third parties like Mouser. Freight is enormously expensive in and out of New Zealand hence there is no allowance for mistakes or returns.
Regards,
Kevin.
A quick feedback from my side: the updated motor board has improved the situation significantly, but we still observe frequent motor board crashes also during "easy" scenarios (no shock, flat floor, no extra load)
@Alkarex,
If your problems are occurring while using GOSPD, you might want try the modified firmware I posted above.
Regards,
Brad
Thanks; but, I am waiting for Parallax to update the official version before making changes to the DHB-10 code. I still believe it is a mechanical problem in my case.
PS: I am testing with the Test Encoder Connections from the online documantation which uses drive_speed commands (not sure if that resolves to GOSPD) in a 50 count loop.
Q. If you can observe the sensor, is the encoder wheel centered within the sensor (many require several obsevations due to wobble)?
Thanks; but, I am waiting for Parallax to update the official version before making changes to the DHB-10 code. I still believe it is a mechanical problem in my case.
Hi!
In case you didn't yet... and as you mention you are waiting for an update- I would strongly suggest you contact Parallax support directly so that they can help with your request. It's no so likely they are monitoring threads here, so they may not be aware that you are waiting on something.
I've been running my Arlo several months - I had one error at first, but my notched encoder wheel was not centered (between the emitter and reader). This error showed in the very first diagnostic test. I centered the wheel and have had no issues since. All of this was as suggested in the tutorial.
An update on the motor stop problem with my Arlo:
As suggested in an earlier post, I modified the sensor board attachment holes by
elongating them into a slot and attaching them to the motor block with 4-40 binder
head screws and star lock washers. This allowed me to center the encode wheel in
the sensor as directed by the assembly instructions.
I then modified the Arlo - Serial through arlodrive.c program to loop
for count times with a duty cycle of 2 seconds at gospd(32,32) and 2 seconds stop.
With Arlo mounted on blocks on a table so that I was able to sight check the encoder
placement, I ran the modified program through several hundred cycles with no failures.
So, back to floor testing for me. Thanks for all the valuable information provided by multiple
individuals on the forum.
Special thanks to Whit.
My conclusion: assembly should not proceed until the encoder wheels are centered.
Comments
At the moment this is a hardware revision.
It may not impact everyone. The issue relates to rapid direction changes and more-so when the 3 motor bolts are not tightened to the same amount, which pulls the motors off-parallel to the motor mounting blocks, putting uneven strain on the wheel shaft.
More likely those with DHB-10's bought in the last year using encoders bought in the last year (identified as those with pre-soldered headers) are affected.
Note... the encoders are not an issue, but just to use those as an approx. timeline.
Firmware:
The latest firmware is the same v1.0 version that shipped with DHB-10's, and also available here: https://www.parallax.com/downloads/dhb-10-motor-controller-firmware
Earlier in this thread, David Carrier posted a special version of v1.0, which added a STATUS command to return the last error code. (That was the only difference from v1.0).
David's version could be used as direct replacement to v1.0, but it didn't get pushed to an official release.
GitHub:
Some other news.... Parallax are looking into pushing the source code into GitHub, subject to summer work queues/etc.!
Once that happens, someone will get David's update included too. Either me for sure, or whoever beats me to it! (as I think there are a few interested parties watching for the GitHub moment)
I, also, don't really do rapid direction changes. My code is such that when any of the sensors indicate "getting close to something" I slow down first, then stop or change direction when it get's inside of a second threshold. Helps keep my walls and furniture from getting banged up.
The picture is our latest production run.
Ken Gracey
This is the reason I will ALWAYS be a Parallax customer! You all are incredible! Amazing customer service.
Plus Ken and Chip and all the others I have met from there are super nice and smart folks! Several of them I count as friends, even if long distance ones.
- Switch back to the closed loop GOSPD instead of the open loop GO commands.
- Increase command frequency back to 30Hz
- Give extremely low values of velocities to the robot without the controller seizing up. We were unable to go below 0.2 m/s previously, but we have now run the robot successfully at all lower speeds.
We will be testing on three other robots in the upcoming weeks, including one we never got to work even with our workarounds in place. I'll report back once that is complete.
Good news so far, I'm glad things are working out.
I made a change to the firmware requiring 3 consecutive reads of a fault on the HB chip before stopping, tested that, and could not get the board to fault out. Ok, great.
Then to attempt to make sure my firmware was doing what I thought it should be doing, I changed the fault threshold back to 1 and re-tested. I could not get the board to fault out.
I re-loaded the first version of debug firmware from David Carrier and tested. I could not get the board to fault out (I was removing the prop-plug in each case).
I re-loaded the (presumably) original firmware and could not get the board to fault out.
I have been unable to recreate the original fault out scenario since I have reprogrammed the board.
I guess this is good news, but I am puzzled by it. There were no mechanical changes between any of the above tests.
After the testing above, I decided to make some mechanical modifications as well to attempt to further improve my operating margins.
I went ahead and drilled out the large holes in the aluminum blocks to enlarge them slightly. I did not alter the smaller holes that the bolts pass through.
I also spent considerable time trying to improve the centering of the encoder wheel in the optical sensor channel on one side of my platform.
Finally, I added 0.0055" shims (aluminum soda can material) between the window motor attachment points and the standoffs, to relieve some of the pressure on the bearings. There is still a noticeable difference in play, or lack thereof, between the two sides after doing this.
Since doing all of the above, and running with my modified firmware, I have done considerable driving of the robot (all based on GOSPD ) and have not had the DHB-10 board fault out.
It remains to be seen how good the odometry is.
Are the boards marked differently? I continue to have a problem with Arlo locking up and requiring a toggle of the Power switch and a POR of propeller to recover. Trying to implement a copy of the Chrisl8 implementation. I initially reported that the encoders were not centered. I see that there are new encoders with soldered leads. If there is a order number, I would be happy to try to center with a new set of encoders as well as upgrade to a new DH-10 board (I already replace the original which did not power up: please see my posts elsewhere). Thanks for additional information.
Looks like the original board was 472. I will need to disassemble Arlo to be able to see new board. Maybe later if I work on the encoder problem.
472 is good. I figured you'd have 104 if you had problems with the board.
If you have 472, then the issue is more likely with the encoder or mounting.
I'd suggest getting Arlo up onto a block, then running a slow wheel rotate and watching to see if it binds or struggles at any point during each revolution. Getting the blocks and motors aligned square is really critical, or you'll get binding at some point in the rotation which can cause locking up. You could also try loosening the bolts a quarter turn (or more) and see if that helps.
Thanks for the information. Does this encoder set have the leads soldered to the board? The picture looks like the set I have. I see no advantage to connectors for the wiring harness. Soldering straight to the circuit boards increase reliability. Even with the zip ties, I have had to re-connect several times. I will check for wheel alignment. My primary failure occurs on a rapid stop rather than straight line running.
Failing on stop - that's interesting. I'll think about that a bit, and also ask the technician at Parallax who wrote the drivers. He may be able to share some clues.
Based upon information gathered so far, I put Arlo up on blocks in order to diagnose
the motion stopping problem while running the Chrisl8 code set. I modified the
Test Encoder Connections program to run 50 cycles and the results match actual
test conditions on the floor. Sometimes it functions normally, sometimes it does not.
I then observed the gap between the sensor and the encoder wheel while the wheels
were turning. It appears that the encoder wheel wobbles between the sensor arms on
both the left and right wheels. I also observe that there is play with both the bearing
and the lateral support for both axles. Based upon these result, the assembly instructions
to ensure that the encoder wheel is centered within the sensor applies to my Arlo and
that is not the case as previouly reported.
My measurements show the following: sensor gap 3.14 mm, encoder wheel width 1.62 mm.
Therefore, the available free space to allow for wobbling is 1.52 mm. Since both the left
and right encoder wheels are close to the outside of their respective sensors, it appears
that I need to shift the sensors about 0.28 mm further from the motors.
Based upon that information, I believe the proper solution for my Arlo is to get new encoder
sensor boards with the holes drilled so that the sensor is shifted approximately 0.28 mm
closer to the cutout in the aluminum motor mount block. Another choice is to make the
mount for the sensor board adjustable by using a slot in the sensor board and binder head
screws and lock washers to attact the sensor board to the motor block.
Thoughts?
Attached is a .zip of modifications to the firmware that I have been running without issue for some time.
This version includes the "David Carrier debug" extensions released earlier in this thread, as well as a new "REBOOT" command and a requirement that three successive h-bridge faults must occur before the firmware will fault out.
I also changed some status clearing code that looked incorrect to me.
No warranty of any kind.
I created a .git archive starting with the original firmware, then adding some Dave Carrier modifications released in this thread, and then adding my own changes.
As I recall, I had to do a bunch of character encoding cleanup as well along the way to make the files work correctly with the git diff command.
You should be able to see the change history using git.
Good Luck,
Brad
My observation: many different Arlos reporting the problem. I did not see a great deal of feedback that those reporting the problem also reported that the problem has been resolved.
Also, I do not see a summary report with specific checklist proceedure for preventing/resolving the issue.
It would make me more comfortable to understand the approximate percentage of Arlos which are performing well in the field.
Many thanks,
Kevin.
The number under "Rev A", is 1809. My original board was 1646, just like yours.
The small eight pin IC above "Motor 2 Status" has 472 on it. The original board had 104 on it.
Regards,
Brad
Regards,
Kevin.
If your problems are occurring while using GOSPD, you might want try the modified firmware I posted above.
Regards,
Brad
Thanks; but, I am waiting for Parallax to update the official version before making changes to the DHB-10 code. I still believe it is a mechanical problem in my case.
PS: I am testing with the Test Encoder Connections from the online documantation which uses drive_speed commands (not sure if that resolves to GOSPD) in a 50 count loop.
Q. If you can observe the sensor, is the encoder wheel centered within the sensor (many require several obsevations due to wobble)?
Hi!
In case you didn't yet... and as you mention you are waiting for an update- I would strongly suggest you contact Parallax support directly so that they can help with your request. It's no so likely they are monitoring threads here, so they may not be aware that you are waiting on something.
https://www.parallax.com/support
An update on the motor stop problem with my Arlo:
As suggested in an earlier post, I modified the sensor board attachment holes by
elongating them into a slot and attaching them to the motor block with 4-40 binder
head screws and star lock washers. This allowed me to center the encode wheel in
the sensor as directed by the assembly instructions.
I then modified the Arlo - Serial through arlodrive.c program to loop
for count times with a duty cycle of 2 seconds at gospd(32,32) and 2 seconds stop.
With Arlo mounted on blocks on a table so that I was able to sight check the encoder
placement, I ran the modified program through several hundred cycles with no failures.
So, back to floor testing for me. Thanks for all the valuable information provided by multiple
individuals on the forum.
Special thanks to Whit.
My conclusion: assembly should not proceed until the encoder wheels are centered.