Poppy 1.1 : Hipi

Technology
,
81

Actually we work on installation process of poppy robots,
I imagine a way to setup the sc16is7xx driver easily. I will create a .ko for each actual kernel (4.2 or more) revision and put it on a repo as release with a specific name depending on the kernel revision. After that we could link travis to raspberry kernel repository and generate a new .ko release for each kernel revision available.
On the same repo we put a bash script who select the release depending on the kernel revision of the raspberry and setting it up. This script can be called easily with a simple command line and this is not dependant of a complete poppy robot.

@sonel :

  • What do yothis distribution processbution process?
  • I still have a compilation problem. Actualy I have to remove each #ifdef CONFIG_SERIAL_SC16IS7XX_SPI, how do you manage it?
82

I have this at the top of the c source:

#define CONFIG_SERIAL_SC16IS7XX_SPI

In my case it seems to work. If I comment that define and run a make clean and then make I get the 3 warnings during compiling and the ko file is 6552 bytes.

When I put the define back in there are no more warnings in the compilation and the ko file is 24952 bytes - clearly the #ifdef are considered.

Yes, it probably will work. We might also consider putting an EEPROM on the board and certifying it as a HAT. That would mean the drivers will have to be included in the standard distributions for Raspberry Pi. For instance Iā€™ve seen some cards from Adafruit (like the PiTFT 2.8) come with overlays and koā€™s in the standard distribution of system. But for the time being precompiling them for each kernel version and using a script to do the installation might be easier. Keep in mind that also the dtb needs to be different (at least the name) for the 4.4> versions (extension dtbo and no ā€œ-overlayā€ in the name).

Have you yet testing it with a 241 on the Dynamixel chain? I hooked it up last night but couldnā€™t make it communicate. I suspect itā€™s because of the fact we havenā€™t set the chip in RS485 mode - so that the RTS pin controls the communication direction. I canā€™t figure out how that is done through the driver.

83

@Nicolas here is what I managed about setting up the RS485 mode:

first you need the version 3 of pyserial. Run pip list and check for the version you have installed. If it is 2.x then you need to upgrade - the RS485 support is only included in version 3:

pip install --upgrade pyserial

Then there is a bug in serialposix.py source that will throw some errors. They are fixed in the source but that is not included in the official release. So youā€™ll need to download the code and replace it in the local distribution package:

curl -o serialposix.py https://raw.githubusercontent.com/pyserial/pyserial/master/serial/serialposix.py
sudo cp serialposix.py /usr/local/lib/python2.7/dist-packages/serial/serialposix.py
sudo cp serialposix.py /usr/lib/python3/dist-packages/serial/serialposix.py
sudo cp serialposix.py /usr/lib/python2.7/dist-packages/serial/serialposix.py

Iā€™m using curl instead of wget because the later gives me a TSL error. Iā€™ve seen some other people complaining by this on the Raspberry Pi forum.

Then the way to use it in python is the following:

import pypot.dynamixel
import serial.rs485
dxl = pypot.dynamixel.DxlIO('/dev/ttySC0', 1000000)
dxl._serial.rs485_mode = serial.rs485.RS485Settings(delay_before_tx=0, delay_before_rx=0)

In principle after this the chip should be in RS485 mode and the RTS pin should control the direction.
Unfortunately in my case it still doesnā€™t communicate with the servo. And I have no oscilloscope to test if the RTS pin works fine. Can you check this part?

84

I was wonrking on the same issueā€¦
To pull the good pyserial revision you can do :

pip install git+https://github.com/pyserial/pyserial.git

You should have the 3.1a0 version with this.

For begin I just try to move the rts line with this :

import serial.rs485
ser = serial.Serial('/dev/ttySC0', 921600, timeout=0.5)
ser.rs485_mode = serial.rs485.RS485Settings(delay_before_tx=0, delay_before_rx=0)
ser.write('voila')
>5
ser.read(5)
>'voila'

That sound good!
Now I have to manage it with SN74!

2 Likes
85

Obviously I donā€™t have any SN74LVC2G so I do something equivalent with some 74LVC1G and SN14LVC1G.

To check the signal integrity of the output signal I plug the output data line in a complete old and crapy poppy humanoid and send a random byte.

Thatā€™s good!

Blue line is TX out of sc16is7xx
Yellow line is RX in sc16is7xx
Pink line is data line

Next step find a way to match with a motor baudrateā€¦

86

I found a poppy arm somewere with 3 MX-28 motors, I change theire baudrate to 38461 because my sc16is7xx can run at 38400ā€¦

import pypot.dynamixel
import serial.rs485
dxl = pypot.dynamixel.DxlIO('/dev/ttySC0', 38400)
dxl._serial.rs485_mode = serial.rs485.RS485Settings(delay_before_tx=0, delay_before_rx=0)
dxl.scan(range(52,55))
>[52, 53, 54]

Here is the complete transaction :

Here is the first motor messages :

@sonel, if you deal with xl320 you have to use Dxl320IO instead of DxlIO
try with this :

import pypot.dynamixel
import serial.rs485
dxl = pypot.dynamixel.Dxl320IO('/dev/ttySC0', 1000000)
dxl._serial.rs485_mode = serial.rs485.RS485Settings(delay_before_tx=0, delay_before_rx=0)
87

Cool, looks good!

I was using a AX-12A so the DxlIO is fine. I probably need to look at the connections again.

