luos-io / luos_engine Goto Github PK

• Register PTP that can be more than 2
• Truth table to have state PTP
• time for PTP maintain up or down

Describe the bug

Context :

• OS : Windows.
• "PLATFORMIO_LIB_EXTRA_DIR" environment variable points to a local directory.
• This local directory includes many libraries and projects. For example, it can be your local workspace directory with many differents projects, even if there are not Luos related.

When compiling a project, PlatformIO scans all directories pointed by PLATFORMIO_LIB_EXTRA_DIR.
Then, PlatformIO tries to compile all directories. Maybe it believes those dir are "libraries"...
So, depending of your local directory structure, the compilation fails.

How to reproduce the bug
See context in above section.

Suggestions

• Try to find a clean fix (maybe in platformio.ini ?).
• If it's not possible, we'll have to add a specific troubleshooting chapter in the Luos documentation.

In the readme: This repository contains a submodule. The examples folder is linked to another repository. That means this folder won't be cloned with a regular git clone.

This didn't seem to be the case.

Running git clone --recursive https://github.com/Luos-io/Luos.git doesn't make an examples directory appear.

By passing ID in 8 bit instead of 12 we can change the header struct and save 1 byte on the header because we can save 4 bit in target and source field.
This allow us to check if the message is for us at the second byte and we don't need more than 256 module ID.

In Reachy modules send datas when critical motor informations are transmited generating message collision. When collision occures critical messages transmission fail easily. We have to speed up collision detection and understand how electrical priority work.

First we have to look at electrical behavior of the driver with and without pull-up.
After try to secure collision detection.
And finish by randomize retry delay time to avoid recollision.

Describe the bug
When we create a lot of auto-update at the same time all the services reply in a short period of time. But after few seconds we can see that this period of time become larger and larger. The space between boards diverge.

Network configuration

• Any

How to reproduce the bug
Just use a gate with some service with the standard configuration

Additional context
The auto-update feature have a ms granularity. We could reduce this granularity to reduce this divergence.
Most importantly auto-update is computed on luos_loop(). If Luos_loop is executed later after the deadline we create divergence because after send the message we do :
new_trigger_date = current_time + update_time
We should do :
new_trigger_date = last_trigger_date + update_time

pb works well at O1 but not at O0 certainly du to timings and loop for or while

Describe the bug
When connecting to a Gate, if Pyluos doesn't receive any detection from the Gate : the process is stucked in serial initialisation method. A bypass way is to disconnect and reconnect manually the serial link (usb/serial link in my case) But it's not convenient. A software fix should be usefull.

Network configuration

• Bad configuration : a MCU in Luos Network is badly initialised (so the PTP states are totally crashed).

How to reproduce the bug
With a network with a bad firmware loaded (specially with bad PTP configurations) , the Gate is logically not able to receive a routing table.

Additional context
Even if the bug is caused by a bad user configuration, Pyluos should include a way to properly close serial link (with a software command ? A timeout ? ...).

Describe the bug
It's possible to have detection reentrance if user make the launch of a detection on an event in msg_handler triggered by a localhost service.
For example a button board with a button driver service and an App running a detection on push.
When you push the button detection is launched from message_handler, but it's possible than the detection run Luos_Loop(). If Your button service send another information about the push of the button it could re-call the detection in the middle on detection.
Witch is bad...

Network configuration
To reproduce it you probably need to have quite a large network making the detection wait and call Luos_Loop

Additional context
This bug have been hidden in the detection button app from the led_strip Demo

the lib revision on the platformio side should be used on Luos and sharable into the network allowing to check compatibility.

time_t structure on OD already exist. We should rename it as time_luos_t

When it's done we should use OD time functions on modules (led, gate, ...)

Describe the bug
When there is a lot of nodes on a network during the detection we copy the routing table in each node.
The first nodes that get this routing table are ready to send things but not the other. Potentially messages send during those copies can be ignored because routing table is not already up to date in all the nodes.
This could lead to a change in the behavior depending on the position of the nodes from the detector.

Network configuration
Quite a big one with a lot of nodes.
And we need to have the application sending things like configuration just after the detection.

Additional context
This bug has been hidden by delaying configurations send on our demos (bike alarm and led_strip)

We need to include "luos_board.h" to make
HAL_ADC_Start_DMA(&hadc, node_analog.unmap, sizeof(node_analog_t) / sizeof(uint32_t)) work.
Normally we should not.

What feature would you like to be included in Luos?
Actually keeping aliases from a power off is a mess and is never the same depending on MCU.

We should make something simple but efficient and reusable.

On Luos project compilation, there are 2 warnings about IRQ function declarations :

Templates\Servo_motor\profile_servo_motor.c: In function 'ProfileServoMotor_Handler':
Templates\Servo_motor\profile_servo_motor.c:153:13: warning: implicit declaration of function '__disable_irq' [-Wimplicit-function-declaration]
__disable_irq();
^~~~~~~~~~~~~

Templates\Servo_motor\profile_servo_motor.c:156:13: warning: implicit declaration of function '__enable_irq' [-Wimplicit-function-declaration]
__enable_irq();
^~~~~~~~~~~~

