A simple robot-companion for my cat. Main project features:
🔶 Architecture-oriented
🔹➡️ Develop the right architecture using architectural best practices
🔶 Result-oriented and minimalistic
🔹➡️ Progress over perfection
🔶 Integration-oriented.
🔹➡️ Reusing existing libraries, projects, etc. Minimum development of individual pieces
🔶 Reusable in my other projects
🔹➡️ It should be done automatically with a good architecture. But I want to make several special decisions to make the project easy to transfer to my another robotic project.
Files
leon_stl.zip
3D models needed to build LeOn
application/x-zip-compressed -
634.86 kB -
12/08/2023 at 21:52
I'm developing a mechanical framework for my robotic projects. It is called simpleR. I would like to make in the way suitable for robotic prototyping and education. For the research purposes, I've decided to reimplement LeOn in my new framework, developing two projects at the same time and hoping for the synergy effect. Let's see how it goes 🙂
Separation of the Software (independent of the hardware logic) and the Firmware (dependent on the hardware) has allowed me to implement the main robot logic on Windows without involving MCUs at all.
I packed all the code in a set of CMake projects producing static libraries. Including main.cpp - it is also a component. Then I assemble everything into an executable file - currently for the Windows platform. It can be called a Windows robot simulator:
The next step is to implement the driver part and then connect them together.
Quick QnA:
Can it be done directly on MCU? Yes.
Would it be faster to do this? Yes!
Would it be scalable when the project grows? No!
Could I easily port parts of the code to my other projects? No.
Initially I wanted to implement interfaces as simple header files, but after reading articles from Jacob Beningo (e.g. https://www.beningo.com/how-to-write-epic-hardware-abstraction-layers-hal-in-c/) I’ve decided to go with abstract classes and structures with function pointers. This allows me to pack the interface as separate components, decoupling other components even more. The result is on the updated component diagram:
Before coding, let’s decide on the Software Architecture. Based on my previous decision, I’m going to have two main parts:
Main Application
Movement Server
Movement Interface - to communicate between them (e.g. CAN library)
Each part will have a high-level and a low-level logic. I will use two terms, movement - for transportation in space, and motion - for any other physical activities. In total, we will have:
Motion Controller
Motion Driver
Movement Controller
Movement Driver
To break the direct dependency, Controller→Driver let’s use a Hardware Abstraction Layer Interface, so we will have a dependency on a stable interface rather than on a driver that can be changed in the future:
Controller→HAL←Driver
By doing so, we isolate the high-level logic of hardware changes.
Let's introduce two more terms:
Software - logic, depending on a use case, a practical application.
Meanwhile, I’m preparing a simple prototype, since my architecture already has enough information for hardware steps.
I'm going to go cheap 28BYJ-48 stepper motors and probably a DC motor for the cat toy. When it is done, I would like to port it to a different hardware and verify that my architecture does not require any changes, something like this: