This is the first log recording for Servio, written retrospectively, as in the early days, I was preoccupied with developing the project and did not think about documenting the process. (A habit I find problematic, as writing things down generally helps in not forgetting something or passing information to others.)

Let's start by describing how and why it all began, focusing more on the why rather than the exact details.

What is smart servomotor?

First things first, what do we mean by a "smart servomotor"? It's a good idea to establish expectations and an understanding of basic terminology.

In our minds, a servomotor is a physical part with an output axis. The servomotor takes an input and, based on that, rotates the axis to a specific position determined by the input (with position being an angle of the axis).

While this is a predominant use case, there might be instances where we want the servo to spin the axis and hold angular velocity. Instead of focusing on the position of the axis, we might want to control how much force the axis should apply to spinning.

This component is fundamental for modern robotics, allowing us to use servos to articulate joints of robotic arms, spin wheels, or perform other actuating tasks.

What Makes a Servo Smart?

As far as I know, there is no strict definition, but generally, we can say that one can interactively communicate with a smart servo (we can send it a message, and it will respond), while simple servos just receive input in some form (such as PWM, for example).

The benefit of a servo being smart is that, apart from telling it what to do, we can inquire about its success. With some servos, we can also monitor how well it is executing operations or how much force it required to do so.

Motivation

We embarked on this journey with myself, Jan Veverak Koniarik, having the most available free time, and a friend of mine (yaqswx - Jan Mrazek). At the time, we were both Ph.D. students in robotics, sharing a common need for decent open-source servomotors in our research projects. Given that my friend was also a member of the local robotics club, there were more people interested in open source servo.

At that time, there were no open-source alternatives (though this might have changed over time; unfortunately, I lost track of other projects as I became engrossed in my own). Proprietary alternatives could be narrowed down to two options:

Dynamixel or similar: Well known brand (at least in the academia) with well equipped features, whitch is also well priced. We did liked our experience with dynamixels we just found them too pricey for open-source robots. Traditional industry uses different brands of servos, with even much higher price than Dynamixels, so that was no way to go.

Lewansoul (renamed to Hiwonder): Much well priced servomotors with quite a decent hardware quality (servomotor with metal gears for +-17$ at the time (2021) was a steal), however the software quality was kinda disappoiting, or more precisely: The quality of the smart part. The control loops of the servomotor were not the best and there was lack of configurability over communication protocol. That is: this was cheap enough but not capable enough.

So, we said: what the hell, it can't be THAT hard, how about making our own servo? (Obviously this assumption failed miserably)

Early goals

We began by agreeing on the specifications and expected milestones. Initially, we were ambitious, but eventually, we set on set of goals that we did not fully met, but turned out to be practical enough:

1. The firmware is written in C++.
2. We use CMake as a build system, following standard practices as closely as possible.
3. Basic principle: Servio is a device that responds to messages sent over a communication bus and executes a closed-loop control loop for motor and encoder.
4. Three control modes: position control, velocity control, and current control.
5. A minimum of a 10kHz control loop for current control.
6. Develop basic automated tests.
7. The end goal is to create a replacement PCB for Lewansoul LX15D.
8. Support for potentiometer, quadratic encoder, or magnetic encoder as sensory input.

Let's discuss the goals in more details:

1. We chose C++ primarily because we are proficient in it. Additionally, we believe the language is well-suited for our needs.
2. Our choice of CMake was less about the tool itself (which I sometimes find frustrating) and more about avoiding alternatives, such as IDEs provided by manufacturers.
3. The basic principle is a solid goal as it helps filter out impractical ideas. For instance, if we consider adding battery management, we can assess its relevance to the primary function.
4. The control modes define how we envision controlling the servo - position control for moving to a specific position, velocity control for moving at a certain speed, and current control for maintaining a specific current.
5. Based on knowledge/discussions with more experienced people in the industry, we got a hint that the sweet magic trick to make PID control loops work reliably (which we wanted to use) is not perfect fine-tuning of parameters, but a high-frequency loop. When we asked "what is high?" we were told that we want 10kHz for the current loop and only 1kHz for velocity control loop is enough. Do we understand WHY this is so? Nah, but we went for 10kHz anyway.
6. As software developers, automated testing is a natural part of our process, a practice not always common in embedded systems.
   
7. We decided to focus solely on software and PCB, sourcing other components, like metal gears or casings, from our favorite cheap servo, the LX15D.
8. The last goal was actually a point of controversy among us. Yaqwsx correctly argued that magnetic encoders are superior to potentiometers, as they are more reliable, support 360-degree rotation without a dead zone, etc. I mostly argued that that might be true, but unless I can buy a servo with a magnetic encoder mounted and positioned inside, I am not interested, as I refuse to try positioning a magnetic encoder where a potentiometer used to be. We agreed to support both. (And quadrature encoders just for the sake of completeness).

So it begins

Well, this is primarily what we began with. I recommend focusing more on the essence of the text rather than the minutiae. The overall nature of it still remains valid. In subsequent logs, I will switch modes and describe the entire project from top to bottom, inside and out, including a few tangential details along the way.

P.S: This text was NOT written by ChatGPT, that unwieldy stubborn thing was used only as glorified spellchecker.