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 when you think about an interface for the entire system, does it make sense to have multiple instances that lead to the same thing (the drivers and core functions)

• Decision for singleton pattern: Make LOS interface a singleton. Reason being, it is intended that there is only ever one interface for a given system, and if more than one are ever instantiated, it could lead to very undefined behavior. So user protection.

• Decision for thread safety responsibility: LOS will be thread safe.

Notes:

Thread Safety

• How do we ensure that the interfaces are not having issues with threads

  • Chris says that thread safety would be up to the users of LOS

  • guy → it should be thread safe to access the different interfaces

    • Chris: (1) how would you implement that and (2) its undeterministic for the user side to know if something is working

    • guy: as long as we use rtos features it would be able to figure out priority and stuff

    • chris: how do we decide to implement this in LOS vs user code

      • We want to give the most “flexibility” to use it how you want

      • But do we want to let them use it incorrectly?

    • tony: isn’t rtos being controlled by user code?

      • what if rtos isnt running?

      • We could run some checking on whether it needs to be doing rt safety

      • Or we could leave it up to the user since los is meant to be configurable by user as much as possible

• back to the original question about singleton los

  • might be a good idea to make it a singleton to protect user from making two of them, better than having user need to enforce only creating one los object, and better than static classes cause its easier to work with and ensures only initialized once and that no matter when you access it, you can be sure it has been initialized.

• Back to thread safety

  • similar to the reasoning for singleton: maybe its good to have mutexes baked in

  • Maybe have them be enabled/disabled from config

  • might be better to have someone

  • Some boards dont support rtos

    • Add some kind of configuration to different boards?

  • HAL doesn’t have thread safety built in, so why don’t we?

    • Anni: i have seen some stuff that has thread safety built in but anyways; on the point of leaving stuff to the user but at some point, you need to decide where the line is in the user’s control.

      • for having thread safety. The addition of this feature wouldn’t have an impact on the user’s perspective of control over rtos

      • if we have sensor fusion, a part of it already needs to be thread safe so it makes sense to make it all thread safe?

  • End result is maybe making los thread safe

Q3:

• Makes the drivers more generic, able to work with different parameters

  • Part of the original spec

• Decision: All LOS drivers will support dependency injection to be high configurable and portable.

Q4

• How do we expose configuration to the user

  • when you create los you want be able to define the configuration

  • With singleton, you dont necessarily know if its been initialized when you get the instance

• There are two parts to configuration:

  • LOS interface require configuration (how many drivers to configure with what dependencies)

  • LOS drivers require configuration because of dependency injection

• How it is currently set up is there is a config.h file that would hold all this configuration in which LOS interface would have access too

• Runtime config tho

  • Ardupilot allows changing the config at any time, even during flight

  • this might be too much for us rn

  • it might be doable

    • You have your initializiation but you can change stuff halfway through

  • If it is a runtime configuration, it would be something zero pilot would have to do and pass to interfaces and then pass it to the driver

    • It would be easy enough on the driver side (Just reinitializing the drivers)

    • But on the interface side, you need to deal with variable config parameters → different types of gps for the gps driver for e.g., the user needs to be able to determine the available pins and parse that (E.g. “gpio pin b” is this pointer to the gpio pin) etc.

• Decision: keep config.h and driver_params.h for LOS configuration, meaning nothing has to be passed into LOS interface for initialization.