Raspbian for Robots - Request for Comments

GoPiGo
1

Greetings!

@cleoqc
@cyclicalobsessive
@RobertLucian

(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

  1. Control Panel:
    (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.

  2. 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.

  3. 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”.

  4. 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.

Jim “JR”

2

Comments:

  1. Go For It! (Learn Git, create an Issue, solve the issue, create a pull request)
  2. My guess is these are useful ideas, but it is just overwhelming to me.
  3. I still have not upgraded to the latest Buster based Raspbian For Robots, so cannot comment further.
1 Like
3
  1. Doing that.

I created a text-based “craps” game as one of my first Python programs. While I was doing this, I created a Git repo for my game. Good thing too, because as I was working on it, adding the various design features I had planned for it, I ended up refactoring it several times to reduce code-bloat and make it easier to maintain.

I started out with a bare-bones wire-frame design with minimal functionality and added one feature at a time once the previous feature(s) were playing nice together. IMHO, (and based on my SQA experience), it makes debugging much easier if you plan the entire project ahead of time - on paper - and then implement small chunks at a time.

I found myself re-designing the paper specification repeatedly as I discovered that certain assumptions I made didn’t work - or didn’t exist in Python.

Having the project within Visual Code Studio, (It’s a Windows-based executable), and up on GitHub, allowed me to totally screw the pooch and recover work that would have been “lost and gone forever, oh my darling Clementine!”

  1. And a lot of the code you write is overwhelming to ME!! Maybe we can collaborate?

  2. This should all be applicable to Stretch too.

4

The first, (and only!), time I’ve played with “git” - was using Visual Studio Code on my Windows laptop and a GitHub account I created. Visual Studio Code allows you to clone GitHub repositories, make changes, commit the changes, etc. etc. etc.

In my case here, the existing code is already on the 'bot, and is run there. As a consequence of this, I’m doing my 'bot development directly on Charlie - using a VNC window because I don’t have a micro-HDMI adapter. . . . yet!

Questions:

  1. How do you do your development for Carl? Directly on the 'bot itself? Or do you have access to some kind of GoPiGo simulation?

  2. What development tools do you use?
    In my case I would prefer a “windowed” based editor rather than raw EMACS or vi. Thonny is OK but lacks the chops of Visual Studio code. (This sounds like a job for a good search engine!)

  3. How do you handle Git integration? Manually via the command line? Via your development environment?

You’re right about one thing. If I’m going to be running with the Big Dogs, (or at least medium sized dogs), I need to “Git” With The Program and use adequate version control software.

5

I’m short on time but I can answer this one very quickly. On each update, the Dexter folder actually gets deleted and re-created. If it is user writable (like it used to be, btw) then users tend to save their work in that folder instead of copying code out of it and put it elsewhere. This lead to a lot of lost work.
We really want to discourage people from editing the files under ~/Dexter.

2 Likes
6

Then, maybe it should be somewhere else and not in /home/pi?

By convention, people assume that anything within their home folder is fair game. If you’re using it for static objects that should NOT be modified by the user, than the user’s home directory is the WRONG place for it.

7

If we move it out, then beginners do not find it. Conundrum…

2 Likes
8

Perhaps it’s time to split the Dexter directory? Essential functionality would move somewhere else - like the updater, libraries, etc.

More user-centric functionality could remain in the home directory and not get updated.

9

see My Dev Process for GoPiGo3 Carl

1 Like