In the series of discussions about cheaper actuators, has anyone looked at the Dynamixel RX series? Specifically RX-24F and RX-64. They retail at a significantly lower price (due to the motor used) and they also come with the front horns (something the MX-28 don’t).
I know they use RS485 bus (the 4 pin Molex), but that is not an issue as I plan to anyway to use a custom made interface instead of the USB2AX dongles - that are too big and too expensive.
From what I see on the data sheet the main difference is the precision (1024 vs 4096) and the RX are much faster - hence the very high stall current (almost double).
I wonder if anyone had any experience with them and can indicate any compatibility issues with the current Poppy design (apart from the bus).
There is no compatibility issue, we use MX because they are smoother more precise and compatible with the USB2AX dongle which permit fast synchronisation loops.
On the mechanical aspect, they have the same size so you can use them. Yet we use also AX series and this ones are only 3 pin therefore you will have to manage at least 2 different buses.
Yes, indeed I realised there are two AX-12 which means I would have both the TTL and RS-485. I will see what can be done about that later. Another important difference I have seen by looking at the registries is that the RX-24F uses compliance slope (like the AX series) while MX uses PID controller. I’ll have to look through the code if this is taken into account when sending commands to the servos.
The price for the RX-24F is roughly half the price of the MX-28 if you also add the horn (they come included in RX-24F). So it is worth checking them.
I’ve ordered the last two RX-24F from Generation Robots and they will come on Monday. I plan to use a Raspberry Pi 3 (also waiting for the delivery of a couple of those) with some USB to RS-485 bought on eBay (this ones). I’ll hack them after testing so that they are smaller and fit better in the robot. The thing is they should be working better that other interfaces because they use dedicated hardware (a FT232R for USB to serial and then MAX485 for RS-485 conversion). Practically the USB2AX is kind of a hack because the data conversion is done in the ATmega and is mostly passing data between one port and the other. You can see the difference in price between the two.
It would interesting to know how the “smoother and more precise” would impact Poppy’s movements. I’m not that worried about the “fast sync loops” - most certainly the RS-485 convertors will do that too as they are blind to the package content (which is not the same for the USB2AX because it needs to look at all the packages as it passes them along).
Matthieu talk about sync_reac which is not a standard Dynamixel v1 packet, but which is implemented in the microcontroller.
1 packet from the OS serial will ask present_position present_speed and present_load to all motors in the bus. The USB2AX will send a message for every motors and end it back to a single packet to the OS. The USB latency is very high and it saves lot of time to work like that. On a Raspberry Pi 2 It take in average 26ms to get present_position present_speed and present_load with sync_read on 13 motors with the syncread on a USB2AX, but 100ms without…
Volume sales are probably not the same, which explain why USB2AX is so expensive.
And the stall torque is half the one of an MX28. RX-24F is suited for high speed low torque applications, which is not the case if you plan to use in in an humanoid or torso.
Excellent points, thanks for pointing them. I have looked a little more into them and here is what I found:
The USB latency is very high and it saves lot of time to work like that. On a Raspberry Pi 2 It take in average 26ms to get present_position present_speed and present_load with sync_read on 13 motors with the syncread on a USB2AX, but 100ms without…
Indeed that is a problem with USB and I did not appreciate the translation that USB2AX is performing. On the other hand everything depends on the USB frame latency - which is standard 16ms. Hence the delays you see. I’ve checked the data sheet of the PL2303HX that comes with the RS-485 adapters and these are preprogrammed to a 1ms delay. In principle that would mean for 13 servos you would get the same 26ms time (1ms command package and 1 ms response package x 13 servos). I will check that and confirm if it is the case once the servos are coming.
And the stall torque is half the one of an MX28. RX-24F is suited for high speed low torque applications, which is not the case if you plan to use in in an humanoid or torso.
I have to confess that I also had the same impression initially. Double the speed means probably the gear train adds 2x multiplication, hence a stall torque should be half. But in the Robotis data sheet for RX-24F the stall torque is stated as 2.6Nm@12V, while for MX-28 is 2.5Nm@12V. So the same… It really didn’t make sense - that would mean the motor in the RX-24F would need to provide twice the power of MX-28 to keep that speed. And then I looked at the stall currents: the MX-28 has a stall current of 1.4A@12V which means a maximum power of 16.8W, while the RX-24F has a stall current of 2.4A@12V which means 28.8W. The motor in the RX-24F is almost twice more powerful! Then the numbers make sense.
Why the RX-24F with a more powerful motor is half the price of the MX-28 is beyond me. Maybe because it’s older and (very possible) less reliable - I would expect it to get much hotter and possibly to fail faster than an MX. But I can limit the speed and see if that would still keep the performance form other perspectives.
I’ll hope I’ll be able to post some results next week.
RX-24F are fast but power-hungry and they fry easily. It’s impractical for the type of robots we are talking about, and i’m pretty sure you will experience it soon.
Concerning the USB2AX and the access time you hope to see, I’m pretty interested to see you get a fast enough loop with your solution. I designed the USB2AX this way (and you can see everything about it on usb2ax.com if you want to check the details) with the intent to make latency bearable while keeping the flexibility of using a regular computer (without requiring a realtime OS even) as host, which no other solution that I know of provides.
The loop time mentioned by Theo is not as good as it should be, and that’s due to the Raspberry and code more than the adapter. So take that into account when you will test, you will probably get lower loop times if you test on your computer instead of a Raspi, and same if you test with a C program instead of python, etc.
With a reasonably powerful computer and careful C coding you can have a full loop of about 3ms to read and write 7 servos. And that’s before using advanced scheduling tricks that the sync-read command allows, which could make it possible to read, write and compute IK for maybe 10 servos in about the same time…
See full data of one latency test I did here: https://docs.google.com/document/d/12Cttzxx7QP2ekiJNls9PWVCWiMpgOH4l0O6hUaiYVlQ/edit?usp=sharing
Please share with us if you manage to reach such communication speed in USB with any other way that do not involve completely offloading com’ and IK to a realtime controller. I include IK because the goal hereis to a control loop on the whole robot, otherwise in open loop it would be trivial.
Also, if you are now convinced that this hack that is the USB2AX is useful and find it too expensive, you’re welcome to make your own for the roughly $5-7 it would cost in single quantity, all the eagle files and BOM and firmware (source and bin) are available. As long as you are confortable assembling small leadless component that is.
I quick update on this topic: I have tested this week various RS485 dongles with the RX-24F and here is what I have:
there are 2 types of USB to UART chips that are commonly available: FTDI232 and Prolific’s PL2303HX. I’ve tested both and I found that PL2303 works only at 57600 and not at 1000000. FTDI works fine at 1000000. I think this because 1000000 is not a really standard UART speed and the PL2303 chip paper is not listing as supported speed.
make sure the ground (GND) is shared between the USB dongle and the servo. I’ve found it the hard way after trying many night to understand why I have so many failed packets. Once the grounds are connected the package errors are almost inexistent
the FTDI driver on MacOS is not optimised for speed (it will use the 16ms delays). The driver on Linux is optimised for 1ms delays (tested on Raspberry Pi with Ubuntu Mate 15.04)
I’ve done some speed tests using a program that reads the position, speed and load for the same motor ([1]) - 100 times and respectively 13 times (to compare with the ones above. Here are the results (one read means 1 request packet + 1 response packet with 3 parameters): 100 reads - 288ms, 13 reads - 42ms. The bus was working at 1mbps. This means the solution is quite usable.
That means the solution is quite feasible. I’m planning now to move to testing the RX-24F for stress. Will post the results when ready.
Also I will start putting the results on github - including the build of a board that includes the 2 dongles for RS485, IMU, power amplifier and a Murata regulator that will power all 5V stuff.
the speed is actually better: I realised that the default return_delay_time was still set on the servos and hence the replies were delayed. I’ve changed the setting to 0 now and re-run the same test: for 100 requests (and answers, requests include position, speed, load) the time is 173.43ms; for 13 requests the time is 25.38ms
I’ve managed to do some stress testing in dynamic mode. You can see the results in my github. Overall I am quite OK with the results. The servos indeed present apron. 2.6Nm torque in static mode. With the rig presented in the github when the arm (170g version) is positioned at 45 degrees I am getting aprox. 9% load.
The funny thing is that probably during testing I have overstressed one of the servos and now it behaves very strangely - it’s like it’s tired… Specifically it works fine on the bus (I can send commands and it responds), it also complies with movements but does not have the same power. When placed in the same position as the other servo it reports aprox 3 time more load (get_present_load), ex. 27% vs 9%. I’ve checked the gears - they seem to be ok, and nothing is blocking the horn - I can move it normally when not powered. I’ll take it apart again and check the motor this time. Let me know if anyone else has experienced something similar with other servos before.
Well, that’s one of the failure modes people have been seeing with these, one of the reason nearly nobody uses them anymore.
Most of the time it’s reported as the servo feeling “sticky”, a little sluggish when at no load. If it’s indeed the same problem, you might also see an increased current consumption when idle (in the order of 100mA IIRC).
