obc: add framework for modes of operation#152
Conversation
Add initial framework of modules, modes of operation, and functions that will be used across all files. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Add initial framework for the Idle mode of operation. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Add initial framework for the Imaging mode of operation. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Add initial framework for the Downlinking mode of operation. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Add initial framework for the Safety mode of operation. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Add initial framework for the Firmware Update mode of operation. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
The main function has been moved to the idle mode of operation file, so this file is unnecessary and has been deleted. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
angelazheng96
requested review from
TheArchons,
alexapostolu,
chopikus,
coby1kenobi,
mshinjo and
swarnavaghosh04
as code owners
alexapostolu
left a comment
alexapostolu
left a comment
There was a problem hiding this comment.
This looks pretty good so far. I left some comments on a couple things that stood out to me initially. We'll do many rounds of reviews over time, but this is a good starting point.
There's also some CI errors related to formatting and building. Feel free to fix those as well but they're not a priority for now.
apps/obc/src/safety.c
Outdated
| char* error_info; | ||
| safety_command cmd; | ||
|
|
||
| while (1) |
There was a problem hiding this comment.
We never want to have an unbounded loop because this may never end. For cases like this, a timeout would be better, so loop for like 500ms (we can chose a more accurate time bound later), and if nothing happens then stop the loop and return an error.
You can refer to the NASA coding handbook for more details (rule 2): https://web.eecs.umich.edu/~imarkov/10rules.pdf
Modify conditional block to allow for both obc and pay update in the Firmware Update command sequence. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Add FINCH prefix to the common module to avoid naming conflicts with external libraries. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Add downlinking prefix to all functions in Downlinking command sequence. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Reinstate main file for OBC. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Change placeholder parameter and return types from char* to uint8_t*. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
For functions in downlinking.c and safety.c that send downlinking or error data to RF, designate the data parameter as a constant. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Originally, the modes of operation registered both the 'obc' module and their own module name for logging; removed the 'obc' module registration to make logging more specific. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Add basic error handling template for the downlinking to RF function. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Init file handles the modes of operation switching. This removes the problem of infinite stacks when calling functions directly. This way each mode of operation returns with the op code of the mode of operation it wants to switch to. Signed-off-by: Juan Pablo Medina <jpmedinagl@gmail.com>
mshinjo
left a comment
mshinjo
left a comment
There was a problem hiding this comment.
@alexapostolu
I'm curious. If we are introducing flatsat specific images (#147), shouldn't all of these modes of operation changes be included in the flatsat image as well?
I know we discussed this a few weeks ago on #147. Have we decided if we still plan to introduce separate flatsat images, or continue development in the flight software image (I prefer this approach, but that's just my opinion)?
mode to fine pointing mode In the Firmware Update mode, the ADCS should be set to fine pointing mode and not sun pointing mode. Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
Adding idle scheduling. Support for different commands. Defining command structure for idle.
…light-software into mission-ops-moos
We are in the process of restructuring Idle mode to take in commands as an array. Therefore, each of the general sections in the previous Idle main sequence has been moved to a separate function. (Not properly implemented yet.) Signed-off-by: Angela Zheng <angelazheng96@gmail.com>
|
|
||
| mode_op mode; | ||
| idle_ret_t (*fname)(void); | ||
| uint8_t *loc; |
There was a problem hiding this comment.
Current location of the satellite - we weren't sure what data type to use for that
| for (int i = 0; i < MAX_SCHEDULE_LENGTH; i++) { | ||
| cmd = idle_schedule[i]; | ||
|
|
||
| if (cmd->mode != MODE_OP_IDLE) { | ||
| return cmd->mode; | ||
| } | ||
|
|
||
| ret = execute_command(cmd); | ||
|
|
||
| // error handling | ||
| } |
There was a problem hiding this comment.
I forgot what we conclude with last week, but I remember us also talking about the option where we have an external function do this for loop for all the modes. So instead of idle.c running through the commands, and external function would take in Idle's command sequence, run them, and at the end switch modes.
There was a problem hiding this comment.
Ok that makes sense, we can move the new stuff from this past week into init.c, which is where we could put the external function to execute any mode's command sequence. In that case, each MOO would no longer have its own main sequence, just helper functions right?
There was a problem hiding this comment.
Yea, just confirm with JP on this just in case I missed something
Yea that's a good point. I have to think about it a bit more. |
4 participants
This PR adds a baseline framework for the modes of operation, as defined by the Mission Operations team. It currently follows the most recent system architecture diagrams, which are based on the document linked in the Final Update to MOOs Notion page.