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
Thanks to my brother this the 4th robot body we can use in our experiment.
We would like to use updated technology wherever it’s possible:
- best 3D printing technology we could reach (and pay for )
- light polyamide material
- precise printing
- strong result
- BLDC servos
- much better movements
- better speed
- high efficiency
- Very clear design
- stronger parts
- dimensional stability
- easy to assemble and work with
- has its own designed holder
- much easier offset operations
- Built-in mirror for proper onboard camera handling
- Removable battery holders (for C and D type)
- Arduino mega 2560 Rev3
- I would expect better serial data transfer
- New Bluetooth UART modules
- Replacing HC-06 based module I would use better component and faster communication
- Under testing
- We will also try to use LiPo instead of alkaline battery for stand-alone walking tests
Only the used cell phone, wires and ultrasonic sensors are going to remain the same as before.