PlantUML rendering of the MathComponent tutorial

[TenguBoss]

Dear Colleagues,

We have started using F Prime for our project on the coordination and contol of swarms of Space Vehicle (SVs) . First of all thank you for all the work in putting F Prime and releasing it as open source; it's a lot of fun.

In an attempt to formalize our design processes I put together a PlantUML description of the MathXomponent tutorial. (To be read as: "this GNC engineer needs diagrams with blockd and arrows to understand what's going on.") The diagram takes advantage of the PlantUML customization of UML that I have used to the extend I understand UML. I am posting the diagram only to ask for any feedback and comments before I start on the GPSTutorial. If the PlantUML script might be useful to the community I can make it available.

We are looking forward to hearing from you. Thank you!

Bogdan

[Joshua-Anderson]

This is really cool! Are you parsing the component and topology XML files to generate this?

[Joshua-Anderson]

Welcome to the community and please keep asking questions as you learn!

Don't be afraid to take a look at the core components in /Svc to see common component design patterns

Yeah, there is a quite a bit of overhead in defining a component and its message structures. I'd recommend trying out fprime-util new to help speed up creating new components and ports.

Now that you bring it up, it makes sense to write a parser and generate this kind of diagrams.

F Prime's component structure lends itself well to block diagrams. I've used a prototype topology visualizer (I don't think it wound up being open sourced since it's a prototype) and it worked well for exploring the structure of a F' project.

[TenguBoss]

Thank you again. Right now I am more concerned about the overhead in the communications between the GNC computer and the reaction wheel and what delays it might introduce in the attitude control system. But we have just start exploring F' so maybe I'm prematurely anxious.

[Joshua-Anderson]

Ah, performance overhead, not code overhead 😁

Synchronous port calls have effectively no overhead, the autocoder just translates them into a function call.
Async port calls will use an os-layer queue, which certainly adds some overheard but usually not enough to be concerning. Managing task priority of the active components is generally the largest part to ensuring that async port calls are handled within their deadlines, particularly in an RTOS context.

[timcanham]

@TenguBoss: For what it's worth, we have run F Prime at very high loop rates. It typically isn't the bottleneck. It exacts a low tax if you use messaging, but you aren't required to use messaging. You can use synchronous port calls to group high-rate activities together using the ActiveRateGroup component to do work cyclically.

[TenguBoss]

@Joshua-Anderson and @timcanham Thank you for the details. Indeed, we were worried about performance overhead. I was afraid that everything was handled with messaging. And yes, task priority selection and fine tuning is where the fun starts.

For the time being, we have an internal discussion and are starting to experiment with handling "clones" of flight software components to each of the spacecraft in a swarm. We are focused on developing a Processor-In-the-Loop (PIL) swarm testbed and from what we have learned it seems that F' messaging allows us to perform inter-spacecraft communications with very small changes to the underlying patterns.