A Friendly Overlord
I've been working on this one in silence for a bit.
Awhile back it hit me, before I started growing my Overlord project in complexity I wanted to refine it for ease-of-use. Therefore, I began translating my Overlord project into a Python module I could build off.
I figure, this would make it easier for anyone to use. This includes myself, I've not forgotten my identity as a hack, nor will anyone who pops the hood on this module :)
But, at its core, there are few essential inputs:
- Color to track.
- Compass reading.
So, I spent some time translating the code into a callable module. This experiment was mainly for my own use, yet I knew it'd grow healthier if I had LMR's feedback, elder or noob.
When I started I actually planned (gasp) out what would make this code more user friendly. I didn't think long; the two things that have taken the most time tweaking to get this code useful are:
- Adjusting the compass heading.
- Selecting the color to track.
To address the first issue, I developed a "auto-compass calibration function."
Basically, this function takes the very first compass reading and adjusts all other readings. So, all you have to do is put your robot in the direction you want it to consider "North," start your code, and this function will convert all other readings.
The second issue took me a little longer to deal with: easy color selection. In short, I rewrote most of the color detection parts of the code to take advantage of the OpenCV's CamShift algorithm. This function is more resilient to lighting changes or other near color objects, but it is also more CPU intensive. At some point, I'll probably go back and write a variant that sticks with the old largest-target-color-mass method.
Ok, what this means for the user? When the code starts you select the color you'd like by left-click and dragging a selection box over an area. The mean color of the selected area will be tracked and this will also start the rest of the code.
What does Friendly Overlord give you?
Well, a lot. And when I finish writing the damn thing, more than alot.
Here's a list, and only one bit is untrue.
- It tracks your robot, providing its x and y relative to your webcam.
- It will provide a target coordinates, which I'll later make addressable in case someone wants to do something cool, rather than have their robot drive around and catch virtual dots. Lame.
- It will take the compass reading you provide, translate it to a heading relative to the camera, then, it will send commands to your robot telling it to turn until it is in alignment, then move towards the target.
- Make you a cuppa (CP, DanM, did I use that right?)
- It will allow you to tweak pretty much any element of the code (e.g., overlord.targetProximity = 5)
What does it not do?
- Take care of your serial data. You're own your on, bud.
- Write your robot uC code for you.
- Provide you with your robot's heading (though, when I delve into two-color detection this could be done with two-dots on your bot. But really, it'd be easier and near cheaper to get an HMC5883L).
Alright, so let's talk code. How little code does it take to use it?
This is fully functional code. You'll notice that really, only about 10 lines get Friendly Overlord going, the rest handle Serial functions and motor firing. Be warned, the motor firing code will change, since it is written how I like it right now, eventually will be designed to be as flexible as possible.
- overlord.dVariables() #Sets the Friendly Overlord variables.
- overlord.otracker() # The module's heart. Handles color tracking, angle calculation, etc.
- overlord.compass(x) # You pass it an compass heading as an integer in degrees (0-360) and it does the rest.
- overlord.tranx_ready # Simple flag to indicate last bit of serial data has be sent.
- overlord.tranx # Variable that contains the serial command to be sent to the robot.
- overlord.motorBusy # Flag to indicate if the robot is still in the middle of a movement.
That's about it. In the module? 399 lines of code, or so. Still relatively small for a program but not something I want to wade through without a damned good reason.
Ok. So, where am I going with this?
Hell if I know. I want to make it as versatile as possible. Eventually, I'd like to be tracking nth number of robots. I envision a swarm of Yahmez' Baby bots flying all over the place, Friendly Overlord tracking them, and communicating with them via IR.
But in the more immediate future, I'd like to make every variable tweakable. Especially, variables useful to others. For instance, the overlord.tX and overlord.tY are currently controlled by the module. They are simply randomized numbers. But, I'll make a flag in the next two days to take control of them from your own code. You can decide where you'd like your robot to go. Whether it be to your mouse pointer (overlord.targetY = overlord.mouseY) or a complex set of way-points to lead him through a maze. Really, I'll probably code around the feedback I get.
Now, some obligatory stuff.
Here are some of the current variables addressable from your program:
But I'd like to make every variable needed by the user available.
Ok. So, here's what I need: Someone to use it and provide feedback. I'm getting too close to it and bleary of thought.
I've thought of doing a few things to get some feedback:
- Setup a challenge (I've got some surplus).
- Offer to mail one person a month a setup (two Bluetooth PCBs and a cheap webcam).
I think I'll make a walkthrough video pretty soon (kinda miss making stupid videos) but I'm a little worn out right now.