The distance to the dock was 24mm ( less than one inch) too much, probably because I bumped him with my chair when I headed off to sleep for the night four hours earlier.
Carl’s programmed strategy for this situation is to shout “MANUAL DOCKING REQUESTED!”
Carl’s programming prevents him from speaking (or shouting) during quiet hours (11pm to 10am)
So Carl sat staring mournfully at his dock for ten more minutes, then quietly put himself into a deep sleep.
Charging Status: Not Charging
Docking Status: Manual Dock Requested
Last Docking Change: 8h 25m 30s
******** WARNING: 7.4v Safety Shutdown Is Imminent ******
QuietTime speak request: Safety Shutdown Is Imminent. at vol: 125
******** WARNING: 7.4v Safety Shutdown Is Imminent ******
QuietTime speak request: Safety Shutdown Is Imminent. at vol: 125
******** WARNING: 7.4v Safety Shutdown Is Imminent ******
QuietTime speak request: Safety Shutdown Is Imminent. at vol: 125
******** WARNING: 7.4v Safety Shutdown Is Imminent ******
QuietTime speak request: Safety Shutdown Is Imminent. at vol: 125
SHORT MIN BATTERY VOLTAGE: 7.24
SHORT MEAN BATTERY VOLTAGE: 7.39
QuietTime speak request: WARNING, WARNING, SHUTTING DOWN NOW at vol: 250
BATTERY 7.32 volts BATTERY LOW - SHUTTING DOWN NOW
Shutdown at 2020-11-29 04:44:45
Sort of and sort of not - let me explain the reality of Carl’s “playtime”.
I have not programmed the most important step that would unleash Carl for random playtime:
Get off Dock - Programmed
Get on Dock from designated “Docking Spot exactly in front of the dock” - Programmed
Find Dock from middle of the room and line up roughly at an “approach distance” - Programmed
Ask for help if anything seems wrong - Programmed
Line up EXACTLY at the “Docking Spot in front of the dock” - NOT PROGRAMMED
This last task requires using the camera and OpenCV to figure out how to drive to be lined up perpendicular to the dock aligned with the center of the dock.
I supposedly have the OpenCV knowledge, but have not tackled applying that knowledge to become a reality.
So Carl’s reality right now is "When you get off the dock, don’t wander away from that exact spot or you will not know how to get back on the dock"
. . . .then how do vacuum robots do this with such seeming ease? They don’'t have rotary spinning cameras, (or even static cameras for that matter), being equipped with a basic optical sensor for alignment. (OK, maybe the new super-duper fancy modules have the fancy camera, but there are generations of robotic vacuums that don’t.)
Perhaps you are making this more difficult than it needs to be?
It seems that the easiest way is to take something stiff, like a piece of marlite wall-board, (like they use on the back of cabinets or the floor of drawers nowadays, or a sheet of stiff plastic maybe a mm or so thick and make a guide slot for Carl?
Maybe something like this?
Or something similar so that the EXACT alignment of Carl in front, prior to docking, is not so critical anymore. A piece of inexpensive plexiglass and a jigsaw should be more than adequate. 1/8’ or 1/16 wood (like plywood or cabinet back marlite), would work too.
It might need to be a little longer front-to-back, but the idea is that it would protect Carl from the accidental jiggle, (he could just “go backwards” to re-seat himself), and if he gets “close enough” to the “exact spot” he can dock by himself without needing nuclear precision.
Or, simplest of all: In the case of critical issues, allow him to speak during quiet hours?
The slot needs to be deeper to guide the roller better, and the wheels have to be able to transition onto the guide so it gets a little tricky. Back up too quickly and the roller won’t stay in the slot. Back up too slow and the wheels are not going to climb the edge of the guide.
I have some foam board; I can try various shapes and guide lengths before tackling a sheet of acrylic with my hand jigsaw. (I’m just not good with tools, period.)
A software solution has more appeal but I just haven’t had the will to dig into it. Perhaps trying again with the hardware assist will work well enough.
The question of whether to use a hardware solution or a software solution is always a trade-off.
With respect to this particular problem, (IMHO), a “software” solution would be both time-consuming and potentially expensive. An optical system invites the question of “what happens if the light through the window is just so?” Or, “What if a future replacement lamp in that room has a different color-temperature?”
A “hardware” solution for a problem like this is immune to all these issues, but presents issues of its own - like “What is the ideal spacing with respect to both the roller and Carl’s wheels.” or “Is it long enough? Too long?”
Since you have foam-board, have you considered cutting a (relatively) small piece, (a few inches front to back), that fits around the front of Carl’s dock, mashed down toward the front to make a ramp that is easier to climb than the relatively high lip that is at the front of the charger now? With a bit of a ramp-up, maybe the rest isn’t so difficult?
Thinking about it, I would try a ramp to overcome the lip at the front of his dock before I’d re-manufacture the guide.
Maybe it’s me, but this doesn’t sound nearly as difficult as some of the really gnarly problems you’ve faced in the past.
Do you remember an old television show called “Dobie Gillis” (1959-63). There was a rather simple character “Maynard G. Krebs” that would yell “Work?” and exit the scene quickly at the mere suggestion. (Dobie’s lazy and somewhat goofy best friend. Maynard was a would-be beatnik who shunned romance, authority figures, and work.) Maynard G. Krebs knew that once you get started on something, the work will never end.
So I built an extended docking guide from foam board. Modified juicer for the longer backing distance and told juicer to perform five test dockings.
Major success. Carl backed over the lip just fine, and seemed to have a much larger error acceptance.
So then I placed Carl in the center of the room, and told him to “find your way home.”
He did a 360, threw up his arms, and told me he was taking the rest of the day off.
(findDock.py uses OpenCV to
recognize the two green LEDs of appropriate color, size, distance from each other, and distance from the floor,
then drive toward the found dock
use distance sensor and panning to measure his angle to the wall
calculate the angle to turn to be parallel to the wall and make the turn
calculate the distance to travel to end up aligned with the center of the dock and move there
turn to face the dock
)
When I last left the program months ago, it appeared to be working quite well. Some sort of bit-rot must have occurred.
Now I remember why I didn’t finish the docking code - “Work? See Ya!”
Or, a dependency or some corollary code was modified somehow somewhere else that broke this code.
I don’t think you should throw in the towel so quickly, (IMHO).
Example on point: My “Remote Camera Robot” project.
I’ve noticed a particular cycle of programming effort with that project:
I get all fired up wanting to do something.
I go try and implement it.
I discover that even simple things have more aspects than a cat has hair and implementing even trivial changes is a Herculean task.
The classes, methods and programming models are difficult to conceptualize and, as a consequence, difficult to build concise and understandable mental models of their behavior.
Little, if anything, works as expected and frustration reigns supreme.
I end up with a blinding headache along with “. . .such a desire to knock heads together!” (John Adams, 1776)
The result is that I abandon the project for a while, and - ultimately - become frustrated that I’m not accomplishing what I want.
Reading The Art of Unix Programming by Eric Steven has been instructive.
Apparently what I need to do is step back, look at what I’ve done, and - very possibly - refactor the entire code tree, simplifying it into something that doesn’t make so many assumptions about what the input device is.
Likewise, in Carl’s case, perhaps instead of trying to teach him new skills, it’s time to step back, examine the existing code and try to simplify and refactor it into smaller, less complex modules that have less a tendency to interact and break each other?
