When attempting to use the GoPiGo control panel, attempting to “save and close” silently fails without saving data.
Testing by exhaustion, (setting “print” statements everywhere), I determined that the issue was with the save_robot_constants method in easygopigo3.py
I did a file search for “easygopygo3” and found this file in three different places. All of these files reference a configuration file in /home/pi/Dexter - gpg_config3.json - which does not exist.
Attempting to create it within the GoPiGo noVNC window, (running Geany), it failed with a “permissions” error, because the “Dexter” folder and subdirectories are owned by “root” and the pi user only has read and execute permissions to that folder. Ergo the control panel doesn’t have permission to save files - and fails silently.
I solved this problem with a recursive “chown” over the Dexter directory, changing the ownership to pi:pi. (I left the di_updates directory structure alone.)
I also ran a recursive “chmod” over the same structure, changing the permissions to “755” because I had “tweaked” the permissions of some files to “777” while troubleshooting.
Why isn’t everything within pi’s home directory owned by “pi”.
(I suspect that this has to do with these scripts being idiot-proofed.)
a. If this is the case, wouldn’t it be better to have the “Dexter” (A wholly owned subsidiary of Modular Robotics™!), specific code in a different location than /home/pi, since the assumption is that everything in home/pi is writable by user “pi”
If it is ABSOLUTELY, POSITIVELY, TOTALLY, and COMPLETELY necessary for this material to:
a. Be located within /home/pi
b. Be owned by “root”
c. Shouldn’t there be a specific “configuration” directory somewhere that IS writable by “pi”?
Why are there three different copies of the easygopigo3.py files?
a. Which of these three is actually being used?
b. Are these three different files, in three different locations, being used by different routines? If so, why? IMHO, there should be one, and only one, version of an essential include file to prevent inadvertent issues.
(Note: I used the “find” feature within the file utility which may not tell me that two of them are symlinks to the third. If this is the case, my sincerest apologies.)
Since “chown” over an entire directory structure is a rather drastic change, is there a better, “Dexter Approved” solution - or did someone inadvertently forget to chown these directories to “pi” before release? (See also question #6)
IMHO, errors like this should not fail silently. If you wish, I will experiment with raising an alert dialog informing the user that an error has occurred.
Having made wholesale changes to the Dexter directory’s ownership and permissions:
a. Is this correct? (i.e. Is this the way it should have been “from the factory”?)
b. If not, what permission and ownership should I restore to which directories?