What if you had much faster communication with servos?

Technology
1

Imagine that you could query the position of the servos, and the value you would get instantly was always less than 1ms old, and sending new positions to them would return instantly and be applied to the servo before the next 0.5ms are elapsed, all that from the convenience of your high-level language on your embedded (or not embedded) computer running your OS of choice.
What would such a thing enable you to make?

I have a crazy idea, maybe some day I’ll work on it… but I wonder what people would want to do with it, or if it’s even something anyone would want beside me…

2

Well of course that is of much interest! especially if it can scale to many motors or any sort of devices and without extensive wiring!

Most research done for the control of complex robots and their dynamics require high update frequency (a couple of 100Hz). But such robots (HRP2, Boston Dynamics’, iCub) have specific design that enable such high-speed communication with so many sensors and motors.

Making this easy to use and scale would be a great step forward, but it is sure not an easy task. We are all curious about the solution you have in mind :wink:

3

There are two questions at hand when we talk about “latency”
.
One is how long it takes from the application to retreive a value. This is basically how much time the program will lose to get that value.
The other is how old will that value be when the application gets it.

Both can be drastically improved upon compared to what we have now.
And I’m still putting the restriction of no custom linux board (only commercially available and community supported ones), out-of the box Linux-based OS (no realtime kernel, etc), plug and play USB interface, and no modifications to the servos. Basically the goal is to get fast speed on any hardware and any OS/software with limited changes. Keeping things as simple as possible…
The area of improvent are all across the board:

  • hardware : use USB 2.0 High Speed, change the interface to a MCU that can handle multiple UARTs simultaneously (so something with sensible DMA and at least 4 hardware UART).
  • firmware on the interface: not only handle multiple DXL buses simultaneously, but also add a configurable loop that reads data from servos all the time. All regular commands received from the host would be interleved with the loop so as to be nearly transparent to the host.
    The interface would know how to talk in both DXL1.0 and 2.0, and could optimize for it by creating automaticalky the most efficient set of packets to satisfy the host request. Different lines could talk at different speed to accomodate all servos (for example, one TTL line at 1Mbps for AX, one at 3Mbps for some MX-28T, and one RS485 line at 4.5Mbps for some XM-430).
    Maybe add also an interpolation engine that works accross all dxl models (even though newer models like the XM can do it themselves) and makes it possible to adjust motions based on load and servo model just for kicks, since it seems to be a feature some people like.
  • software : create a service that exposes the DXL buses to the rest of the computer ( either emmbedded in your app or as a server to expose it to multiple processes, and even to processes running somewhere else on the network) through various interfaces : ZMQ with IPC or sockets, real sockets, maybe encapsulate that in a ROS node, etc. This server would be able to handle multiple interfaces each having potentially multiple DXL lines.
    Inside this process, there would be a table that could be created with all the data read (and written) from the servos, each with timestamps to know its age.
    The process would be instructed by the application (or through a config file) about the servo IDs it would have to talk to, and which one to monitor in priority. It could detect by itself where to look exactly (routing to the right line of the right interface by pinging around), or that could be forced by the config too. Keeping servo IDs unique would make things easier.
    All the data automatically sent back by the adapter would be integrated in the table and the query for data from the application could be either “get me your last value for X” or “get me a value for X that is no more than Y ms old”, which would trigger a request to update that value if the one available is too old.

In all of that, we could still preserve backward compatibility. The interface could work like a USB2AX + hub out of the box by using all lines as one, and maybe offer the advanced functionalities through a second endpoint (second virtual serial, or maybe HID for additional priority on the bus?).
The sever could have bindings in any language, though I’m personally interested only in C, C++ and python. For python, it would be yet another layer of speedup to have all the packet creation/reading outsourced…

For the hardware, I imagine something not much bigger than an USB2AX (20x45mm instead of 16x36) but with 4 ports oriented to the sides instead of aligned with the usb port. One fun aspect of the idea I have to make it is that it could be made to have both TTL and RS485 connectors (2 of each), or 4 of any of the two. The chip I have my eyes on actually has 5 UARTs so we could add a small connector for XLs too (however that one would not be electrically connected to VBUS on the other ones).
Funny thing is that the MCU to do that doesn’t even need to cost a fortune, I found a cute one ATSAM3U1 (though a little big at 9x9mm) that can do all I need for 3.2 EUR /100pc - as a comparition it’s not that much more than what the atmega32u2 I use in the USB2AX used to cost when I started the project). On-board USB High-Speed, running at up to 96MHz, 4 UART, many DMA channels, …

