Using Pan Tilt Hat with two axis camera mount pre assembled. I’m using only the two servos and not the light bar. On RPi 3. Not your standard configuration in several ways. I already have items plugged into the GPIO header, so I can’t mount the PCB on the header. I have wired from header 3v, 5v and gnd to the pcb farside where I put pins in Power and I2C. I am using I2C-1, so I wired GPIO_2 SDA and GPIO_3 SCL to the I2C pad pins. Next I’m writing in C. I have a working I2C library from other work. I implemented the functions as shown in panthilt-hat-master/library/pantilthat/pantilt.py. The code runs, the I2C slave chip responds. i2cdetect finds the chip. i2cdump will show the registers used (0, 1 & 3) have expected values. Eg, enabling both puts 0x3 in reg 0. Setting position to 1449 us (centered) puts 0x05a9 in Reg 1,2. The supplied servos work with other code and direct connect to pwm0. Another servo of mine doesn’t work either with the hat. My servo will vibrate and shake, but not otherwise respond. Your servos have no feeling of moving or trying. I have verified 3v and 5v supply on the board, but have not/cannot look at the pwm signals. Some thing I think about: with out the hat on the expansion connector are all the required connections made with just wires from J8-2 5v, J8-1 3.3v, J8-6 GND, J8-3 i2c-1 SDA, J8-5 i2c-1 SCL individually to farside POWER and I2C pads? That is, the board should work if not plugged in but is wired like that. Please advise. I’m out of ideas.
You will likely need to wire up all the grounds marked with a black blob show here.
Thanks for the reply. Did that as suggested. No joy.
But progress. I gave up on my other circuit, ripped it out, installed the hat as directed, so it is the only thing on the expansion header. Futzed around and made the Python example smooth.py work. So its not the hardware.
That leaves my C code. I studied all the visible Python code I can find. I found an update register that I haven’t hit, but that seems to be only associated with the lights, which I am not using. I think I don’t need to use this register.
I found timeouts associated with the servos. This is set to 2 seconds and is labelled for power saving. It disables the servos when not used. I don’t do that. I could do that. I don’t think that has anything to do currently with my code not working.
Is there anything under the covers in the pantilthat package that I can’t see in those sources? Eg., is there a binary file that it has to load each time it starts up? I don’t think so. I don’t see any sign of that.
Is there any required delay between writing on the I2C bus? Some implementations may require the user to leave the controller alone while it implements a function. I don’t see any sign of that. I added a 1 second delay after every write and it did not make any difference.
I don’t see any means to set the frequency for the servos. The API doesn’t seem to expose such a capability. It works for your servos with your Python code. Is it setting that somehow that I can’t see and I need to do it too? I don’t see any sign of that. Again, I’m groping for stuff I didn’t see and have missed.
I only write enables to Reg 0 and position in usec to Reg 1 and Reg 3. It looks like the position as a word has the high byte in Reg 1 and the low byte in Reg 2. That seems to be the standard I2C bus meaning for writing a word. That’s what I do. It seems that’s what your Python I2C write a word does. If I’m wrong that could account for the servos being unhappy with their commands.
You don’t publish in C, but have you seen any other user’s reporting running in C?
Your patience is appreciated. I really really don’t want to mix Python for platform control with my C for vision and the camera.
I don’t work for Pimoroni, just so you know. I have 2 pan tilts. Both are running motion eye OS, and Python code. I have no C skills. =(
well ok enough. Thanks for speaking up to help.
I used i2cdump to watch what smooth.py wrote to the position registers. It writes low byte then high byte. I had it backwards. When I swap bytes before writing the word, the pan axis works correctly. I think that was the mistake all along.
That’s good to hear, your moving forward now. :)