If you have a crystal available 32 or 16MHz you might also hack the board so that you can also do some performance testing - see how long the packets take to go back and forth. If everything looks fine weā€™re good to go for the prototype batch.

Donā€™t forget to change the circuit design to include the IRQ connection before sending the production order.

88

Thankā€™s @sonel, I donā€™t have crystal nowā€¦

I send the production of the prototype yesterday with the IRQ connection ok, I should receive it at begining of may!

1 Like
89

Iā€™m just teasing :slight_smile:

hipi-teaser.jpg1944Ɨ2592 648 KB

3 Likes
90

Rrrrrrr, thatā€™s a bad hit for those waiting for a final release !
Hope you will tease us more :wink:

91

Waiting to embed on Droneā€¦

92

As @damien mentioned it before , we have the 2 first Hipi prototypes. These boards have been produced by CircuitHub but CiruitHub have failed in the Raspberry connector mounting, they mounted it reversedā€¦ I canā€™t mount it on a RPI for now and reverse this connector is a really tricky thingā€¦

Anyway I start to test each functionality (with wire) of this board step by step :

  • [] Power conversion => TOO noisy
  • [*] Audio amplifier
  • [*] Driver of sc16is752
  • [*] Apparition of /dev/ttySC0 and SC1
  • [*] TTL Communication with motors at 1000000
  • [] RS485 Communication with motors at 1000000
  • [] IMU
  • [] Mechanical integration

I will update this topic and check this boxes to keep everybody in touch.

2 Likes
93

I have had the opportunity to see it, touch it and bear it. Itā€™s wonderful :slight_smile:
Can t wait to distribute this boards in the community :wink:

1 Like
94

Brilliant!:rage:

If youā€™re itching to test it you can try some male-female cables. There are not that many pins connected from the GPIO.

45073-IMG_2066.jpg800Ɨ600 34.6 KB

95

And waiting for a biped robot! =] Iā€™ll be patient, Iā€™ve a lot of projectsā€¦

96

Thatā€™s exactly what I am doing,

Now I can detect sc16is752 and see /dev/ttySC* but when I send something nothing happend on data side of the ttlmotor connector.
I think I switch the logic direction of RTSā€¦

Indeed, if I switch the RTS logic
With pyserial > 3

import serial
import serial.rs485
ser = serial.Serial('/dev/ttySC0', 1000000, timeout=0.5)
ser.rs485_mode = serial.rs485.RS485Settings(rts_level_for_tx=False, rts_level_for_rx=True, delay_before_tx=0, delay_before_rx=0)

I got something in the output.

Mistake list :

  • I have mounted the TTL connector reversed because the 3D view on CircuitMaker is reversed and the one pin of robotis is not the 1 pin of the connector but the last oneā€¦ I will need to make it easyer for users. I plug it on a robot so the 5V push/pull output of the driver has been short-circuited to GNDā€¦ Hipi continuing to work
  • I short circuit GND and power input with my oscilloscope, but Iā€™m lucky a 0Homs resistor suicied itself to save the rest of the board
  • The COUT capacitor of the alimentation work at 4v, so the capacitance could be really bad at 5vā€¦ I change it with a bigger capacitorworking at 16V but the output steel crappy. I also try on the second Hipi but it steel noisy. I can catch some 200mv glitch without nothing mounted on the board
97

I wrote in a post earlier on the 1st of April how the 2G241 should be connected - and I think it was wrong. By default the RTS is low for TX and high for RX (page 33 in manual) so the 2G241 should be used 1A/1Y for TX (active low) and 2A/2Y for RX (active high). This way you donā€™t need to change the direction in software. Itā€™s more intuitive to use.

If you still have ripples that big you might have some sort of a short on the board. I havenā€™t checked the oscillator on the power source (thatā€™s why I use the Murataā€¦) but I will look at the calculations. 47uF at the output should be more than enough - although indeed is should be at least at double the output voltage (so minimum 10V).

98

Yes I will switch it for the next version.

I succeed to communicate with motors of a torso humanoid and the signal is pretty good :

import pypot.dynamixel
import serial.rs485
dxl = pypot.dynamixel.DxlIO('/dev/ttySC0', 1000000)
dxl._serial.rs485_mode = serial.rs485.RS485Settings(rts_level_for_tx=False, rts_level_for_rx=True, delay_before_tx=0, delay_before_rx=0)
test = dxl.scan(range(30,55))
print test

[31, 32, 33, 34, 35, 36, 37, 41, 42, 43, 44, 51, 52, 53, 54]

5 Likes
99

The circuitmaker model for TTL connector I used, seems to be good (thought that doc. mention connector shape and not cable shape) USB2Dynamixel) .

Pasted image1366Ɨ768 230 KB

ttl.jpg852Ɨ720 99.6 KB

Pasted image1366Ɨ768 90.7 KB

1 Like
100

I mount a Raspberry Pi 3 with a Hipi board on the head of an humanoid robot and I add a screen on it.

The humanoid with a current version of Pypot and a Hipi have an extremely strange behavior! Thankā€™s to @Pierre we understand why.
In a Poppy humanoid robot we have 2 motors network (1 for legs, 1 for torso). Pypot create 2 threads to manage each UART simultaneously but in reality both use the same device (SPI) and if one of the UARD deice use The SPI driver The other one will be dropped.

@Pierre add a lock rule to avoid this kind of problem, and now itā€™s working.

We still having some strange things probably due to overheating on the headā€¦

3 Likes