RB Running Squares

[Bastian]

Hi there,
I have been digging in on some odometry topics and got the bot running in (rather) straight lines at a certain speed for a certain distance using optical encoders and 3 PID’s.

The video isn’t thrilling, but shows an intermediate result in calibrating the positioning and RB almost finishing a full square with a total perimeter of 12.2 meters.

Video:
https://www.youtube.com/watch?v=8z0CsYaxo8Y

For those who are interested, the following blog contains a more detailed description of the background, approach and a way to use squared runs for further calibration:

https://plus.google.com/113179308235478830494/posts/UiFYacTvDLr

If wanted remarks, suggestions and/or questions can be dropped there as well.


The Python script can be found at:
https://bitbucket.org/RoboBasics/raspberry-robo-cars/src/8df278bd8786da754462197c3b553d1aaa40f599/Scripts/Odm_2_running_squares.py?at=master

I noticed in the forums that several people raised questions on having the robot running straight. The bitbucket repository also contains a Python script for mere proportional correction of the wheel differences. If just straight driving is desired, this script might be helpful.

The approach is a bit raw (left out some things like the acceleration), but it provides a good start for further exploration.

For sure I will work on some improvements in the future (and surely acquire some magnetic encoders for better actuating).

For now I will be working on adding digital compass data to the control loops (or replacing the balancing loop by a compass loop)

Enjoy !

[Alan]

Hi Bastian,

That looks really good. I haven't looked at your code in much detail, but I'm really impressed that you got your control loop to run using py_websockets_bot (i.e. not within the web server). Were you running oyur control script on the robot, or on a separate computer?

Regards

Alan

[Bastian]

Hi Alan,

It is running remote on a W8 computer. The script is rather straight forward to keep the coding challenges low (for me). So, I had to take some shortcuts in the solution. In the Google-blog I describe the reasons.

Then one of the two major challenges was of course the timing. I think the sample_time is on the edge of workable. Using py_websocket_bot I couldn’t get it much lower than 0.05 anyhow.

The timer generates weird peaks even when working in plain Python without your classes on several computers. I’m not sure if that’s due to Python. I’ll want to recode the script in C/C++ once, to find out if that’s the case.

The other phenomena was the difference in performance between the left and right motors. I could get one side working with a perfect graph. The other side fell short on the max PWM. Thus resulting in too much weight of the balancing loop in the controlled part. In the blog I mention almost everything I tried, but I’m still guessing for a solution.

Anyhow the outcome is satisfactory as an intermediate result. I’ve just ordered the Grove compass. I’m curious if I can add that while still using py_websockets_bot.

The epic after that will be trying out the improved Dagu mini driver. I’m thinking of building the control loop, including the compass, in Arduino. The memory should be sufficient now, I think.
That will leave me the Raspberry (also probably Model 2) to work on locating and mapping, incorporating vision control. (I might be needing your help in implementing the new Dagu board in py_websockets_bot)
And of course I’ll try more qualitative encoders as well then. (You’ll have them launched at your store by then, I hope). ;-0)

So still a lot of fun ahead and I’ll be back when I’ve something I can share.

Cheers,
Bastian