"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
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
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.
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();
^~~~~~~~~~~~
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.
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
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 :
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.
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.
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.
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.
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.
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.