Manage assert bay sharing it on the network and update all routing table.
Manage it on gate an pyluos too;

Actually identifying a node is a mess. We should be able to determine a node by a number.
This allow us to manage a new kind of target_mode for node. This is extremely usefull for bootloader because bootloader doesn't really have any module...
Also we have to store this information in route table and or module to easily identify where is hosted a specific module.

Sometime a module miss an id sent by the detector module. We perhaps we could use IDACK.

Describe the bug
I'm not comfortable with the use of "route table" instead of "routing table", this is a mere question of terminology, but it may be good to avoid approximate or wrong use of words at the very root of the technology, as it can only prejudice us in the future.

Network configuration
n/a

How to reproduce the bug
eg:
route_table_t route_table[MAX_containers_NUMBER];
RouteTB_GetNodeID(unsigned short index);
compute_route_table_entry_nb(void);

Additional context
Add any other context about the problem here.
Don't hesitate to add screenshots or to link an entry from the forum.

What feature would you like to be included in Luos?
It would be good to rename the master branch to main as the github. https://github.com/github/renaming

What feature would you like to be included in Luos?
Code Optimisation

• discard msg with PTP
• remove from luos detection

Hi
I find the project cool.
Do you plan to port it to C++? It would fit very well with your framework.
Thanks in advance

Sometime there is some inconsistencies on node topology mapping causing pyluos fail.
output module doesn't always fit with the output module input. This is because we can't check the good reception of this information during detection.
We have to find a way to secure it :

• by securing the reception of this information
• by recompute data after and remake it clean.

We should cumulate filters on routing table field instead of making silly research function for each case.

Currently during the reception of a message we have to loop on module table to find if we have a module concerned by this messages. This loop take time and have to be executed in IRQ...
To save some time defining if this message is for us or not we could check it by using masks on compressed datas of hosted modules in the node.

To do that the Id or Type value represent a bit decay on a specific buffer containing compressed datas of modules hosted in a node. To check if a message is for us we just have to decay a bit from the ID or TYPE received and compare it with the local compressed values we have.

Create a basic template managing a state object.

Describe the bug
On november 5th 2021, clang-format has released version 1.6.0.
Since this date, all Luos github actions workflows which are using linting are down ( concerned repository : Luos, LuosHAL & Examples).

Additional context
Before fixing properly this problem, i have modified all worklows to old clang-format version 1.5.0. Everything seems OK, but we should fix this later.

Add node ID allowing to identify a specific Node.
This way a container can send a message to a node.
We also have to manage NODE target mode.

As described in the documentation, product-related definition and enums should be put on a product_config.h .

But if I want to create and maintain my product App type list with the Luos offset or a custom command list, this will not work because I need to include luos_list.h first.

example :

typedef enum
{
    MY_APPLICATION_TYPE = LUOS_LAST_TYPE,
    MY_SENSORAPP_TYPE
} ;

The product_config.h is included using -include ../product_config.h on the platformio.ini file that's why you don't have any luos related values.

We have to find a way to make it.

Since the separation between Gate and Pipe Gate don't return Gate Assert anymore.

On assert The node start by calling Services assert functions. Previously this function was managed by Gate and was allowing to send back assert information to the computer.
Now the Gate still generating this message but send it to pipe. The problem is that Pipe will not be called anymore because we are on assert.

To solve this we should call a function of pipe that will be able to send assert information to the computer.

On GitHub Action "BUILD" workflow, all Luos repository are correctly compiled, without any warning.
But on some OS (like Ubuntu), GCC basic parameters are generating too many warnings.

Maybe those warnings are not relevant. But we should take a little time to think about that.

remove useless detection file

Create a message allocator instead of a simple table to save some ram.

Describe the bug
When asking statistics with Pyluos, those statistics are often not reported to python console.

Network configuration
4 st-microelectronics MCUs (L0, F0, G4, L4) with about 20 services.

How to reproduce the bug
Simply ask statistics in loop, and the bug will pop in less than a minute.

Additional context
A colleague has the same bug on his Windows Dell Laptop. But in his case, he doesn't receive the statistics at all.

What MCU would you like Luos to be compatible with?

Link the datasheet of this MCU:

Describe your project:

Describe the electronic board hosting the MCU:
Add details about the network interface, the pins used, the device, etc.
Don't hesitate to post a schematic.

Ensure that every box bellow is checked:

• The MCU is not in the compatible list in the documentation.
• The MCU is not already in an existing porting issue.
• The issue has the label porting.
• The issue is added to the Porting project.

Additional context
Add any other context about the porting request here.

What MCU would you like Luos to be compatible with?

Link the datasheet of this MCU:

Describe your project:

Describe the electronic board hosting the MCU:
Add details about the network interface, the pins used, the device, etc.
Don't hesitate to post a schematic.

Ensure that every box bellow is checked:

• The MCU is not in the compatible list in the documentation.
• The MCU is not already in an existing porting issue.
• The issue has the label porting.
• The issue is added to the Porting project.

Additional context
Add any other context about the porting request here.

copy all needed cubeMX generated code in hal.c file avoiding to setup properly CubeMX for each Luos based project.