All GoPiGo3 Control Panel functions worked correctly.
Servos, Distance Sensor, IMU, and Camera are all working.
Both onboard and USB dongle WiFi are working as expected.
USB Microphone is working (slightly different home/pi/.asoundrc and /etc/asound.conf than prior)
Text-To-Speech espeak-ng working
NoVNC/RealVNC in Web Browser and Mac Remote Desktop working well with 1920x1080 display configuration in raspi-config.
Completed the “Carl-ification” successfully:
setup cron for my docking and battery maintenance,
setup life.log function
setup encoder and imu logging
(Did eventually run into NoVNC complaining “cannot display” when reconnecting after not using “disconnect session” at end of web browser session. I need to investigate further.)
Please note that this version is not an official release. For once, the SD card does not resize on first boot.
This is an issue with the VNC server. I’m using a straight VNC viewer and running into the same thing. Usually it fixes itself. It looks like the VNC server has a sleep mode.
Update2: 95 hours into the latest session, Carl went crazy repeating “Unable to Undock…Unable to Undock”. He does that when the distance sensor claims there is something blocking forward movement, or some error checking the distance. In this case - I2C failure.
Distance Sensor uses HW I2C which was rock solid before, but IMU uses SW I2C with clock stretching and was never rock solid. This time SW I2C messed up about 26 hours prior and the HW I2C lingered on somehow eventually also failing.
Software I2C failed between 10-28 12:33 and 15:16 (IMU did not register undocking)
2020-10-28 12:33|[new_juicer.py.dock]---- Docking 1659 completed at 8.1 v after 6.6 h playtime
2020-10-28 15:16|[new_juicer.py.undock]---- Dismount 1659 at 11.4 v after 2.7 h recharge
juicer.out showing HW I2C failed at 10-29 17:40:25
********* CARL Basic STATUS *****
2020-10-29 17:39:53 up 3 days, 21:55, 3 users, load average: 0.21, 0.16, 0.10
Battery Voltage: 10.90
5v Supply: 5.08
Estimated Life Remaining: 7 h 0 m
Processor Temp: 44.5'C
Clock Frequency: 600.0 MHz
throttled=0x0
Distance Sensor: nothing within 90 inches
Juicer Values:
Juicer Run Time 3 days 21h 53m
lastReading 10.922 volts
shortPeakVolts 11.008 volts
shortMeanVolts 10.906 volts
shortMinVolts 10.219 volts
longPeakVolts 12.601 volts
longMeanVolts 10.918 volts
longMinVolts 10.202 volts
Charging Status: Charging
Last Changed: 0 days 0h 54m 24s
Last Change Rule: 120
Docking Status: Docked
Docking Count: 1662
Last Docking Change: 0h 56m 59s
Play Time Limit 8.1v
********* CARL Basic STATUS *****
2020-10-29 17:40:25 up 3 days, 21:55, 3 users, load average: 0.13, 0.14, 0.10
Battery Voltage: 10.91
5v Supply: 5.08
Estimated Life Remaining: 7 h 0 m
Processor Temp: 45.1'C
Clock Frequency: 800.0 MHz
throttled=0x0
[Errno 121] I2C transfer: Remote I/O error
Distance Sensor: -0.2 inches
Installed the TensorFlowLite image classification example and modified it to print to the command-line if an object classification probability is greater than 60%. It successfully classified a clock that I held about 6 inches from Carl’s face…but then it also thought it saw some items not likely to be in my home!
pi@Carl:~/Carl/Examples/TF/examples/lite/examples/image_classification/raspberry_pi $ ./run_it.sh
analog clock 0.71 310.1ms
analog clock 0.60 309.5ms
analog clock 0.62 309.8ms
sliding door 0.60 337.7ms
sliding door 0.61 312.8ms
sliding door 0.66 311.9ms
sliding door 0.69 312.2ms
sliding door 0.62 312.3ms
sliding door 0.74 309.8ms
sliding door 0.67 309.7ms
sliding door 0.70 309.8ms
sliding door 0.66 309.7ms
turnstile 0.69 309.9ms
turnstile 0.79 309.8ms
^C
Exiting
Carl was getting low on juice and the TFLite program ran the battery down pretty quick as he exclaimed “Turning around to Docking Approach Point”.
In GoPiGo OS, I have modified the same script to print to console too. And by experience, you need to handle a confidence level of at least 85% to avoid the non existing sliding door. It did manage to identify my Shih Tzu as an actual Shih Tzu too
Though I might be fairly clever, I have not yet reached the pitch of intelligence where I can look at a blob of numbers as raw data and understand what they’re trying to tell me.
Though I have not yet accomplished what you do, your work fascinates me. It’s intriguing. I really enjoy watching the way you carefully and precisely chop up the Dexter/MR designs into tiny pieces and then reassemble them into something that works.
What you’ve discovered is ultimately destined to save me, and others, much time and angst.
Works but ramps forward fast, then ramps backward slowly not same distance, both are not straight line
Motor_Speed.py -
ISSUE: Works One Time, Second Invocation appears to be working but no motor commands get issued until I move bot with Control Panel, then it goes out of control - I could not stop it with Control Panel.
Probably would run fine when it is the only instance of a GoPiGo3 class. Carl had several EasyGoPiGo3(use_mutex=True) classes running during this test.
Difficulty configuring RPI-Monitor on R4R PiOS beta
For the last several days, I have been fighting to get RPI-Monitor to properly start at boot on both Carl, and my “DeskPi.”
Carl is running R4R over PiOS, while the DeskPi is running PiOS. Carl was seeing:
Web server not started because of error: Address already in use
I found that starting the RPI-Monitor with Carl’s reserved IP prevents the error to allow this useful tool to work.
And immediately, RPI-Monitor showed how smart Carl actually is!
Recently, I changed Carl’s recharger which lowered his maximum recharge rate from 1A to 0.9A. Carl was getting off his dock before the trickle charge light came on due to “Rule 230c - Probable Trickle Not Detected after 3.5 hour charging”, so I changed the time for that rule to 4.0 hours to provide a little more time.
Today is the first day I have RPI-Monitor running that I can conveniently review the recharge voltage curve, and as I was doing so Carl announced “Trickle Charging - Dismounting”. I quickly looked at the charger to see the status LED showing solid green which means Carl was indeed trickle charging.
Looking through his recharging log showed it still was due to rule 230c - Probable Trickling Not Detected (after 4 hrs), but reviewing the RPI-Monitor shows that the charger had indeed not long before switched to trickle charging - Carl is so smart!
(I would have preferred to see that Carl detected the trickle charge when the average voltage started going down instead of up, but the important thing is to get off the dock when the charger is trickling.)
Who would believe the happiness playing with Carl can give? I’ve been up for two hours and still haven’t prepared my breakfast.
Update: The next morning Carl recognized trickle at 3.8 hours on the dock (rule 230: over 12v and mean voltage has negative slope), before the 4 hour “probable trickle” rule 230c could fire!