Some of these could be implemented right now with existing hardware (USB2AX, Arbotix, OpenCM9.04)… yet what I’m most exited about would be the hardware…

4

Without even going that far, we could do other great tricks:

  • having a mode in the interface that would allow it to automatically configure the servos for maximum performances (return delay time, maybe baudrate…)?
  • less invasive and doable with any current MCU-based interface: letting the interface schedule the packets. The USB communication looks like full duplex from the application point of view, so why not make use of it? The interface would query the servo to know if it’s there, its return level value (to know if it should wait for a status packet), and would simply manage packets in the most efficient way possible, leaving no unused bus bandwidth. The host would then simply blast commands and get the responses extremely fast, and in order.
    A little bit like a transparent sync_read generalized to all commands :smiley:
  • in the case of the 4-dxl-line interface, it could automatically create a routing table to make the lines transparent to the user (goes hand in hand with the previous idea).

So many possibilities…

5

Yes, I am also interested in it ! Having such low delay/high rate communication can allow having very smooth gestures at first (we can consider that a smooth gesture is obtained at 24Hz… cartoon framerate)
But having higher framerates is also very good for optimal control when you want to optimise the dynamic of your robot computed in the embedded computer (for biped robot for instance…:smirk:.)
For low cost mechanic robots like Poppy, the big issue is flexibily+game which introduces biases in the robot. Therefore, even if you get a high rate communication, the returned values are difficult to take into account.

I don’t know what you plan to do with alternative sensors but the fact you can have sensors on the same bus to avoid the additional wires is a major key to improve robots move. With the decrease of cost of IMU due to drone democratisation, I plan to put an IMU in each solid of Poppy. To do so, for the moment, I have to design a parallel wiring system … And I see that more wires is more issues.

I also think about buttons and pressure sensors below the feet…

6

Agree, let’s do it ! The actually 70Hz max is a limitation for the speed of the robot, especially when you want to have balance behaviour.

7

I’m currently finishing a work project, I’ll get back to this at some point this month.

3 Likes
8

Took time, but I am finishing the design of the first prototype(s).

So the interface is currently a 32x44x15mm thing made of two PCBs stacked.
On the top one are the connectors (right angle, like on the USB2AX), a screw terminal for power, protection on each Dxl line and a MOSFET to turn power on/off, controlled by the main MCU.
On the bottom plate is the MCU, a Micro USB port, a 6DOF IMU, an EEPROM chip, a button and a few LEDs.
There are 4 independent Dxl lines, that can work in parallele.

The top plate can be changed (it’s connected using a 1.27mm 10x2 connector) to make different versions : TTL for AX/MX, TTL for XL-320, RS485 for MX/RX, RS485 for XM, or any combination. The firmware would be the same for all, so changing the plates would be the only difference.

The first version has 6 TTL (AX) connectors, but I imagine that one with one type of connector per line and separate power input for XL-320 would be a good “default” version.

The USB connector is completely recessed in the volume given earlier, and will have additional strain relief to make sure no amount of banging the thing (robot falling, vibrations, …) can break or disconnect it.

I’ll post more info when it’s ordered, I still have some routing left to do.
Other than that, I design a LOT of other little boards that will complement it, I’ll get back to them later too - maybe when I receive the PCBs so that I have pictures instead of a lame description like this one :stuck_out_tongue:

2 Likes
9

Sounds very great ! is it Open Source ? Are you using eagle to make it ? Or maybe circuitmaker (very easy to share work) ?
Do you plan to plug it only with USB or do you want to add other possibilities (UART ? I2C ? SPI ?)

So how can you manage full or half duplex ?

10

I have used Eagle this time fr these boards. I’m still not really sold on Circuitmaker - and I have a standard license of Eagle so I’m not too fond of changing right now… :confused:

The interface is aimed specifically at USB, and I went to the trouble of making it USB 2.0 High-speed (480Mbps instead of the 12Mbps of the USB2AX), which imposed a higher-cost and bigger MCU than what I would have used otherwise.

