Network layer for SimpleFOC (Luos)

Hi everyone,

I plan to create a code example combining Luos and SimpleFOC.
At Luos, we are working on embedded microservices, or how to make multiple features (motor, sensor, app) across numerous boards quickly work together =>

The idea is to use as many SimpleFOC boards as we want on a machine with any other devices, and we plan to make a simple 3DOF arm to move marble with it.

But first, I need some boards to work on, and there is no official SimpleFOC board available :frowning: .
In you point of view, what is the setup I should buy to start with?

Also, did you see any way to make this development useful for the SimpleFOC community?

1 Like


Welcome to the forum.

There are boards, but all components are out of stock due to the current world-wide silicon shortage.

The closest to what you want may be the SimpleFOC Arduino shields, or some of the boards listed here

To my knowledge, they are also having manufacturing issues.

I’m currently developing a fully integrated board

That one however is in development and will not be publicly available until March perhaps.

There may be others on this forum that could give you more input and references.

The most important question is, what are your use cases?


Dear @Nico-Luos , welcome to SimpleFOC!

I actually recently looked at your website, after a friend pointed it out. It would be exciting to have SimpleFOC work as part of the Luos!

Would it be a service? Would you “bundle” SimpleFOC including motion control, FOC, PWM driver and sensor as one Lous ‘entity’ (whatever the representation is that would best fit)? Or would you intend to seperate these components? The integration between these needs to be quite tight, I’m not sure the latter would work well…
It will certainly be interesting to see how this develops, and I would be happy to support the effort by helping with SimpleFOC integration questions if I can.

In terms of your question regarding the boards, you could certainly begin development with any Arduino compatible MCU and no motor, in open-loop mode you won’t even need the sensor. Obviously this won’t actually move anything but the whole communications and simpleFOC setup could be developed on while you wait for the right hardware.

In terms of drivers, I think the clones of the SimpleFOC shield can be ordered?

This isn’t quite the shape you’d want for a robot arm, but would certainly get you started on the development of the comms etc… and with moving motors :slight_smile:

In terms of a robot arm capable board, you could ask about the Dagor controller…

1 Like

Hey Nico, happy to hear form you!

The embedded community in Bordeaux is not so large and I am very happy to hear that you are interested in exploring the SimpleFOC. :smiley:

We’d definitely be happy to hear more about your vision of the integration of the SimpleFOC to Luos.

At the moment the SimpleFOC shields are out of stock, but I do have some (used) which I would be very happy to share with you. Let me know if you’d be interested! :smiley:

1 Like

Guys, thank you for the warm welcome,

I heard about you from @Sam (thank you Sam :wink: ), and I continued spreading the message by introducing SimpleFOC to Pollen Robotics (my first company). I think they could be interested…

@Antun_Skuric world is so small, yes I am interested to share some of your boards to bootstrap the project at least we have to share a coffee and talk.

I will start this week by selecting the easiest MCU to start and compile an open-loop version as runger (I can only mention 2 people per post for now) advised.
I have tons of things on the way so I’m not really sure about how committed I will be, any help is really welcomed.
I will definitely need some help with the motor part.

At Luos we already have users running more than 20 crazy FOC brushless motors in an advanced atomic grade robotic arm. So this is not my first time integrating FOC in a Luos’s service but my first time actually writing code about the motor.

About Luos

To give you more context about the project driving me here. The Idea of Luos is to simplify compatibility between things. To do that we encapsulate a piece of firmware into a package exposing a service. In the SimpleFOC case, this service will be a motor driver (2 services if we have 2 motors).
Services are just a fancy API encapsulating a feature.
Packages are services code folders.
Because services are loosely coupled Packages are independent pieces of code you can easily move from one board to another (a kind of tiny container for embedded systems).

Using the service interface you will be able to send or get the position, speed, torque, trajectory, current, temperature, or anything you want. Luos will allow you to send/receive information from theoretically anything. You can control a collection of motors from any kind of board through a network, or directly using python on your computer, or both at the same time.

We put services into packages to easily share a feature and plan to have a registry soon listing all available packages (a kind of app store). We want SimpleFOC to be one of the first packages.

About the project

To start working on SimpleFOC we plan to add some more context. Currently, we are working on a Test/Demo system able to perform autotest of our library on multiple collaborative devices running a marble circuit. The development of this test system will be publicized on various content explaining how we make it. In the end, users will be able to take control of this system through our website to see any interaction between services (a kind of online remote system debugger).

We plan to create a 3DOF arm to move some marbles. Because the idea of Luos is to make things work together, we planned to create this 3DOF robot with 1 stepper, 1 BLDC, 1DC. We already have the DC and stepper running, and plan to do the BLDC with you. Perhaps this robot will be linked to ROS or Unity, we don’t know yet.

So, step 1: Choose the MCU!


Wow. Very interesting. That’s super-ambitious. I’m very curious and will be watching very closely. Currently I’m working on something like that and the problem is so hard that I ended up designing my own hardware and writing my own network layer and encryption algorithms and protocol in low-level C (and some assembler) else nothing else worked. This is what I had to design from scratch (fabricate from discrete components) to make it work in order to achieve near-zero latency and hard cryptoprotection and DOS/attack protections.

I’m very interested how you could solve the problem with off-shelf components and a scripting interpretive language. That would open the field to more people who cannot afford a custom solution.

Very interesting.


I’m not sure Luos could solve entirely your problem here because it can work with any physical communication layer. So you still need to deal with your hardware, encryption, and security issues depending on your product constraints.

We have a simple serial low-level management allowing us to do multi-master and stuff with no additional hardware but it can’t work in any conditions. Others need specific hardware.

For now, to interact with something like python you need to add an extra service on the embedded side called Gate translating Luos’s messages into Json and streaming it to your computer.

You can experience all of it by following our get-started : Get started | Luos

We are currently working on a multi-phy feature allowing us to put the Gate service (and any other) directly into the computer or cloud.

1 Like

My problem is that I need to control a large number of nodes simultaneously in real-time, where real-time is 10ms or better round trip end to end, over 10 km or more, including full encryption and network protection.

I did look into the link you sent me but didn’t quite get it, perhaps I’ll just wait and see what you come up with and you do a few use cases first.

It’s an interesting project.


If you want to make it 10ms real-time you will probably need to consider having a time synchronization or something allowing you to define an event date.
We have a specific way to deal with time synchronization for distributed architectures at Luos.
I am currently working on a blog post called “Distributed latency-based time synchronization” to explain how we make it.


Perhaps you misunderstand the use case, I mean, 10ms round trip data packet, not within 10ms synchronization of the time.