Unreliable communication with low baudrate on Leonardo I am using an Arduino Leonardo (more precisely this product), to communicate with servo-motors) using RS485.

Everything works fine as long as I don't go below a baud rate or 115200bps. If I go below, as 57600 or 9600, I start to get ill-formed packets from my motors: the 4 first bytes are usually correct, but the end of the packet contains incoherent data, and the checksum is obviously wrong.

I am using IndustrialShields (my PLC/Arduino vendor) library for RS485, and I don't see any mention of this problem.
I am using Half-duplex communication, with U2X if I correcly understand the source code of the library.

Note that the documentation of the servo-motors mentions there is a small error margin on the clock for low baud rates, but since it works with 115200bps, which has the highest error margin, it shouldn't be a problem.

Also the motors seems to understand the packet I send, but I do not receive their packet correctly.

Is there an edge-case I am not aware of? Sorry for the lack of details, I am not sure what else I can say.
I suspect that the RS-485 interface in your servo is what is at fault.  Nothing to do with the Arduino or your communication, or software.

Without knowing more about the servos and how they are wired internally it's hard to be certain, but I can assume:


The servo has some kind of controller in it which communicates over the bus
That controller may or may not directly control the direction pin on its interface


It's the latter that is critical. There is a way of wiring up a MAX485 that automatically controls the direction pin - immediately you start sending data it asserts it into TX mode. The trouble comes when switching back to RX mode - there's a few ways of doing that:


Shortly after the last bit of a certain value (0 or 1) has been sent (the bit stream keeps a capacitor charged)
A certain time after the start of communication.


The first method is usually more reliable across multiple baud rates, but can be sensitive to the values of the bytes sent - if it relies on a 1 being sent to keep the capacitor charged and a number of 0 bytes are being sent it won't see the 1 that keeps the transmit mode open, and it can close prematurely.

The second method is more reliable for fixed length packets, but will only work for a certain (or small range) of baud rates. If sending a packet takes longer than the allotted window then it will truncate regardless.

However if the controller in the servo is itself directly controlling the data direction pin then it could be that there is a bug in its firmware. Maybe it's working on a delay principle and they got the time calculations wrong.  Maybe it's working on a "queue being empty" principle and they forgot about there being a hardware buffer that also needs to empty, but high baud rates just manage to squeeze through in time. 

It's impossible to be sure, but going by the symptoms you describe those seem to be the most logical scenarios.