Purpose

This meeting is to discuss LOS architecture decisions, specifically, to answer these questions:

1. Should we eliminate the singleton nature of our drivers now that there is an interface (LOS_Interface) separating ZP3 code and the drivers.

   1. Of course if this is true, then there is possibility or support for multiple instances of a sensor, let just say for this example we have 3 airspeed sensors on the drone, how would the interface know which sensor instance to call for? I assume some index would be passed in from the ZP3 code?

2. Kind of by extension, if point 1 is true, should we then make LOS a singleton?

3. Should all drivers support dependency injection (https://stackoverflow.com/questions/130794/what-is-dependency-injection ) making them portable and easily mocked. This would also require some rework of current drivers I believe.

4. There was talk about some runtime configuration, how would all this play into LOS (my first thought is LOS shouldn't be aware about this run time config and this ultimately what would be passed into LOS, which may be why we need dependency injection for our drivers)?

Discussion

Q1:

• Online resources suggest that having a singleton pattern only because there may only be 1 “instance” is not the best idea

  • limits having more in the future

• Now that we have an interface between the driver and ZP3 SW, possibly eliminating the singleton nature could be beneficial

• Decision: Remove singletons from driver design pattern

Q2:

• The question arises that