LeOn, a Cat Companion. Architecture First.
With this post, I start my new robotic project. This project will have several important features:
Zakhar Brain Service
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.
Brain Software Architecture
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.
Sensor Unit with qCAN Support is Merged!
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 Wheeled Platform with CAN support is merged!
A new step in Zakhar global transition to CAN bus is done!
New Zakhar Face Module
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).
CAN Bus and a New Simple Protocol
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:
"On the way to AliveOS" or "making of a robot with emotions is harder than I thought"
So, indeed, the more I develop the software for Zakhar, the more complicated it goes. So, first:
Contributions and collaborations are welcome!
If you want to participate, write to me and we will find what you can do in the project.
Second, feature branches got toooooo huge, so I’ll use the workflow with the develop branch (Gitflow) to accumulate less polished features and see some rhythmic development. Currently, I’m actively (sometimes reluctantly) working on the integration of my EmotionCore to the Zakhar’s ROS system.
EmotionCore - 1.0.0
First release!
The aim of this library is to implement an emotion model that could be used by other applications implementing behavior modifications (emotions) based on changing input data.
The Core has sets of parameters, states and descriptors:
Parameters define the state of the core. Each state has a unique name (happy, sad, etc.) Descriptors specify the effect caused by input data to the parameters. The user can use either the state or the set of parameters as output data.