GoPiGo3 API Concepts

GoPiGo
1

Reading the “in progress” GoPiGo3 doc at read_the_docs and github_GoPiGo3 shook me up a bit.

One of the unique features of the GoPiGo is the availability of programming examples in multiple languages. Another strength of the GoPiGo as a platform “was” the establishment of a simple API upon which users could build behaviors that other users could directly use.

While I was expecting that DI would at some point release a Classes version of the Function based Python API, my expectation was that it would be mostly cosmetic - a Class around the Function APIs, with Class constants, and setters/getters for Class vars.

The gopigo3.py class methods use hardware layer parameters and units, and above that seems to be the EasyGoPiGo3.py classes that use robot/world parameters and units. The shock is that the simple functional API of the (GoPiGo/)gopigo.py is totally re-imagined.

Evolution is inevitable, and I do see beauty in the new interface design. I just wasn’t expecting this much change.

(I was also hoping that all method defs would be documented in-line with allowed values, ranges, and units, or documented at the top of the module.)

2

Hi @cyclicalobsessive,

Let me comment on what you’ve said.

Evolution is inevitable, and I do see beauty in the new interface design.

Evolution can be seen as an optimization algorithm.
As time passes, anything will get more complex on the smaller scale, but simpler on the bigger picture.

While I was expecting that DI would at some point release a Classes version of the Function based Python API, my expectation … etc.

I’m not sure if that’s a good thing for you or not.
For us, it’s certainly one step ahead of the game.

I was also hoping that all method defs would be documented in-line with allowed values … etc.

I’m quite happy you’ve brought this subject up in the discussion.
So, at the moment, we’re currently working on the documentation for the GoPiGo3 and will be released really soon.

Thank you!

1 Like