Central System Manager
This week, I built the first prototype of the central system manager! As mentioned in a previous status update, I programmed the CSM using Python, a language not typically selected for multithreading purposes, open access to a wider array of GPIO libraries that would have been used to integrate hardware and software portions of the project, to consolidate the technical resources utilized in this project, and to minimize links between these tech resources in a time where integration is becoming increasingly problematic for the team.
This progress goes into several code modules, each representing the different portions of the overall project that must be controlled concurrently.
- The System manager, the core of the CSM which launches all other module managers, coordinates data transfer between them, and acts as the product’s FSM
- The Camera manager, whose role has now been changed to modeling the control of a Picamera so as to pull frame data from some source and forward it over to the Perception manager run by Diego.
- The Motor manager, whose role has now focused to pulling motor command information from the SystemMan and pushing it to an analyzable log.
- The Communications manager, whose role it is to maintain bluetooth connection with the iOS app and to send and receive information from it.
- The Perception manager, programmed by Diego, whose role it is to control the full Perception stack of object detection and tracking
Although Python’s concurrency features and the elimination of most hardware integration has made this work difficult, it is still feasible and everything we simply cannot accomplish now we can model as a representation of this project being possible in the future.
0 Comments