Mechanically, the whole shape of the thing is organized around the USB Micro plug, like this :

PCB_stack.png921×588 17.2 KB

What would you have wanted to do with I2C or SPI here? using these interfaces to talk on the Dynamixel bus as a Master?

Because I have made (it’s in the same panel currently being fabricated) a generic Dynamixel thingy, that I imagine more useful as a Device, but could run a 1-dxl-line version of the Master software, and has, besides the Dxl line, serial, I2C, SPI, analog pins and PWM… more on this [here] (I’ll update to a link when it’s up).

The top plate receives 4 independent sets of TX, RX and Enable pins, plus 5V power and a “power_enable” signal that is used to turn power to the servos on or off (through a big MOSFET).
So yeah, if you wanted to, you could make a top plate that could accomodate full-duplex serial, to talk to Herkulex servos for example. But in that case you would have to change the firmware, since it’s resolutly aimed at half-duplex dynamixels. Changing from half-duplex TTL to half-duplex RS485 would however be completely transparent to the firmware.

I strongly lean towards it.

11

Ok, so that’s it, I pushed the files to github if you want to have a look : https://github.com/Xevel/usb2ax_pro

The PCBs look like this :

usb2ax_pro_v1.0.png627×840 135 KB

And there is a good chance that on your screen it looks much bigger than it really is (32x44mm).

The top PCB, on the right, has 6 3-pin TTL Dynamixel connectors, two pairs of which are connected together.
Each of the 4 Dxl lines has its own level shifter (the MCU runs at 3V3), and protection against ESD and over-current. Like on the USB2AX, shorting DATA to +12V will not harm the MCU or the computer. It is however a different protection that I designed around a JFET, and it should be comfortable protecting from up to +/- 25V while allowing 3Mbps communication the rest of the time. The protection used in the USB2AX had problems going too fast. We’ll see how it works out in the field.

It also has a big screw terminal (rated 16A) and a big MOSFET (DMP4015SK3-13) piloted by the MCU that controls power from the screw terminal. This power goes only to the servos, the MCU itself is powered from USB.

On the Main board are the MCU (an ATSAM3U1CA-AU, 96MHz, 64K FLASH with integrated USB2.0 High-Speed PHY, QFP-100) with its crystal, Micro USB connector, MPU-6050 IMU, 32KB of EEPROM, 3 leds and a button.
There are some gpios broken out on pads on the bottom but they are only intended for debugging (the 7 thin and wide pads on the bottom right of the pic) and might disapear in following versions to make the back of the PCB completely isolated. There is also a SWD + SWO port for programming/debugging.

There is also a voltage divider to measure voltage on the Dxl bus before the MOSFET (so you can monitor voltage before turning the servos on). You could also use that to see when power is lost and react accordingly (this way the robot would not jump when power returns).

Mechanical

The boards are connected by a standard 2x10-pins 1.27mm connector that keeps the PCBs 6mm from each others. The rest of the mechanical connection between the two will be done by 2 or 3 threaded nylon standofs with M3 nylon screws both on top and bottom, and small 3D printed part that will clamp on the USB cable to provide additional strain relief.
To attach the product to anything, you can remove any screw and replace it by a longer one that would also go through the plate you want to attach it to.

The USB cable can be changed at will (the space is big enough to accommodate any type of cable I have seen, even the giant 3m double-shielded micro USB cables, that have connectors 1-2mm bigger in any direction than regular ones) to make it as long or short as needed.
If I go to production with this, I might have a custom cable 30cm long with 90° USB connectors on the PC side, so that plugging it in a RPi would not require an additional 5cm of additional space (I’m sure in the head of a robot it can be important…).

Things to improve

One thing I’m not too happy about is that right now there is no reverse-polarity protection on the power input. The thing is that it cost a lot to do it without sacrificing efficiency (these low Rds_on MOSFETs can cost 1€/pc) and and they take a lot of board space.

The name is not very inspired either.

Lastly, I would have loved to add a second screw terminal and circuitry for hot-swapping power source, but I guess this will have to go on another board. It makes sense to make the hot-swap board as close as possible to the power sources anyway.

