Handle and log onboard_computer_status messages

[Jaeyoung-Lim]

Describe problem solved by the proposed pull request
A new mavlink message has been introduced to monitor the status of the companion computer mavlink/mavlink#1186 However, the message was not handled from the firmware and therefore not logged into the message.

This PR copies the message to a uORB topic and logs it as part of the flight log.

Information of the companion computer (e.g. cpu load, memory usage ) can be very useful in checking the health of the overall system, especially for applications that run critical processes on the companion computer (such as obstacle avoidance)

Describe your preferred solution
Adds a message handler in mavlink_receiver and logs it as part of the vision and avoidance topics.

[Jaeyoung-Lim]

@dagar Any ideas how I should solve the flash space problem with fmuv2?

[dagar]

@dagar Any ideas how I should solve the flash space problem with fmuv2?

Either of these PRs will save more than enough. #12601 #12191

[bkueng]

This is ok, but going forward I think we need a better approach than pushing data into the flight controller and then pushing it right back out again only for logging.

[Jaeyoung-Lim]

@bkueng Thanks for the input! I totally agree, but in the short term this would be useful on evaluating the performance of the system with companion computers

[Jaeyoung-Lim]

Now flash space is solved, but the test fails on rtps.

@TSC21 Are the rtps message IDs just assigned arbitrarily? I couldn't find any documentation on how the message IDs are defined

[TSC21]

Now flash space is solved, but the test fails on rtps.

@TSC21 Are the rtps message IDs just assigned arbitrarily? I couldn't find any documentation on how the message IDs are defined

There's no magic behind it. Just follow the numeration, and make sure you don't add base msgs to the multitopic ID space.

[Jaeyoung-Lim]

@TSC21 Thanks! All is good now :)

[TSC21]

So are we just using this msg for logging purposes? I see some more useful usage for it.

[TSC21]

So are we just using this msg for logging purposes? I see some more useful usage for it.

@Jaeyoung-Lim can you advance more on what will be the usages for this, besides logging?

[Jaeyoung-Lim]

@TSC21 As explained in the description, the main reason is to monitor the companion computer status and log it.

This is a crucial part on enabling advanced computer vision systems, as we will be able identify problems that are caused by companion computers such as high CPU loads / high temperature / low memory availability.

For the future work, as this PR adds a uORB topic for the onboard computer status, we would also be able to add failsafe behaviors triggered from the companion computer status.

But for now, logging the status of the companion will already enable us to identify a lot of problems much faster that is coming from the companion

[TSC21]

@TSC21 As explained in the description, the main reason is to monitor the companion computer status and log it.

This is a crucial part on enabling advanced computer vision systems, as we will be able identify problems that are caused by companion computers such as high CPU loads / high temperature / low memory availability.

For the future work, as this PR adds a uORB topic for the onboard computer status, we would also be able to add failsafe behaviors triggered from the companion computer status.

But for now, logging the status of the companion will already enable us to identify a lot of problems much faster that is coming from the companion

Thanks! That seems to be the way to go. Merging

[Jaeyoung-Lim]

@TSC21 Thanks!