Purpose
This meeting is to discuss LOS architecture decisions, specifically, to answer these questions:
Should we eliminate the singleton nature of our drivers now that there is an interface (LOS_Interface) separating ZP3 code and the drivers.
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?
Kind of by extension, if point 1 is true, should we then make LOS a singleton?
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.
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.