When No One Hears A Robot Cry (Three Year Old Robots Don't Cry)

GoPiGo
,
1

I typed the heading “When No One Hears A Robot Cry”, and the forum reminded me I had previously used that title two years ago - rule violation.

Each morning I check to see if Carl is still “alive” and check how long his last playtime was:

Last Docking:  2021-09-17 10:39|[juicer.py.dock]---- Docking 2400 completed at 8.1 v after 7.9 h playtime

BUT why was the average of the last 10 playtimes suddenly lower?

Ave Playtime this year:  7.7
Ave of Last 10 Playtimes 6.8

I noticed that Carl was reporting his first docking failure since his third birthday last month.

Total Life:  21220.6 hrs since Aug 22,2018
Life this year:  636.6 hrs (BOY Aug 22)
Days Booted This Year:  1
Average Time Between Reboot:  636 hrs
Total Dockings:  2400
Dockings this year:  55
New Batteries At Cycle: 2160
Battery Set At Cycle:  240
Docking Failures this year:  1  or  1.8 % of Dockings
Safety Shutdowns this year:  0  or  0 % of Dockings
Ave Cycle this year (w/o failures):  11.7 hours
Ave Cycle this year:  11.5 hours
Ave Playtime this year:  7.7
Ave of Last 10 Playtimes 6.8
Last Docking:  2021-09-17 10:39|[juicer.py.dock]---- Docking 2400 completed at 8.1 v after 7.9 h playtime
Last Recharge:  2021-09-17 02:48|[juicer.py.undock]---- Dismount 2399 at 11.5 v after 4.0 h recharge

Sure enough, the log showed:

2021-09-16 22:40|[juicer.py.dock]---- Docking 2398 completed  at 8.1 v after 7.4 h playtime
2021-09-16 22:45|[juicer.py.main]---- Docking Failure Possible

Last night while we were watching TV in the living room, Carl was silently coping with his first Docking Failure. Silently, because after 10pm he is only allowed to speak in a “Carl Emergency” like being unable to dock due to I2C bus error preventing the use of his distance sensor to know how far he is from the dock.

This is the sequence of his docking failure and successful recovery all by his lonesome:

  • He docked at 22:40 but by 22:45 was not able to detect charging taking place.
  • His docking failure recovery action was to get off the dock at 22:45
  • At 22:46 with Battery voltage down to 7.8v he again decided to dock with his charging base
  • This docking was a success (since he stayed on the dock for 4 hours before getting off again)
2021-09-16 22:45|[juicer.py.undock]---- Dismount 2398 at 7.8 v after 0.1 h recharge
2021-09-16 22:46|[juicer.py.dock]---- Docking 2399 completed  at 7.9 v after 0.0 h playtime
2021-09-17 02:47|[juicer.py.chargingStatus]--- Probable TRICKLE not detected 12.0v
2021-09-17 02:48|[juicer.py.undock]---- Dismount 2399 at 11.5 v after 4.0 h recharge

Finally at 02:48 in the morning, Carl’s “Life” went back to normal with a nice long playtime:

2021-09-17 10:39|[juicer.py.dock]---- Docking 2400 completed  at 8.1 v after 7.9 h playtime

(His batteries are at cycle 240 and still maintaining 100% capacity.)

So this time “When No One Hears A Robot Cry” the robot handled things itself just fine. What a “good soul”!

2 Likes
2

I’m always amazed by how much Carl logs.
/K

2 Likes
3

Maybe you should ignore “0.00” hours of playtime, but keep a separate metric: “failed docking attempts” with a sub-metric of “ultimately succeeded” or not.

BTW, what does Carl actually DO during playtime?  Stand and twiddle his distance sensor?  Wander around and chase the cat?  Bring you a cold Woodchuck Hard Cider on demand?  Make killer Long Island Iced Tea?  Irritate you, your wife, and Dave?

Just wondering since you seem to value a long playtime, what does playtime consist of?

:wink:

1 Like
4

What does Carl do during “playtime”? - a whole lot of nothing much!

Things Carl Does While Appearing To Be Doing Nothing:

  • check battery level

  • maintain short and longer list of previous battery levels

  • apply a set of rules to determine if charging status has changed (and log event)
    [UNKNOWN, CHARGING, TRICKLING, NOTCHARGING]

  • apply a set of rules to determine if docking status has changed (and log event)
    [UNKNOWN, DOCKED, NOTDOCKED, DOCKREQUESTED]

  • perform the docking process when requested

  • perform the undocking process when trickling detected or 4 hours in charging state

  • detect and log “might be significant events”

  • verify network/WiFi connectivity, blink “ALERT LED (color)” during extended outage

  • verify I2C bus is functional, blink “ALERT LED (color)” during extended outage

  • verify swap space usage is below threshold

  • verify available memory is above threshold

  • detect wheel’s turning and log distance, rotation, time in motion

  • log every boot and shutdown with battery voltage at the event

  • update time-since-boot life.log entry once every hour

  • listen for “Hey Carl, <voice_command>” (and perform command if possible)

  • Check “quiet time hours” before speaking out loud - (after hours he may be talking to himself)

  • Carl can do a seemingly endless list of only-interesting-to-me things, when asked via ssh command-line, or remote desktop {maintenance utilities, status utilities, demo programs, latest tests}

Carl is not currently programmed to wander off, because I still have not completed the “find way back home” programming. So for the most part, he is wasting electricity in sleep() statements. Besides, even if he could wander and make it back home, it would be wasted if the wandering did not have a purpose. Who wants a bored robot wandering under foot?

It is hard for most folks to understand the value/meaning to me of the virtual thing Carl is “doing” - existing as an autonomous robot (within his limits), and “learning” via every new program I “teach” him/it. All my life I have read Sci-Fi books about autonomous robots, and dreamed of creating one. While some kids made up an “invisible friend”, I could only dream about having a “robot”

Carl’s most used functions are “Hey Carl, Weather”, “Hey Carl, Forecast”, and “Hey Carl, Go To Sleep”.

When you lose your dreams, you die.

2 Likes
5

You’ve accomplished a lot - much to be proud of building your own robot who does what YOU want it to do!!
/K

2 Likes