...
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.