Je sais, c’est pas bien de rédiger en français, mais j’ai si peu de temps.
Juste pour dire que ma version de DxTosser reçoit bien les données de pypot.
Je peux vérifier ce qui est reçu en écoutant le port serié BT de l’OpenCM 9.04 pendant que pypot communique par Usb.
La fenêtre à gauche est juste le moniteur série de Arduino IDE connecté au BT de mon Darwin mini.
On voit l’erreur que sort pypot en réponse.
Je ferais de même pour les données en sortie pour tracer ce qui est répondu.
Le code que j’ai utilisé est sur Github
J’envoie les données par Pypot :
import pypot.dynamixel ports = pypot.dynamixel.get_available_ports() dxl_io = pypot.dynamixel.Dxl320IO(ports[0]) dxl_io.scan()
Mais je ne reçois que de pypot vers le port USB comme les traces reçues par BT le montrent :
-v1.1.1 Orders receiver started BT
From USB : FF
From USB : FF
From USB : FD
From USB : 0
From USB : 0
From USB : 3
From USB : 0
From USB : 1
From USB : 1A
From USB : DA
j’ai aperçu d’autres dxlTosser assez identiques, je ne vois pas pourquoi ça ne veut rien émettre dans mon cas.
j’ai une sorte d’intuition que ce serait lié à des problèmes de vitesse de communication entre les différents étages, mais aucune certitude.
Je ne vois pas dans le code où le baudrate est réglé pour les XL320, et je ne comprends pas non plus pourquoi tu instancie 3 ports série différents.
j’utilise SerialUSB comme entrée qui correspond au port utilisé par pypot.
Le Serial2 correspond au port BT et me permet de voir ce qui se passe en me connectant dessus
j’ai un troisième port série ?
Pour le baudrate, à priori ça se règle avec Dxl.begin
Hey,
First thing : remove any long blocking operation. So the delay in blink_once, all the prints that are not part of the communication itself.
There is no chance for that to work while the delay between each byte is bigger than the servo internal byte-to-byte timeout, which is 100ms
( http://support.robotis.com/en/product/dynamixel/dxl_communication.htm talks about that at the very bottom).
And the BT serial might be useful (even though a little slow), but you’d better not interleave writing to it and to the dxl port.
If the serial libs are implemented with interrupts, it might not matter in most cases (that will depend on the size if the corresponding tx buffer, the quantity of data you try to send and the way the lib handles the buffer being full), but you could be safer by just removing it.
Now that I told you to basically remove all the debug features, you might ask how to debug things then…
If you have a logic analyzer, that’s the way to do it.
Start by monitoring the DATA line to see what actually goes on on the bus.
To get more info about what is happening in your code, set a few GPIOs as output, and switch them high or low at key points in your code.
You can use pulses (set high then low immediately afterwards) to show events happening, potentially using multiple of them to get more info (example: one pulse when doing this, two pluses when doing that, … Or as many pulses as the state you are in in a finite state machine, or as many pulses as the number of time you pass a certain point… ).
You can also use these gpios to delimitate zones: set high when you get in a function and low before you return, you have the exact time it took to run it. I use that all the time to benchmark performance without slowing down the execution or requiring additional memory.
The logic analyzer software will show you precise timing of all the things happening on these debug pins. It is not as explicit as text printed on the screen, but it’s so much more powerful to debug time-sensitive code like communications.
With the arduino-like code, the pulses will not be super-super narrow, it might take dozens of cycles to do one, but compared to the rest of what is happening it should not impact too much. I usually write directly in the register to do it in 2 cycles per change, but it’s not really arduino-like and probably overkill here.
Not too important anymore as it would be solved by removing all debug prints, there is the problem of you writing debug info to SerialUSB. These additional characters are mixed within the data coming from the Dxl bus… Pypot will see it all and will never be able to parse any packet.
Edit: when talking at 1Mbps like it’s the case here, one character takes 0.01ms to be transmitted on the bus (8 bits + 1 start bit + 1 stop bit, so 10 bits per transmitted byte), so think wisely before adding any delay() or print.
That’s a very complete answer.
I’ll try to clean everything.
But it looks strange because I added things to a DxlTosser that people claimed to work…
Of course, I’ll keep you informed in this thread.
Thanks a lot.
My bad, I mistook delay_us for Delay - that’s because in Arduino-speak, a delay in microseconds is annoyingly called DelayMicroseconds. The original code should have worked, even though it would have been significantly slowed down by that delay.
Anyway the ther remarks are still valid, especially the part about the debug info being mixed with data.
YESSSSSS !!!
Github updated, the code is very minimalist, we’ll see if it’s enough reliable
and…
Now I can start experiment, looking for the ultimate goal of having a Raspberry in control with a Hipi through a dedicated creature 
Ok, I’ll start with manuel tests of different pypot APIs
CONGRATULATIONS!!
Amazing work, I think you’re the first worldwide to succeed in that, because I haven’t found any other topic than yours.
Well, why do you need the hipi board, now you can manage and power anything through an OpenCM9?
If there’s no other topic, maybe is it because it was so simple that I was the only one to struggle with it 
The idea behind the Hipi board is to have autonomous robot with all process power in a raspberry.
One other reason is that this OpenCM solution allow me to experiment but is not 100% stable.
For exemple, I can’t use autodetect_robot() method because of motors failing to answer, and not always the same.
But when I look at the time between Pixl board conception and availability in stores, I know I have plenty time to experiment before Hipi is out 
The Pixel was created with a complete robot, but you are write… We will try to be better for the Hipi…
The first version of the prototype of the Hipi is ready to produce : Hipi | Projects | CircuitMaker
We have to test ISP to UART convertion before, but if this test pass we start the prototype production this week.
I’m following the Hipi thread, I know this needs some work.
No hurry on my side, i have so much to learn in so many different areas
Hey guys, I’m also trying to use OpenCM9.04 as a USB2Dynamixel. And here I found a solution from horchler/DynamixelQ and tested successfully with AX-12A servos!
