After a couple of months trying to make something meaningful of my project, we with my small team have made a soft reboot. Why do we need it? The architecture is BAD. Before starting learning software architecture, I was just trying to mimic what I've seen working in Espressif and Rockwell, I was trying to follow best practices of Python, ROS and C++. I sounded like a good idea, and when I tried to add people to the project - it got stuck.

What problems did we face? 

So here a list:

1. We had a nice idea, but the closest milestone was miles away.
2. The idea was nice, but not precise. What the pet companion should do exactly?
3. We had my documentation that does describe the project architecture well enough. And even myself was not able to explain everything, because I just forgot a lot of things.
4. We had a lot of dependencies by default, so everyone why wanted to develop something had to understand everything before start to develop.

Why did we have all this problem? 

Because I started from the middle. I wanted to build something using particular technologies implementing a new technology, and did not have the clear vision of the result. 

It was a research project and as it turned out it's very difficult to convert it to something more substantial.

The Solution

We've decided to split the work into intermediate prototypes that should do something particular. I will rebuild the architecture from scratch, taking only useful pieces of my monstrous legacy. We've started from the Use Case scenario. The use case of our first iteration is the following:

1. The user turns on the robot
2. The robot starts to explore the space using a camera and microphones
3. If it recognizes a pet (cat or dog) it moves closer to the pet
4. When it is close to the pet, it makes a sound.

That is it. The diagram looks like this:

Here is our current phase documentation:

https://zakhar-the-robot.github.io/doc/docs/architecture/phase-1/

Meanwhile, I continue working on my more mini project LeOn which is the source of our current discoveries about the project architecture: https://hackaday.io/project/192732-leon

This project is really heavy. It grew organically and need a revamp to be manageable and fun.

I started a new project to entertain myself and to kick this one, It is called LeOn. LeOn is a simple robotic toy for cats, but it supposes to contribute to Zakhar. Main features of the LeOn project:

🔷 Architecture-oriented 

🔷 Result-oriented and minimalistic

🔷 Integration-oriented

🔷 Reusable in my other projects

All features are supposed to accumulate best practices and solutions, so they can be integrated to Zakhar back. Consider it a mini prototype 🙂 

https://hackaday.io/project/192732-leon

Last year was tough but also productive. Several of my friends had joined the Zakhar team and we will try to build a real product. 

We've come up with the idea of creating a pet companion! Dogs and cats only for now 🐶😺.  (Check the updated project description). We will be moving towards this idea and the project will remain open-source, so even when we finish you will be able to build your own companion from sources!

There are a lot of things that should be done here and we going to entertain you with our test videos. For now, check out the ears that I 3D printed for the robot!

Yesterday I merged a big software update to the Zakhar’s Raspberry Pi Unit - brain_service.

The update brings a service providing the robot’s status (network, OS status) and access to the CAN bus for many simultaneously connected clients. Also, the service tracks the presence of other robot Units on the CAN bus.

There is another service shipping with the same repository brain_service_display. This service connects to brain_service and shows some important information on a small OLED display:

• f - Face Unit
• S - Sensor Unit
• m - Wheeled moving platform (“Motors”)
• t - Service Unit (“Tool”)

The service structure is presented below:

The service publishes status information and incoming CAN messages to ZeroMQ subscribers. The service allows all TCP connections including connections from external machines. See brain_pycore for compatible subscriber and client implementation classes.

Sources:

• https://github.com/Zakhar-the-Robot/brain_service
• https://github.com/Zakhar-the-Robot/brain_pycore

Before updating Alive OS to support qCAN (my CANbus based protocol) I have the last thing to do. To simplify my live in future I need a CAN publisher that can publish messages to many subscribers. My main subscribe of course is AliveOS but also to display information about connected devices I need a second subscriber - a service listening only qCAN Present messages.

To do it I will use a ZeroMQ protocol - an extremely supported and documented for many programming languages standard. I’m going to update my brain_service to support the protocol and it will be responsible for all interaction with Raspberry Pi.

Repositories:

- https://github.com/Zakhar-the-Robot/brain_pycore
- https://github.com/Zakhar-the-Robot/brain_service

