[QUESTION] How does proposed class structure cope with differing capabilities of boards?

[kierdavis]

How does the j5's class structure cope with the fact that in some environments (i.e. competitions) two APIs are physically implemented by two different boards, while in other environments they are implemented by the same board?

As a concrete example, Student Robotics provides a servo interface via a servo board and a GPIO interface via an Arduino, but Source Bots provides both of these interfaces via an Arduino (with an attached servo driver shield). Therefore code to operate a servo may look like:

robot.servo_boards[0].servos[0] = position

in a Student Robotics environment while looking like:

robot.arduinos[0].servos[0] = position

in a Source Bots environment. This inconsistency feels counterproductive to the goal of j5.

As another example, Arduinos run different firmwares in different environments: the Source Bots Arduino firmware has builtin support for ultrasound sensors while the Student Robotics firmware does not.

[kierdavis]

My preferred solution to this would be for abstract the concept of "boards" away from the end user. As such the code to operate a servo would look like:

robot.servos[0] = position

in all environments; it is then the job of the environment-specific Robot implementation to determine which physical board this request should be delivered to. Similarly, a Source Bots Robot class would have a read_ultrasound method (or something along those lines) while a Student Robotics Robot class would not.

I'm working on a rough draft of how a class structure based on this concept would look - if it comes to fruition I'll post it in a later comment.

[trickeydan]

I'm tempted to suggest that we support both methods of accessing them. The main issue I see is working out how to address the components

[trickeydan]

https://gist.github.com/kierdavis/d4114454aa655c974eb5ce0c55988615

My thoughts:

• I really like the term Environment over a BackendGroup, it is much clearer what is going on from this name. I might even add a PR to change it to that.
• The current class structure supports what you've done:

class Robot:
   self._servo_board = SBServoAssembly(_backend_group)
   self.servos = self._servo_board.servos

Still open to changes in the class structure to be clear, just wanted to make it clear that this is fundamentally very similar.

[trickeydan]

Okay I just renamed them all...