09/18/2022 at 21:16 •
Yesterday I merged a big software update to the Zakhar’s Raspberry Pi Unit -
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_serviceand shows some important information on a small OLED display:
---------- more ----------
- 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.
08/31/2022 at 19:28 •
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.
08/17/2022 at 19:06 •
Updated code for the Sensor Unit with qCAN support is merged and documented!
---------- more ----------
- Source code: https://github.com/Zakhar-the-Robot/io_sensors
- Documentation: https://zakhar-the-robot.github.io/doc/docs/systems/io_sensors/
08/07/2022 at 21:05 •
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 😍.
07/21/2022 at 19:50 •
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:
---------- more ----------
- 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
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:
The full protocol description is available on the Zakhar documentation page here:
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!
03/07/2022 at 21:25 •
Behold a new project site!
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
02/06/2022 at 13:16 •
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:
- Remote access to Zakhar's data flows
- 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)
12/26/2021 at 16:55 •
It is done for my robot but can be used everywhere else.
Using a system of descriptors, you can easily:
- send data to the bus periodically
- automatically store data with specific IDs
- send data in response to the RTR request frame
The developer should specify Store, Response, and Transmit (with a period in ms) descriptors and the library will do the rest.
(See the examples: https://github.com/an-dr/zklib_espidf_canbus/blob/4d035b858cc110205f38b9929921d9b5e17ceaf2/examples/node_second/main/main.cpp?fbclid=IwAR1EUVprCHFiITDI6DBwHrnfDYgci81jCXmbXv-WSzSBdhhNuxY-8lDkLOQ#L35-L64)
The only missing and important thing is a mechanism to check which device is online. It will be implemented soon:
As always, any contribution is welcome. See the opened issues (https://github.com/an-dr/zklib_espidf_canbus/issues) or create a new one.
Join the group on Facebook! https://www.facebook.com/groups/zakhar
12/12/2021 at 20:52 •
The project is ambitious, and I cannot move it that fast as I want to. If you are as interested in robotics as I am, let's try to work together. I'm confident that we will develop something unique!
The project covers many different areas and programming languages, including:
- 3D modeling (for simulation)
- 3D printing (for the robot itself)
- C / C ++ development (embedded: Arduino, ESP32, STM32; hi-level: Linux, Robot Operating System - ROS)
- Computer vision (image recognition, especially for indoor navigation)
- Hardware design (robot modules)
- Python development (Robot Operating System - ROS)
Please look at the list of repositories and non-green milestones below, see the issues, and take something if you want. If you want to participate but do not know where to start, create an issue in the main repository, and we will figure this out.
Any volunteer participation will be appreciated!
12/12/2021 at 01:47 •
In the upper part there are two ESP32 stacked together, bellow there is a Raspberry Pi with my new CANbus hat and a CAN test tool.
The Raspberry part needs some tweaks from the Linux side plus a python CANbus subpackage. ESP32 Can library works excellent.
Since it is needed to write a library for STM32, Arduino, and who knows what else I want to build an Arduino-based CAN test/verification tool (lower right corner). The hardware is ready only code remains.
The main project of the transition from I2C to CAN is here, many things need to be done.
Want to join development? See links below!
https://github.com/an-dr/zakhar_service (Python, Linux)
https://github.com/an-dr/zklib_espidf_canbus (C/C++, CAN, ESP32)
https://github.com/an-dr/zakhar_tools (C++, Arduino, Hardware)