(original: https://blog.agramakov.me/posts/2022/08-31-brain-software-architecture/)

Updated code for the Sensor Unit with qCAN support is merged and documented!

• Source code: https://github.com/Zakhar-the-Robot/io_sensors
• Documentation: https://zakhar-the-robot.github.io/doc/docs/systems/io_sensors/

The new Unit is based on the ESP-Wrover-Kit and uses a TJA1050 module for CANbus communication.

It is compatible with the qCAN protocol (described on the Zakhar main page) and can show 5 facial expressions: Anger (0x32), Sadness (0x34), Pleasure (0x33), a Blink (0x31), and Calm (0x30).

To control it you should send a CAN message with an expression code using a 125Kbit standard CAN frame and with the message id ending with byte 0x4. E.g. send a message with ID: 0x004, data: 0x33 to make Zakhar happy 😍.

Read more on the Zakhar main page.

Not Only Two Wires

It’s been more than two years already since I started working on my robot Zakhar. The Zakhar 1 was built out of Lego and relied on I2C communication between modules. It was a nightmare because as it turned out each MCU developer has its own understanding of how a developer should interact with the I2C unit. What I wanted from the interface:

• Main/secondary nodes interaction
• Understand what devices are in the network
• Send commands
• Receive sensor data

To make all this possible I’ve developed a simple I2C-based protocol but couldn’t get the desired behavior (read more in my post) on all platforms - Raspberry Pi, STM32, Arduino, and ESP32. Overly Zakhar 1 had too many problems to continue the project - mechanically it was floppy, power sources were unstable, the display was flickering, and the interface… It was too distracting, unstable, and annoying to continue!

I started Zakhar 2 based on the CAN interface. Why CAN? There are many advantages of CAN compared to I2C:

• Better MCU developer support
• A single data frame contains much more information than I2C
• Physical layer - actually not specified, but de-facto it is RS485 and it is much suitable for heterogeneous systems with several power sources:
  • Really two-wires interface, without a common ground
  • No voltage levels shifters
• Embedded addressing mechanism
• Still simple

There are cons of course. The main one is that not all platforms have hardware CAN bus support. But there are many external modules on the market, there are tons of drivers developed for all platforms, and there are thousands of guides written, so it is easy to mitigate.

Yes, a new protocol!

I like developing standards. I really wanted to invent my own bicycle. Also, I wanted to make a transition from I2C to CAN smooth keeping all implemented features and continuing established directions. And likely for Zakhar 2, there was no good candidate. Had no reason not to develop my own CAN-based protocol. Here is not the full list of my options with the main reason to say no:

• CANopen - too complex
• DeviceNet - CIP, not needed (hello my employer!)
• SAE_J1939 - too complex
• CANaerospace - too complex
• Cubesat_Space_Protocol - better, good support, but excessive
• Very_Simple_Control_Protocol - not very simple

The Bicycle

It is turned out, that I don’t need to build a lot on top of bare CAN. The protocol is based on the usage of the ID field of the CAN frame. The field carries all the necessary information for the protocol. Here are some illustrations for the Standard and the Extended CAN frame (my know-how is in green):

Each device has its own address, an ID. Information about the source, the destination, and the message type is embedded info the ID filed in a way that makes it simple to read by a human in HEX format. For example, if the device with the id #5 sends a message of type 1 to device #3, the message ID will be 0x531 and 0x0503001 for the standard and the extended frames respectively.

Since CAN bus devices by default are constantly sending data in the network I used it for device discovery. All devices should send a Presence message at least once in 3 seconds. If not, the device is considered disconnected.

With such a message structure, it is very simple to address commands not only to a specific device but also to broadcast them using the destination of 0x0. Also sending data information can be broadcasted as well as dedicated to a specific device:

Commands

Data Messages

The full protocol description is available on the Zakhar documentation page here:

https://zakhar-the-robot.github.io/doc/docs/communication-protocols/canbus/

What’s Next?

I’m finishing the firmware implementation for all my robot units. In the next article, I want to talk about the protocol implementation in the Zakhar the Robot project.

Nice but What’s About the Alive Robot?

The main purpose of the project is to investigate the potential of animal-like behavior for the human-robot interaction. It is a big sophisticated topic and working on this demands a reliable hardware basis. I plan to spend some more time working on this. Then I will return to the high-level problem. Also, as I am a low-level developer I know that the hardware architecture defines high-level possibilities so it is important to make it right. Thanks for your patience and stay tuned!

Links

• My blog
• Standard Documentation
• Facebook
• Instagram
• Hackaday.io project page

Behold a new project site!

https://zakhar-the-robot.github.io/doc/

It is not fully ready yet, but I hope it will help to organize the project and develop it faster and more efficiently.

Also, I've created an organization for the project on GitHub. All repositories will be transferred there: https://github.com/Zakhar-the-Robot

Finished yesterday a Bluetooth device for CAN bus monitoring. Need it to continue the integration of CAN into the Zakhar communication (closer Issues is https://github.com/an-dr/zakhar_platform/issues/12).

It serves two purposes:

1. Remote access to Zakhar's data flows
2. It is a node on the CAN bus, so all devices will get ACK response and won't fall into the error state

The data is printed in the CSV format, so it is easy to analyze.

The code is dependent mainly on:

• https://github.com/an-dr/zklib_arduino_canbus - it follows the Zakhar CAN network convention (https://github.com/an-dr/zakhar/blob/master/docs/canbus.md) but without requests implementation for now.
• https://github.com/an-dr/arduino-mcp2515 - a slightly modified version of popular CAN library for Arduino (https://github.com/autowp/arduino-mcp2515)

Sources: https://github.com/an-dr/zakhar_tools
Schematic: will be added later (https://github.com/an-dr/zakhar_tools/issues/4)

[https://www.facebook.com/groups/zakhar]