Software_Servo/Motor controller service

-

I am going to cover both Servo and Motor controller services in this post since they are quite similar internally and have similar functionalities.

Starting with the servo controller service, its responsibilities are to find the servo control unit port by sending the "query" command and assessing the response, connect to the servo_ctrl queue, connect to the servo controller through serial, read incoming messages from the servo_ctrl queue and to send them to the controller unit using serial. It also has a separate thread constantly checking to see if the port is still accessible and to stop the service throwing an exception if it is not, and a simple mechanism for stopping the service if a few consecutive commands send to the controller were missed (a simple implementation of the leaky bucket counter pattern). As you can see:

servo_controller_service 

this part consists of serial command, responsible for sending commands through serial to controller, which has a serial connector, responsible for handling serial connection subtleties(settings), CPPAMQP which is a C++ wrapper around librabbitmq making it more C++ friendly (note that the CPPAMQP.cpp file containing implementation is omitted purposefully, I have not yet decided to make it publicly available), utility with the port finder function, and main. I have also wrote and included a simple makefile to help building entire program using $make command(you are going to need GCC11 supporting std=c++20), and a dockerfile to create an image from the final executable. I am using ubuntu20.04 on raspberry pi4 1G.

 docker command used to build is something like:

 sudo docker build -t servo_controller_service:0.1 .

and running it as a container:

$sudo docker run -d -v /dev:/dev --privileged servo_controller_service:0.1 "xxx.xxx.xxx.xxx" "yyyy" username password

needless to say you definitely need -v /dev:/dev and --privileged since you are going to access the ports. xxx... refers to the AMQP server address, yyyy is the port and the rest are credentials.

I have tested CPPAMQP in my previous projects extensively through multiple different unit tests but due to the tight coupling caused by the intense software/hardware interaction the rest of the parts are all tested only physically(for many extreme cases, for at least 24 hours).

The motor_controller_service is quite similar to the servo one, with minor differences:

motor_controller_service

aside from some settings, it has an additional thread that sends a heartbeat signal to the motor controller every few seconds so for example, when the motor is working and the cub is moving forward due to some command, and then the controller gets disconnected from the service controlling it, the disrupted heartbeat signal will make the motor controller notice, and stop the motor and hence prevent the cub from moving further in the lack of any control. This behavior is not necessary for the servo controller because there is no danger for it to keep its state when disconnected from service. There is a makefile for building this service as well.There is also a dockerfile to create an image from the executable(similar to the previous one, both for building and running).

Exchange, bindings and queues, are formed as the publish/subscribe, like this: 

publish/subscribe pattern

The services each subscribe to their corresponding queue and listen for incoming messages. All settings of this formation are quite normal. there is an exchange called "med" bound to two queues, "motor_ctrl" and "servo_ctrl" using "motor" and "servo" routing keys. But there is a small subtlety in declaring these queues. There is an argument called "x-message-ttl" which should be set to some value around 1500-2000 milliseconds. This way old unconsumed messages inside queues will not last longer than 1.5-2 seconds and will not cause cub after say a connection problem to act strange trying to execute all those outdated commands.

 

Arash Ardeshiri

July 31 2021

Comments

Post a Comment

Popular posts from this blog

Mechanics_Chassis

-
Image
  A chassis is the load-bearing framework of an artificial object, which structurally supports the object in its construction and function. More on chassis   Chassis    For this part I used a couple of metal plates and a few spacers to build a chassis and fix front and rear parts: Metal plates  First I fixed all parts on a one piece plate, but then I decided to make it more flexible and give the chassis a bit of freedom so that front and rear parts be able to turn around the same axis independently. I used a wheel like this: I fixed front and rear on two separate plates, removed the plastic wheel and used it to connect two plates. Connection between two plates   So this is the final chassis:    Completed chassis Underneath and so this form is possible now:  After all, obviously this way of fixing two parts is in no way vital and even may cause problems and be changed later.   Arash Ardeshiri June 30 2021  '  
Read more

Software_Video streaming services

-
Image
This is the last part of the first phase. With this part completed we can control the cub while being able to see through its camera (probably even cameras) connected to the cub's raspberry pi. First I was going to use VLC for streaming the camera video but aside from an annoying 3-5 seconds delay, I did not have any easy access to individual frames for further possessing, so I decided to write a simple service for it using python, flask, and Open-CV.  The webcam used on the cub First I wrote a simple web server running on cub raspberry waiting for requests from the client-side, capturing a frame and responding with the captured frame when receiving a get request. Then I also added some meta-data to the returned data, representing frame dimensions and channels to make it easier to decode the frame automatically which happens on the client-side. Soon I realized I need to be able to change both dimensions and channels of the frames from the client-side and added some meta-data regard...
Read more

Software_Joystick service

-
Image
As mentioned before in this phase, before making it autonomous I am going to use a joystick to control the cub. This is what I am currently using: Logitech Extreme 3D PRO There are many ways to get the output from these devices. There are lots of libraries and we can even read the data directly from the device which is not flexible. For this purpose I am going to use SFML which is basically a lightweight 2D game engine and I have some experiences using it. The way this library is usually used is through the game loop, the loop that goes on and on through the entire period of the game, each time returning all of the events regarding mouse, keyboard, joystick, etc in the context of the game window. Since we don't need the game window and the game loop we should use the other way.  We are going to use it using the update function manually and subsequently checking for the joystick events.  To make the code more open-close I used observer/observable pattern. There is a class calle...
Read more