our Poppy is still not running and I’m working from time to time on it to get it run. I’m pretty sure that I discovered the root cause now, but what makes me a bit wondering is that nobody else talks about this issue, because it should involve every Poppy if my hypothesis is right.
The data signal from the USb2Ax gets worse quickly the more motors you are attaching. After a few motors the signal is so bad, that the communication is not working without errors anymore. I think the output of the microcontroller on the USB2Ax needs an additional driver. This is how I want to modify the design of the USB2Ax, after some tests (to be definitively sure).
What I want to do before is setting the Baudrate down from the default 1Mbaud (which seems unnecessarily high to me) and see if that helps already without hardware changes. My question now @Yoan is, if I can easily set Baudrate to lower values in the Poppy software or if this affects the working of the software in a negative way. I also have so set every motor Baudrate manually to this lower value, which is boring
If this would work, I wouldn’t have to redesign the USB2Ax.
But I’m still wondering why not everyone seems to have this problem.
Btw: Test setup of 5 dynamixel motors with brand new cables also had this issue, so it seems it’s not caused by cables.
Hey @Markus your observations are really interesting! How do you conclude to an altered signal, can you show some screenshots from an oscilloscope?
You should be able to reduce the baudrate in the constructor of the AbstractIO form the pypot library here.
Otherwise, the baudrate defaults to 1M for all motors. I don’t know the motivations behind this high baudrate, but recall that this is the default baudrate for all AX-12 motors (see in the Robotis documentation). Will from Robotis might have clues about this choice, if you want to contact him on the robotsource forum.
Obvisouly, do not forget to change the baudrate of your motors too using Herborist or Dynamixel Wizard.
AFAIK, the USB2AX is no longer supported by xevelabs but still produced by GenerationRobots and a few other distributors selling the device with the original schematics. No one in the Poppy team is now working specifically on the electronics, but @davidjsherman might be interested in this!
The comm may be altered by many causes but 5 motors should work smoothly though. I would try to swap the cables anyway even if they are brand new, we had so many troubles to due faulty cables in the past…
I give you two screenshots, first with one motor attached on USB2Ax, the other with more motors. This signal degradation shouldn’t be there in my opinion. However, I’m not completely sure if it is the root cause. I’ll do some more experiments when time permits.
What I found on the github repository of the USB2Ax was a newer version with modified values of a resistor, so it looks they had problems, too. However, even with this modified resistor it doesn’t work in my case.
“Upgraded to v3.2b : changed R3 from 150 to 47ohms for stronger line drive”
First we had 3.2a. When I saw the github note, I bought two 3.2b. It did not work either. I don’t have an U2D2.
For the moment I took an Arduino with an additional external driver circuit so that the signal edges where sharp on the scope. In this test scenario all motors where found and could be moved, except one motor (I have to figure out what the case for this is). Unfortunately I have very little time to work on this until summer, but I’m confident that the problem can be fixed. I keep you updated.
I am observing the same issue here. We can expect that all USB2AX in the world suffer from the same trouble. However it seems that usually the communication recovers from this smoothed signal.
Here is the signal coming from l_elbow_y of Poppy Torso with an USB2AX 3.2b :
Yes, that’s why I’m wondering why the problem has not been discussed on this forum yet.
Today I set the baudrate to 115200 from 1Mbaud and everything seems to work fine now (at least for the first testing) even with the USB2AX 3.2a. However, as I unplugged and replugged some of the cables in this procedure, I cannot exclude that a bad contacted cable might have caused the issue in the past. Maybe I should exclude that by setting baudrate to 1Mbaud again.
I found another strange thing, which would be another topic probably: In Jupiyter and Firefox I get the error message “kernel error”, although I made a complete new image on the SD card. If I use chrome as a webbrowser, there is no kernel error.
Have you seen that there is a v4.0 in the repository? It looks a totally different design with a different microcontroller but the problem could maybe be fixed with this version.
For the kernel error I fall on the same with Firefox in the past with no possibility to install Chromium on the desktop. I have memories about reinstalling jupyter-* stuff and it got solved. What is your base system image? We could discuss this on a different topic.
v4.0 is older than 3.2b, so I didn’t look at it. but maybe it would be interesting. at least at Generation Robots they told me that they sell only 3.2b.
I would say that it is because a quick fix as been applied lately to correct the defects of 3.2a lately, but we can hope that the design of v4.0 does not suffer from the same issues. I’ll try to test this design, I think it’s worth it!
Question to both of you, sorry if this is obvious: have you tried pinning the system clock, by adding core_freq_min=500 to config.txt? The first UART gets its clock from the system, which changes during idle and overheating.
It should also be possible to sacrifice Bluetooth and use a UART that doesn’t slew: dtoverlay=disable-bt
If the current communications problem is due to the clock, and we assume a Raspberry Pi 4, then the next iteration of the PIXL should just use one of the four additional UARTs. @Yoan another reason to include a HAT eeprom.
I get such a bad signal even when the USB2AX is connected to a regular PC. No difference seems to happen with the USB2AX connected on the Raspi instead.
Did you come further? I cannot find a firmware for this controller on Github. Besides, the Controller is not available on Digikey, Farnell and Mouser.
We will probably try to make a version of the USB2AX 3.2. with an additional driver on the RX/TX line and a bit modification of the original firmware. This should be a quite save route to get good results.
