Hi all!
Does anyone have experience with applications that use the simpleFOC library and are integrated in a ROS2 project? I imagine a simple communication protocol that allows a ROS2 node, running for example on a rpi, to control one or more motors via serial accessing the SimpleFOC api. Do you know if something like this exists? Is there someone interested on working on this?
2 Likes
I’ve made a simpleFOC mini running with a rp2040. The motor is controlled by RepRapFirmware from Duet3D by their step/dir interface. RRF is RTOS based.
Personally I’m not a big fan of ROS… Antun uses it though, I believe.
There’s also the Luos project you may want to check out. It’s not ROS but may be interesting to you.
I’m sure that if you did this effort and packaged it in a way that’s easy to use, there would be people interested 
And while I don’t use ROS myself, and can’t really help you there, I (and others here) would be very happy to help if there are questions about the SimpleFOC side
1 Like
I really tried to pick this up a few months ago, but found the abstraction very confusing, and the documentation is not clear about how to design compatible hardware.
(also, their discord is full of bots and kids looking for help on homework, no discussion of the project!)
I’m interested in ROS. I tried to get SimpleFOC running with MicroROS here: https://github.com/rosmo-robot/linorobot2_hardware/blob/galactic/firmware/platformio.ini
But it was beyond my skills and I gave up. I’ve been playing with brushed motors since, but would be interested to re-visit it. I probably overcomplicated it by trying to port that project to the ESP32 at the same time.
I would start from this Howto/ repo: Running linorobot2_hardware on esp32-WROOM-32D using Wifi | by RoboFoundry | Medium which was published yesterday.
1 Like
I’ve read this article about dual core use for ESP32 under ArduinoIDE. It says, the ArduinoIDE supports freeRTOS and multitasking/multicore usage.
If it’s that what you want, I can post my findings regarding dual core tasking with sFOC here.
Same for rp2040 boards. Their dual core is supported by the mbed-rp2040 library under ArduinoIDE.
Do note that the mbed framework has significantly lower performance than than the earle-hillpower one, it might be impossible to operate the motor with fast enough response speed for your application
I took a look at the microROS project multiple times but I think is still in an early stage of development and would be to much time consuming dealing with it, considering that microROS only tries to extend the ROS2 framework to embedded systems.
The use of microROS can be easily avoided with an implementation of a ROS2 node that communicates with an embedded application via serial. I think it would be possible to use the already existing Commander interface for a good integration of simpleFOC in a ROS application.
The advantage of using ROS in a project is that it gives you access to a lot of high level software that can be easily integrated in it. For example if you use simplefoc to drive the motors of a mobile platform and you make it communicate with ROS you can than use all the navigation algorithms provided by ROS. It would be convenient. I would be surprised if nobody already implemented something similar.
@runger if I understood correctly the Luos project that you mentioned is targeting the embedded side of the issue, so it can be avoided, like microROS, with the implementation of a ROS bridge with the Commander Interface. Am I correct? Do you think @Antun_Skuric can share his experience with us?
1 Like
Your arguments sound very convincing
I have some code (work in progress) in the drivers library for a Serial binary protocol, and a Serial ASCII protocol based on registers - it may be simpler to use this kind of interface for machine to machine APIs.
But also the standard commander interface could be used, as you suggest, it would just involve more string parsing and setup code.
1 Like
Sorry for OT,
I tried to use Earls library too, but I couldn’t compile simpleFOC examples. Something about invalid string conversion in the commander voids…Maybe I try it again with @dekutree64 's simplified commander…
1 Like
This is a bug in commander code which should be fixed in upcoming releases… but it should still compile- it’s just a warning level error. It shouldn’t be related to the framework, I think.
I was hoping that there was some sort of binary protocol to speed up the communications. It is possible to test it?
The current state of the code is here:
But this is still unfinished.
I would like to refactor it to make it all cleaner in C/C++, at the moment the structure is too object oriented, I think.
Hi @runger
Maybe a checksum can be useful.
A XOR checksum was used on the hoverboard firmware, some argued CRC would have been better.
Some hardware also have idle line detection.
Agree, a checksum would be good for sure.
What I’m wrestling with is how to package all of this in a good C++ way.
In reality there are 3 functions:
→ transfer a “register” value from a SimpleFOC motor to a memory buffer
→ transfer a “register” value from a memory buffer to a SimpleFOC motor
→ obtain the number of bytes used in a memory buffer for a SimpleFOC register
Using these 3 functions I think any kind of “register based” control interface can interact with the simplefoc motors. It should not really matter if it is I2C, Serial, UDP or CAN-bus. Each of these can have their own implementations which put values onto the wire and read values from the wire, so to speak.
Additionally:
- the registers should be extensible, so people can extend the control scheme easily with new registers for their purposes
- the interfaces should support using more than one motor “current motor register”
- the code should be useable both in a synchronous (e.g. I2C controller) and asynchronous (e.g. I2C device) context
I will see if I can take another stab at it in the next couple of weeks.
2 Likes
One thing that I could never implement is aknowledgment.
Some values like target would be sent often, so it’s not a problem if you miss it.
But some other messages cannot be missed.
Or you need to send all register’s value over and over again.
I don’t see that as being a big problem.
At one level the application can get an acknowledgement by simply reading the register after writing it.
Or else a given transport could implement an “echo” much like the current Commander does. That’s more a feature for transports like Serial or UDP which are asynchronous. For I2C, ACKs are built into the protocol level.
Yes yes, I am speaking specifically about UART.
I started working on one that uses hoverboard motors and MKS ESP32 FOC v1.0. I just got it to subscribe to a ROS2 topic for velocity command and publishing rotation to another topic: GitHub - mattwilliamson/deepdrive_motor_controller: ROS2 SimpleFOC Motor Controller for hoverboard motors
It uses micro ros over UART and Arduino framework on PlatformIO.
2 Likes
Thanks for sharing! My experience with microROS was tough… 
did they made it a little more user friendlier? I certainly admire the fact that you were able to use it! By the way, are you using only topics to publish and subscribe or did you developed a ROS2 hardware interface?