In terms of user feedback and interaction, one button and 3 leds might not be enough for everybody.
I added the EEPROM as a way to store motion files and poses, but I do not intend this board to be used as a standalone like the boards made by Robotis (CM-730, OpenCM9.04) or Trossen Robotics (various Arbotix Robocontrollers).
I was more thinking about it as a “start” button tat the host computer could poll.

There, I’m interested in any feedback. The software part should be the really fun part here, if I keep motivated for long enough to achieve all I have in mind. In any case, this board should have enough power to run everything I talked about in this thread.

1 Like
12

The PCB panel with, among other things, the USB2AX Pro, has arrived today, a few days in advance :slight_smile:

New photo by Nicolas Saugnier

Just have to wait for the MCU now, that I had to order at Arrow and Schukat instead of the usual distributor. That’s the thing after having used Farnell for so long, with their <24h free delivery, everything else seems so slow.

13

Good, if I resume the differences with the actual USB2AX :
_ The possibility to put different motors (AX, MX, XL , XM…)
_ The possibility to run a loop at high frequency on the MCU. So you can retrieve values from servo very close to real time.
_ A high speed USB, so you can ask any values store in the MCU with a low latency time. For example, if you need to have a present position with Pypot, you just need to read a MCU register wich is really faster than asking all the servo on the bus.
_ An IMU with possibility to put a firmware to calcul positions.

Tell me if I wrote something wrong :wink:

About your MCU, I have a warning on Mouser : “End of Life: Scheduled for obsolescence and will be discontinued by the manufacturer.”

14

That’s not exactly right, but given that it’s not implemented yet and I have been rambling about it, I can’t blame you ^^

Depends on the top PCB used. one could be full TTL, the other full RS-485, and another version with all the different types.
The first version, that I have the PCBs for right now, uses only 6 TTL connectors (for AX/MX-T).

Yes, but it goes beyond that. With the idea of having a specific deamon/process running on the host to listen from the stream of data collected by the USB2AX Pro, the values could be stored directly on the computer, making data retrieval close to instantaneous. The host would not ask for the data, just listen to the interface that would send it continuously. Of course, that would be rather different from anything that exists so far.

The differences do not stop there :slight_smile:

  • Up to 3Mbps (maye more but I have to check when I write the code) instead of 1Mbps
  • power input for servos, controlled by mosfet
  • lots of EEPROM to store poses and whatnot
  • a cable to put the device where you want it, and not risk to break it when it falls
  • a button
  • one more LED

Isn’t that about the A version? thay have the B version out now.
EDIT: Yeah, the ATSAM3U1CA-AU is End-Of-Life, but the ATSAM3U1CB-AU is not.

15

Assembled, but missing the mechanical components (standoffs, and a 3D printed strain relief):

IMG_20160927_205841.jpg3286×2432 1.06 MB
IMG_20160927_205855.jpg3286×2432 887 KB
IMG_20160927_205908.jpg3286×2432 1020 KB
IMG_20160927_205826.jpg3286×2432 1.2 MB

And the album with more pictures of assembly and the rest of the projects on my panel : https://goo.gl/photos/49VdDNXw41NjZAnB9

3 Likes
16

Are you using a home made oven to solder the components ?

IMG_20160927_193140.jpg914×676 107 KB

17

I got the cheapest small oven with convection (“chaleur tournante” en parlance marketing francais) that I could find on amazon at the time (50€ shipped), and just added a thermocouple on a multimeter to show the current temperature.
I’m quite OK with losing the 5 minutes it takes to manage that myself instead of having a PID. I only bake boards at most a 1-2 times a month, for prototyping. A PID is not worth investing in unless you do production.

And I can routinely do 0201 and sometimes BGAs with that setup.

18

And the final pictures, with all the hardware parts (nylon standoffs, plus 3D printed strain relief):

IMG_20160928_133242.jpg3286×2432 1.02 MB
IMG_20160928_133259.jpg3286×2432 856 KB
IMG_20160928_133819.jpg2432×3286 932 KB
IMG_20160928_133354.jpg3286×2432 950 KB

Album for just the USB2AX Pro : https://goo.gl/photos/dQTakCDif3eE8Ge48

3 Likes
19

Very nice idea about the USB connector. It really seems more robust.

20

I saw you did put an IMU inside !! Thank you ! :wink:
What are the RGB leds for ? for making magic lighting ?