After coding many different types of movements like boxing and typing I wanted to have a better control “language”. For these movements I used atomic servo commands: servo 1 goes to 90 degrees, servo 2 goes to 47 degrees, etc. The scheduling was solved by a simple timer and all the phases were activated by a counter and threshold values. If counter is less than 10 move to start position, if counter < 30 move the servos to first phase position, etc. All this was very boring and required a lot of calculations. On the top of this it was absolute dependent on timer period. All the threshold values had to be recalculated if I wanted to change the speed.
I needed something more flexible and timer independent solution which was able to handle complex commands. 2 simple Java classes solved the problem
Instead of sending a simple servo position (atomic command) this class has the below properties to form a higher level instruction. Progress is calculated by the class knowing the start time, duration and the control frequency. So the timer period can be changed free.
- command type (IK leg positioning, balance mode on/off, sensor reading, etc.)
- command state (added, started, finished, etc.)
- duration (in ms)
- start time (ms)
- delay (ms)
- repeat flag (when the command ends it adds itself to the queue)
Command processing rules:
- All timing calculation uses milliseconds
- Any positioning uses IK and builds on the last position using linear transition
- Any command can be deleted any time independently from its state
Command queue class
This class handles complex command lists which could be extended or even deleted any time.
Queue processing rules:
- The processing order is simple FIFO where every completed command is deleted from the queue (except repeat flagged ones)
- The queue can be manipulated any time on any way
This way a more difficult control can be developed where the main robot logic can send command queues, extend them or delete or replace any time. I know that this is just 1 step towards the behavior programming but on a higher level you can request very complex tasks like: discover a room and come back to the base and report the results…
The queue itself is visible on the Android app together with the current command progress. So you don’t have to read robot brain just watch the screen
Queue elements in green, progress is above the list:
This is a milestone video because we always wanted a real jumper This is far from perfect but can be a good base for further development. On the other hand this jump test was the first real test of our brand new movement controlling software module.
This is a very hard topic. Control Systems was not my favourite subject at university (but it should have been…) I tried to avoid difficult math and googled a lot to have something simple that could do the magic. Finally all the links lead me to the same page:
After few hours of reading I realized that this just seems to be difficult and this was the simple thing that can do the magic This is more than a 100 years old theory but still works properly. The one who developed it was a real genius. Respect!
So you have basically a measured value from the accelerometer, which can be interpreted as the error value. This error is the input of any PID calculation. There are tons of math functions you could use but the PID inventor genius selected only 3! Luckily all these function can be ultra easily implemented using programming on any language.
P : use multiplication (*) Wow!
I : use + operator to store a sum. (sum+=current error value)
D: use – operator to calculate difference. (current value – old value)
20-30 lines of code in Java and we have the PID controller for our 4 legged robot!
For few seconds I tested the accelerometer feedback without balancing and after that I checked different PID control modes (P, PI, PD, PID)
Check the result:
I would call this robot R4 because this is our fourth robot and this naming convention could be used for any previous ones too
Offset works are done with the new Android based software module. It wasn’t too complicated thanks to the professional holding frame which was designed for offset tasks.
The harder part was to update our Android application and enable robot selection. I wanted to handle both R3 (black) and our new R4 (white) robot with the same java functions. The base request is simple and “only” a new RobotParameter class had to be developed. It is able to store 68 parameters (Starting with body length, width, height, leg part sizes, blue tooth address, servo offsets, etc.)
The updated main screen with robot selection buttons:
Few tests to check offset values (simple standing, IK control and quick walking on my desk)
PS: I removed the audio track from the video because of the … high level of background noise (my family😀 )
I was very happy to work on the new robot but this 7-hours wiring task simply changed my state to catatonic😀 I could react to my environment but I didn’t want to😀 After few beers everything was OK again.
7 hours in pictures:
Soldering this little component required much more attention I had😀 Let me mention some steps: saw the PCB, file all sides, remove one line, treat everything with soldering flux, connect the small 3-hole segments, … and measure the result. Do it 5 times!
Last time I simply soldered the PWM cables straight. This orientation caused a lot of problems why the new power bus uses a special “V” form. It’s much easier to solder, build and push back when the servo cable connected. And it always has to be pushed back…
Final result : 4 power buses for servos (6V) and one for commonly used 5V.
Power buses built-in
and connected to all servos. Plus tons of zip cable ties used to … tie the cables
Another interesting part was to solder 3 BEC units and mount them on the robot body…
At last its ready to dominate any other robot in the house
As you can see the higher the frequency the smoother positioning. There are only few things you need to take into account:
- the servo (digital) itself uses about 300-400 Hz control frequency so its unnecessary to use more Hz
- bluetooth and UART / Arduino module has a theoretical limit of data transfer (lets say its 115200 -> with a 26 byte pack size -> 443 packs/second) In practice the communication channel dies in every 30 seconds at 66 Hz This would mean “only” a 1 second black-out but in our experiment it is unacceptable.
- mobile phone CPU load is higher in case of fast communication but I would allocate more CPU on walking and balancing calculations…
In our case the perfect control frequency is somewhere between 40 and 50 Hz (with the available hardware of course).
Please check out our normal vs BLDC videos and pictures. I would let you decide😀
Normal servo slow motion and 90 degrees fast positioning:
Same with BLDC:
Normal servo movement speed measured with video recording and simple frame analysis:
19 degrees / frame (1/29 sec)
40 degrees / frame