Here a small board which seems to do the TTL conversion :
http://www.dx.com/fr/p/3v-5v-serial-port-rs232-to-ttl-converter-module-340324?tc=EUR&gclid=CM3_wZ2EmssCFYofwwodvb8H2Q
Apparently only with one IC (and probably a cheap one), I didn’t find any documentation…
Other informations for full duplex to half duplex here : http://circuitcellar.com/cc-blog/one-wire-rs-232-half-duplex-ee-tip-135/
Not totally understandable for me but maybe it can give ideas to you 
I read a rumor saying RPI3 is coming end of march, they say 64 bits, wifi chip & buetooth low energy integrated.
@Nicolas @Theo when you have time, could you give an update on what you think is the cause the communication problem? and what you have been testing? (here or another post, we are all (at least me), really curious about it.
Do you think the voltage not going down to zero, but rather 0.7, could be the source of the problem? The detection threshold should be above that.
If you moved to 200Ohm for the pull-up: the lower the pull-up resistor the more you have a voltage divider effect when pulled to zero with the wire resistance of other resistance along the way. A 30Ohm resistance on the way would make this 0.7 V difference, with 10 motors it might not be that impossible.
Have you tried measuring with 1, 2, 3, …15 motors to see the difference in the signal?
The post of @juju also raise some good questions: Informations sur la carte pixl (raspberry Pi - XL320)
We don’t have a formal proof about that but this is the only difference between Pixl and other system. Also, we have made the same circuit with a lower quality component to increase the zero shift so the communication is completely unusable.
In deed but the Rdson of T3 (in parrallel of your 30Ohm) should decrease drasticaly the voltage divider effect. But you’re probably right because our component have an extra hight Rdson (7.5Ohm => 3.5%). If each motor have a small leakage current this Rdson can have a really big effect. We should select a component with a lower one to reduce the shift.
I’m not sure, because you can use this tricks to build a bidirectional level shifter like the sparkun one. The only difference here that we drive the LV input always to 0.
We will try some other circuit, we keep you in touch.
Hi,
I had a look on Hipi on circuitmaker, You added an imu and an audio amplifier, it is wonderful 
Can’t wait to have one in my hand !!!
Indeed, I also plan to have a port to add start/stop button and/or batteries.
If you have specific need for your creatures please share it with me!
Sure to plug batteries and also 7,5V to power the xl-320.
For other sensor, I plan to use arduino (T°C, Distance, …) and to send the data to the raspberry through usb.
This http://pulsedlight3d.com/ , I’d like to add to sense the surrounding.
please don’t add too much and allow GenerationRobot to sell v1.0 
Hi, how many Dynamixel XL-320 could power this board? I would create a robot using up to 20 servos, could it be possible?
I don’t know for this board, because never tested (it has never been produced at the moment, developpement stage). But with the pixl board, I run 23 XL-320 without trouble. You also need to have the good power supply, because the board is just relaying your power supply.
Is the Pixl board available somewhere ?
I really want to use at least pypot and my XL320 and I don’t know the best current solution.
Edit: I’m a bit surprised that you use 23 xl 320 as it was designed for a max of 8 motors.
Did you modified something ?
Well according to @Nicolas the maximum servo you could use with Pixl is 8 Informations sur la carte pixl (raspberry Pi - XL320)
I would power the Darwin Mini with a Raspberry Pi 3 type B (Wifi, BT, compute power…).
Do you consider to support Raspberry Pi 3 for the hipi board?
Yes indeed with more than 8 motors the communication could be noisy, the power is not the problem and 23 motor should be ok in a power point of view! @juju do you have any trouble on communication with 23 motors?
Actually the Pixel is in pre-production state, we plan to sell it with génération robot soon!
The Pi 3 will be compatible with the Hipi but we have to disable bluetooth to manage it (for now).
The Hipi will be designed to be more flexible and it will support more motors. I will probably update the hipi topic at the beginning of the next week
The bluetooth is on the serial port ?
Nicolas,
I just finally opened the Hipi design and it’s really exiting! I was looking to do the same thing - I even got the delivery of the SC16IS762 (yes, I went for the full steam ones…) early this week and I was planning to start prototyping. Bypassing the USB and using the SPI for interfacing to Pi should make it fly…
Now that I see your design I think it would be cool to pitch in.
Here are some suggestions:
you need to change the crystal; at 14.746 MHz you will not be able to get even 1mbps with the UARTs. On page 16 on the data sheet you have the formula for the calculation of the divisor in respect to the desired baud rate. You can see that with a prescaler=1 the maximum you can get from a 14.746 MHz crystal is 921600bps (which is a standard baud rate, but not a good one for Dynamixel bus that is a little bit different). I suggest changing to a 32MHz crystal that will allow you to get all the Dynamixel rates - including 2Mbps – if we ever need that with the cool MX servos
the SC16IS752(62) is 5V tolerant (page 2 on the data sheet). This means you don’t need to implement level shifters 3.3 > 5V. Insead you can use some plain 74LVC2G241 (that are also very tiny) and just pass the RX/TX to the Dynamixel bus; I’ll talk about the 1OEx and the 2OE next
to control the direction the 2G241 uses the 1OE(neg) (active on 0) and 2OE (active on 1). This is very handy to switch from RX to TX; the trick is to use the RTS(neg) pin on the SC16IS to drive that direction. This is done by activating the RS485 mode (EFCR bit 4 - see page 33 in the data sheet). The choice is if we want to have the TX active on low (0) RTS (which is the default) and RX on high (1) > this will mean the 2G241 1A/1Y will be for TX and 2A/2Y for RX. The other option is to activate RS485 output inversion (EFCR bit 5) and then the logic will be the other way around - TX on high and RX on low meaning the buffers would need to be there other way around. I have already tested this approach with an FTDI chip that has a similar RS485 pin support (TXDEN) and works like a dream.
I think it would be good to add some protection on the dynamixel bus. There are lots of chips like the KBMF01SC6 - although I haven’t used this one yet.
have you managed to test the SC16IS chip on a Pi? I’ve been reading some bad things about the standard driver in the Linux kernel - but I’m not sure if the current kernel used by Debian Jessie uses the updated version of the driver
I would suggest to add also a pair of MAX485 (or some other producer) and include 4 pin RS connectors on the board. They won’t take too much space but will significantly increase the appeal of the board (Dynamixel Pro’s anyone?). They are driven exactly in the same way as the 2G241 and you can have a mix of TTL and RS servos on the same chain…
when it comes to connectors I would include at least 2 of the same connectors for the same bus (ex. 2 TTL and 2 RS485 on one UART). This way you can distribute the load on the chains and eliminate the need to have any hubs. With 2 UARTs and 2 connectors per UART we should be able to drive 4 chains - which is optimal.
I would also power the Molex connectors (right now you put the power through only to supply the 12>5V convertor) - this means no need for powered hubs. It makes the board a little bit trickier as we’ll have to deal with higher currents, but that is what Robotis did with the CM720/730 or the guys at Trossen with the Arbotix-Pro.
Sorry one more thing: I just noticed you still use the RPi UART (TXA, RXA). Why is that? Why not use the two UARTs from the SC16IS?
No trouble with 23 motors, but I did few tests. The average time for a pypot loop is about 20 ms. I plan to do more test soon.
Very interesting suggestions from @sonel. Especially the 2 types of connectors (RS and TTL) to give possibility to plug dynamixel pro.
On my side, for the power management, do you plan to give the possibility to power the board with 7.5V, (recommended voltage for XL series) - means the convector could also be 7.5> 5V ?
Because there is an audio amplifier, it could be good to add a entry for a microphone (I don’t know what GPIO it is possible to use to communicate with RPi). Very useful if you want to talk to your robot 
And last, adding a battery charger. Something very simple. When you switch the power off, put the power supply on the batteries connectors with a current limiting according with the batteries you use. And a green and red led to know when your batteries are charged. If you are interested I can fork the Hipi schematic and try to propose something to you.
For the IMU, do you plan to have a firmware for calculation on the board (calibration, derivation…) or do you just plan to have the raw data of the microchip ?
In general the switched convertors work fine in range of inputs and the one in Hipi should be fine with either 12V or 7.5V input.
Agree we need to do something about adding battery support. Though in my experience with other robots it is much more convenient to just allow hot-swap of the batteries by including 2 battery connectors and using a pair of very low forward voltage Schottky diodes (I’m using Vishay’s V10P45S - but anything that is rated for 10A and at least 30V with as low forward voltage as possible is good):
This way you can use as many batteries as you want and charge them on a dedicated charger that will most likely be capable to provide much more charging current than any circuit we would be able to put inside the robot.
In that design there is also a LiPo voltage checker - but I think this is not necessary as we can implement a loop in the software that reads the voltage from the servos and issues warnings in case the battery drops below a threshold.
I agree about the mic input. The way I did it before was to split the processing in two parts (two Raspberry PIs): one in the head that covers the vision and audio, and one in the chest that covers the motor control (including the Dynamixel network) and the IMU. A big advantage with this approach is that the IMU is not affected by the head movement and does not need to be constantly adjusted with the head position. The two Raspberry PIs should both connect via WiFi (this is why Raspi 3 is so exiting, the WiFi is built in and no need to add a dongle that adds space) and using ROS. That being said I’m still far from having something that really works with ROS in this setup.
Now, back to the video/audio the simplest way is to use USB cameras with mic and let the Raspi in the head use the mic for sound processing. Should work fine with OpenCV. The even more interesting thing is that we might be able to process data from 2 cameras - also meaning 2 mics, so not only we will be able to receive vocal commands, but also identify the direction. Here is a picture of the head of the previous robot:
You see the microphones that I desoldered from the camera boards and moved them to the sides to improve the spatial recognition.