Adding support for Adafruit PCA9685 servo controller

[zuccon]

This PR adds support for building a Brachiograph using an Adafruit PCA9685 I2C controller instead of pigpio.
More background information in the README

Some refactoring has been done to avoid code duplication:

• The Plotter class has been split into a common subclass and hardware-specific classes.
• Virtual mode is now just another hw-specific class.

Documentation will be updated if the change is accepted. In that case, also how to build a PCA9685-based Brachiograph will be documented.

Thanks for the Brachiograph fun!

[evildmp]

Thanks, this is great to see, I have no way of testing this right now, but I am doing some work on the project so let me think about this a bit to see how to incorporate this approach.

[NonaSuomy]

Was this ever included?
It is a fairly priced module https://www.aliexpress.com/w/wholesale-pca9685.html?catId=0&initiative_id=AS_20230603063046&SearchText=pca9685&spm=a2g0o.home.1000002.0

[LouDou]

I would also like to see this merged; unfortunately it doesn't rebase on master. Also, before I noticed this PR I also made similar changes, to be able to swap out the hardware driver part. I wrote a simple adapter to use the same Adafruit libraries. My branch is based on master as of today:

https://github.com/LouDou/BrachioGraph/tree/feature/basic-pca6985

[philippejadin]

Hello and first of all thank you for this incredibly cool project!

This is a great pull request imho, I'm looking at adding another driver, using any arduino compatible board to drive the servos, and thus making the project usable on any kind of computer instead of only raspberry pi with gpio's.

@evildmp Any chance this PR can be merged to allow additional drivers to be defined?

[philippejadin]

Digging this a bit more, this pull request is too out of date compared to the current state of the code, and imvho the other mentioned one is a bit hard to follow probably because there is not a clean separation between hardware specific driver and the supposedly "pure" drawing code which would not need to know anything about drivers (for example on what pins a servo is connected).
I'm not a python expert but I could try to propose a solution. Would there be interest to discuss how to do this the cleanest way?

[philippejadin]

A last comment on this hopefully. I did a quick and dirty hack that allows to run the servos using an arduino, it works quite fine already, here is the minimal amount of code changes to make it work :
master...philippejadin:BrachioGraph:arduino

If I don't get a reply (which I'd completely understand, the author might have other ideas for the project or most probably other stuff to do), I think I'll create a separate project with support for gcodes as input.

[evildmp]

@philippejadin @LouDou @zuccon

Thank you for your efforts and attention. I have been able to spend a little time working on the project lately, but it's whole a hobby project.

I would like to find a way to incorporate your work. Two issues:

First, I have no way of testing it or understanding some of the implications of the changes, so I think we would need to talk more about that.

Then, I would like to find a way to abstract as much as possible from the hardware and hardware controller implementations, so that future changes I make are not blocked by/don't break the changes to support different hardware. But I also don't want to introduce architectural complexity!

[zuccon]

Digging this a bit more, this pull request is too out of date compared to the current state of the code, and imvho the other mentioned one is a bit hard to follow probably because there is not a clean separation between hardware specific driver and the supposedly "pure" drawing code which would not need to know anything about drivers (for example on what pins a servo is connected). I'm not a python expert but I could try to propose a solution. Would there be interest to discuss how to do this the cleanest way?

@philippejadin I'm down to discuss and then rebase this; I'll do some rebasing following the logic I used for this PR, which aims indeed at separating the device (virtual, gpio, external controller) from the drawing logic, feel free to jump in when you have time.
Could you point me to you code please?

[zuccon]

@philippejadin @LouDou @zuccon

Thank you for your efforts and attention. I have been able to spend a little time working on the project lately, but it's whole a hobby project.

I would like to find a way to incorporate your work. Two issues:

First, I have no way of testing it or understanding some of the implications of the changes, so I think we would need to talk more about that.

Since we are splitting hardware classes, testing regression for the drawing logic, virtual and gpio driver should be possible using the standard build.

Then, I would like to find a way to abstract as much as possible from the hardware and hardware controller implementations, so that future changes I make are not blocked by/don't break the changes to support different hardware. But I also don't want to introduce architectural complexity!

I'll attempt this and update.

[philippejadin]

Here is the code I did : master...philippejadin:BrachioGraph:arduino

And here is a completely separate implementation trying to use a computer running python code to send values to an arduino using telemetrix (a new iteration of the firmata idea).

https://github.com/philippejadin/armbot

Frankly, it's not easy to find a way that solves all the problems for every use cases, so maybe it's a pipe dream :)

In all cases thank you for the project and for trying to merge external ideas !

[zuccon]

Here is the code I did : master...philippejadin:BrachioGraph:arduino

And here is a completely separate implementation trying to use a computer running python code to send values to an arduino using telemetrix (a new iteration of the firmata idea).

https://github.com/philippejadin/armbot

Frankly, it's not easy to find a way that solves all the problems for every use cases, so maybe it's a pipe dream :)

Maybe it's not a dream after all, do you think it could work this way?

here you select the hardware you wanna use:

BrachioGraph/brachiograph.py

Line 7 in 2d9c25f

mode = "pigpio", # machine mode: [pigpio|PCA9685|virtual]

Which then imports the right class:

BrachioGraph/brachiograph.py

Line 33 in 2d9c25f

if mode == "PCA9685":

Maybe there's a better way to do this, but this change already separates logic from hardware, so you may just put hardware-specific Plotter class in a file and add the selector here and it should work.

wdyt?