(et. al - anyone else who has constructive suggestions)
I have some ideas for improvements to Raspbian for Robots that I would like to propose. In the spirit of open-source programming, and because I’m not the only person using it, I want to solicit comments and suggestions for improvements to Raspbian for Robots.
Note that these are primarily GoPiGo-centric as that is the 'bot I have. It is likely that some of this may be applicable to the other Pi-based 'bots that use Raspbian for Robots.
I propose to work on (at least some of) these as independent projects based on the feedback received.
Question: How do I submit software changes for inclusion in future versions/updates to Raspbian for Robots?
Please consider and comment on the following ideas
(a) Move target save directory to /home/pi.
(b) Add explanatory text to the wheel calibration settings.
(c) Realign the buttons and input boxes to improve appearance.
(d) Add a “Save” button that does not automatically exit.
(e) Modify movement button behavior:
i. Press-and-hold moves the 'bot only while the button is pressed.
ii. Double-click “locks” the button “down” and releases it.
iii. Button changes color when active.
(f) Add/modify control settings:
i. Add a “wheel bias” setting that would allow fine-tuning the wheels to adjust for any lateral motion while moving forward.
ii. Add a “servo bias” setting to compensate for lateral offset in each of the two servos.
iii. Add “servo left/right limit” settings to allow setting the maximum travel for each of the two servos.
iv. Note that all of these settings will be stored in a human-readable file, formatted in the same way as the existing configuration file. User, (and Dexter supplied), apps and programs are invited to make use of these configuration constants to ensure consistent robot behavior.
Raspbian for Robots’ Desktop:
(a) The current robot battery voltage should be in the system tray.
(b) The VNC desktop should be resizable to make the best and most efficient use of the display being used. This should be true even if the robot is being run in “headless” mode where the VNC desktop is the primary desktop.
i. Question: Is it possible for VNC to distinguish between mobile and desktop devices? If so, can the VNC desktop re-format to fit the mobile device’s screen geometry?
ii. Question: If VNC can distinguish between desktops and mobile devices, and re-format to fit, is it possible for VNC to read the native geometry of a desktop device and conform to it?
(c) I propose re-organizing the Dexter desktop to group related items into various folders so that items are easy to find. This will make the desktop less visually noisy and will provide an economy of space. This is especially important within smaller desktops.
Organization of Dexter supplied software:
(a) Unless there is a specifically critical reason, everything within the “pi” user folder should be owned, modifiable, and, (when appropriate), executable by “pi”. This includes any Dexter supplied software placed in the “pi” home directory.
(b) Any Dexter supplied software, (such as library files, update files, etc.), that should not be modifiable by the user, (except, perhaps, by a suitably experienced user for carefully considered reasons), should not be stored in the user’s home directory tree.
i. Suggestion: Perhaps these files should be in /usr/lib/Dexter, /var/lib/Dexter, or some other directory reserved for important library files?
(c) Certain folders that contain interesting software that the user can use to learn from, (i. e. the “Projects” folder, and others similar), should be elevated to the desktop with a symlink, and these files should absolutely be owned by “pi”.
Scratch for Robots:
(Parenthetical note: In it’s current state, Scratch for Robots is - essentially - useless as a teaching tool.)
(a) I have heard that Scratch-2 is being depreciated. Therefore future versions of Scratch for Robots should be based on Scratch-3 if possible.
(b) I propose extending Scratch for Robots to make it more educationally friendly.
i. The existing blocks and structures should be maintained to ensure backwards compatibility.
ii. The default sprite should be the “robot” and not the “cat” since we’re specifically intending this to be a robot-control programming environment.
iii. The specific robot-control blocks used in the DexterOS for it’s “blockly” programming environment should be either directly ported over to Scratch for Robots, or their functionality and structures should be substantially duplicated.
I would like to invite all interested parties to comment on any or all individual proposed modifications, or propose their own.