Repository for the module firmware.

[uLipe]

I think since the general idea of the hardware is up, the repository for the firmware as well the design discussions would be started.

I see this module as one of most exciting microROS over serial use cases, hot-pluggable to other microROS instances.

[samuk]

Absolutely! There are a few notes in the Rosmo doc, but worth discussing further.

Useful background is to know that @runger1101001 is the author of I2C commander. The ESC board will run this.

Beyond that I think it may fall into three phases;

1. A very simple Bluetooth car & I2C-commander to control to test the board(s) and bring the robot alive

2. Development of a block, or set of blocks for Ottodiy which communicate using I2C-commander. I think we can probably do this in the medium term with our current capacity. Ottodiy has expressed some interest in this.

3. The uRos work. This is less clear at this point. It might involve developing this diffdrive code to have similar functionality to I2C-commander-master. It may make sense to use the ROS2 stack of https://nanosaur.ai/ as they seem open to collaboration, and it would save reinventing the wheel there. There is also interesting work happening in the #stackchan community around uROS, so we'll keep an eye on that. We need more people to get involved to make the uROS/2 work a reality.

[runger1101001]

In terms of the firmware, we have to separate the different parts:

• the "module firmware" will target the STM32G4 MCU on the driver module. It will be expected to have a clean outward API towards the M5-stack's core MCU, probably via I2C. Th expectation is that the normal user will change this firmware rarely, if ever (so the final module may not have the USB port, to be discussed). This firmware will run SimpleFOC, which is an Arduino library. I see that µROS supports some Arduino hardware (though none with STM32G4 at the moment) - so I'm not sure how easy it is to marry these two things.
• the M5 core firmware, which talks to the motor drivers and handles all the higher lauer stuff. ESP32 is supported by µROS, and this is where I would see the freeRTOS based layer coming into play.
• the application software like blocky or a remote control app, which run on hardware external to the robot

For my part I would begin by creating a module firmware repo as the ticket suggests, based on Arduino framework, SimpleFOC and a fairly simple control layer, similar to the many commonly available I2C motor shields.

[samuk]

I think we agree that the "module firmware" on the ESC driver board can always remain Arduino?

In an Otto/Blockly use case, the 'Brain ESP32' would run Arduino & I2C-Commander-Master and speak over I2C to the ESC driver board.

In a uROS use case the 'brain ESP32' may run Arduino (or it may be possible to port I2c-commander-master to FreeRTOS), it speaks to the ESC driver board over I2C. The 'brain ESP32' is also communicating with a Jetson/Pi/Coral over Wifi or Ethernet for the higher level ROS2 stuff.

[runger1101001]

Note that the I2CCommanderMaster side is just a very slim wrapper over the I2C standard functionality. It would be fairly trivial to port it to any other framework.

[uLipe]

I would like to add some points from the optics I have been seen when working with robots as a distributed system.

• Treat them as an isolate subsystem is great, implementing the firmware separately of the ESC on the foc module, and basic robotics stuff ( high level controllers + kinematics server) in the ESP32 sound really nice and reinforces the principle of single responsibility.

• I think the SRP design would be even greater if the modules foc, esp32 and other devices like future sensors could take advantage of same interface, allowing them to be plug-in-play, and visible across other subsystems in a form of topics.

• And here is where microROS comes into play, it would be possible to model the foc modules as abstract boxes that control motors and expose them in a format of topics, publishing commands and parameters and subscribe for their state. Same for the esp32, by modelling it as an robot brain with relevant topics.

• The microROS in their latest design support custom transports ( over UART, thus I2c), and more recently the embeddedRTPS making any microROS instance to be discoverable direclty from a full ROS2 system ( on a PC or SBC), the integration and expansion of this robot system would be smooth, since model it in abstract way, let micro ROS handle the distributed process and deal with subsystem specific role, brain, foc, imu, etc.

Would be interested in a rough draft of this design, I can spend some time on it and share with you.

Just to remember, microROS is compatible with both Arduino, and esp-idf, also it is supported from Nuttx and Zephyr which recently is being supported officially by espressif as platforms.

[samuk]

Would be interested in a rough draft of this design"

Yes! That sounds interesting to me at least. @runger1101001 ?

As an aside, the guys at https://www.luos.io/ were quite interested in the Rosmo concept and might be interested in using the platform as a demo of Luos. Not sure how much time they actually have, or if that's just a further distraction for us in an already complex project.

[runger1101001]

Yes, I would be very interested! I have to quickly add though that due to my lack of knowledge on µROS and time constraints I would support but not lead that development effort.

Regarding luos, that's also an interesting project! I'm discovering so many interesting things thanks to you, sam!

I will (as so often, sorry!) add a concern to the equation: when doing this distributed robotics/control stuff, and also when dealing with something like luos, you have to look at the real-time requirements of the components and put everything in the right place, or it just won't work.
What do I mean? For example, the FOC control of the motors is highly real-time, sub-millisecond. To run either the FOC-loop or the move-loop remotely from the PWM generating MCU is not feasible.
The next level, motion control, i.e. coordinating 2 or more motors to achieve a desired trajectory for a robot - it may be possible to run that on a remote MCU. It will be a tradeoff - comms latency will cause less responsive control and/or inaccuracy depending on the control method. Same goes for detecting and avoiding obstacles.
Higher levels like mapping and navigation are less real-time and can clearly be more easily distributed.

