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.

[uLipe]

@samuk , @runger1101001 , should I start to port the I2C commander as a esp-idf component?

[samuk]

@uLipe I'm excited at the prospect. The principle sounds good. I defer to @runger1101001 on the timing question.

[runger1101001]

Hey, if you want to start, I definately don't want to stop you!!

I am planning some refactoring of the I2CCommander, but this will be mostly on the receiving side. In the longer term future I would like to add SPICommander and CANCommander, using the same registers, and might refactor a little more at that point.

The I2C master is really very simple, you could port what is there with not much effort. The important part is really only the registers header file, which will give you the list of registers (commands) supported.
The rest of the I2CMaster is just send some bytes receive some bytes code, and could be solved in many ways.
Its important to carefully read/write always the right amount of bytes, or the I2C bus can become stuck.

A feature worth supporting is the "report" feature, which allows the master to define a set of registers as a "report", and then read all the registers with one command. That saves a lot of protocol overhead if you're always reading the same set of values, a common use case I would expect.

[samuk]

@uLipe do you think you need any further info? Or would this be enough to get started?

[uLipe]

Hello @samuk , @runger1101001 , sorry for being away these days, I got the flu.

I think from my side we have now sufficient information to start building firmware, said this would you folks think I can create the firmware repository for the motor controller?

Since its responsibillity is well defined, it is also simple to prorotype some circuits while the boards get ready.

If you give me the go, I will proceed creating the firmware repo, onde point, ArduinoFoC was engineered with Arduino in mind, so the motion controllers would be developed using the Arduino (Platformio?) ecosystem right?

[uLipe]

Before I forget, have you chose a particular BLDC motor plus encoder? ArduinoFoC does not have the sensorless FoC (which I personally think is only usable in aerial robotics), se we need to define also the rotor position sensor. Of course I would always prefer an opto encoder with quadrature outputs. Because SPI / I2C encoders are very slow to process in high speed scenarios or high velocity rate variation.

[samuk]

@uLipe sorry to hear you've been ill. Welcome back.

Feel free to go ahead and create a repo. Yes SimpleFOC is an Arduino program. The I2C commander linked above will be the interface to it.

We're going to use these magnetic encoders that @runger1101001 has developed. As no one was selling them with SPI cabling/sockets he's just getting ready to produce & sell them on his Tindie page.

[runger1101001]

Hey, when we're talking about the module firmware here, we're talking the ESP32 code... so the business of porting I2CCommanderMaster and doing the ROS integration...
For the ESC's STM32 firmware, I will make a repo, I have most of the code I need for that together already.

[runger1101001]

And note there is no rush, the ESC boards won't be here until end of Feb, due to Chinese New Years.

[uLipe]

@runger1101001 , thanks for clarification, I misunderstood the question.

That is said, I'm focusing on esp32 side, hopefully I have an m5stack core in my hands so I can consider they form factor to bring-up the component.

By moving with the IDF approach, the module firmware would be a component compatible to the ESP-IDF and inside it it would be possible to provide some application through an example folder, which is compliant with IDF component structure.

Other thing I would like to highlight is uROS supports WIFI interface, which I see very interesing cases of Rosmo robot fleets :)