So despite the promise of their marketing, using a system like luos still requires a careful design of the overall architecture and what happens where, at least for a robotics system.

[uLipe]

@runger1101001 that is true and I agree with you all concerns, when I worked in robotics company years ago, mostly of our final solution was a in-house engineering because at end of day the real-time requirements for having a multiple joint with high of DoF at the precise point are the main target to be achieved, so split high-rate control loops to run into bare-metal microcontollers to deal with servo controller.

At higher layer, and on the top of and ethercat bus, an single-board computer running realtime capable Linux dealt with waypoints and motion-planning + kinematics server in single ms timestep, and was responsible to generate all joints commands (position, velocity, torque).

So we were able to achieve good motion results by isolating the responsibility of each subsystem, from processing units to smart-actuators, which the foc module would be in my opinion.

Hopefully the microROS, as well the ROS2 project evolved to address the issues with realtime publish+sub pattern from ROS legacy and all the communication framework was engineered to achieve low latency communication.

So at the end, by using the microROS the effort may be focused on implementing the highest possible BW on the selected hardware interface, and let the uROS / ROS2 deal with the communication.

And yes, move the high-rate control loops to the foc-modules and leave slow loops + non-realtime stuff residing in esp32, also it would be possible to take advantage of its dual core architecture here and left one of its core to deal with control + low level communication :)

[samuk]

@uLipe I'm sure you're aware of https://machinekoder.com/machinekit-ros-open-source-robots/

It is coming to ROS2 in ~January: tormach/hal_ros_control#4

[uLipe]

@samuk this is awesome, and its the same path that ROS2 evolved along uROS, the communication interface is standard regardless the underlying communication hardware.

For example the microROS espIDF component supports communication using UART, WiFi and Ethernet, allowing high communication bandwidth and consequently, low latency commands from ROS2 to uROS, also using the embeddedRTPS it is possible to create networks of uROS devices only that are compatible to ROS2 and any other project that uses DDS middleware.

ROS2 ans uROS also evolved from realtime perspective, allowing various policies of executors where it could be chosen for processing effort or real time favor.

Also @runger1101001 , @samuk , have you considered to use the esp32 on the esc module instead of stm32?

I know I work for espressif and this would sound marketer, but esp32 already offer MCPWM, Encoder, and ADC, also it is dual core with full SMP support, where Core0 could be used for bare metal motion control along with Core1 which could be used to run communication stack ( uros or even machinekit).

The second unit, the m5core could benefit of same architecture, by running kinematics and higher level controls on core0, leaving core1 for communication stuff ( other uRos node or other DDS).

Also the esp32s3 chip has vector instructions which has native supoort from the toolchain and with some assembly wizard, if needed , the low level controls would reach another level of processing time.

Please let me know if this suggestion would need to be separated from this discussion.

I'm intending to study a bit more of machinekit although as far I remember it is more tied to manipulators and high DoF systems instead a mobile robot like the Rosmo would appears currently.

Folks it is being very nice to explore the possibilities with you :)

[samuk]

"a fairly simple control layer, similar to the many commonly available I2C motor shields."

Random thought which is probably silly, could we just emulate Adafruits Motorhat? so the board could be a drop-in replacement for Adafruit motor shields, as used in Jetbot for example.

[uLipe]

@samuk, I like the idea, although I think this kind of compatibility would be an optional to the design.

The advantage of having an open-source, yet easy to use, ESC board based on brushless motor is the possibility to open all the states of the FoC engine, to the host computer of the robot, the local brain, or the remote brain.

The FoC Engine open would enable for more efficient control of the torque into the wheels, also would enable monitoring the currents and voltages inside of the torque loop.

So I would prefer the main communication model is the same in the I2C commander, or other way that opens-up the motor states and command, for example if the design extend for a manipulator or a MIP-robot torque control is so important as velocity + positional control during trajectory execution.

What about implement inside of I2C commander a command to toggle between adafruit compatibility, or advanced communication and leave the first as default for newcomer users?

[samuk]

"What about implement inside of I2C commander a command to toggle between adafruit compatibility"

That sounds ideal, I don't want to overcomplicate things though. If it makes things too difficult lets drop/ defer the idea. I wonder if the Odrive API be emulated at some later date.

[runger1101001]

Hey,

The "controller" side of I2CCommander is very simple at the moment. The concept, as @uLipe points out, is to expose the details of the FOC controller like the PID values, control modes etc, so the users can benefit from the advanced possibilities of a brushless motor with FOC control.
After all, a setup with closed loop SimpleFOC will provide very high precision basic odometry, fine control over speed and torque, position control for robotics applications, etc...
We can aim to make these things simple for the user, but we can't abstract them away completely if users have the freedom to pick their own motors, or change the drivetrain, etc...

So I think it would be easy to add a compatibility layer for the Adafruit type of control (which is very basic), but we need to keep the underlying "SimpleFOC layer" as well.

[uLipe]

Yes, I thinks both can coexist, the point of openning the FoC states for the host is to provide a huge advancement to the ESCs out there, which is the flexibillity of control the commands and states which the only ESC that provides that is Odrive, which would be a pain to build from source.