Charlie's Adventures with GoPiGo O/S Beta-1


Apparently I am contributing too heavily to the “normal” GoPiGo O/S Beta-1 threads - it only allows three replies in a row before requiring someone else to have a say.

Well then, I guess I have to author my own thread!


First comment:
Note that this may not be fixable in the ordinary sense, as it may require either a re-design of the entire Bloxter infrastructure, or potentially non-trivial changes to the way “argument” blocks work.

Note the following snippet:

Also note that the attempted construct is a print statement with multiple arguments. Apparently, this kind of cascading statement is not allowed in Bloxter.
Pitch (numerical value)
Roll (numerical value)
Yaw (numerical value)

This is a simple statement in any text-based programming environment. It would be nice if it could be implemented in a block-based environment too.


I’m always happy to keep a thread alive with a quick response! :joy: I’ll bring Charlie’s cascading statement and how to perform it in Bloxter to the team.

1 Like

Disclaimer: I know nothing about Bloxter

Perhaps there needs to be an “imu values” block like the “line_follower values” block?
There is an append text block but not a prepend text block - am I missing something?

(Screen shot from not Bloxter in GoPiGoOS)

Do loops need a count 1 sec and then block?

1 Like

Playing with bloxter, and having started and stopped the robot a few times before opening bloxter, I then tried to create some code.


The result of running this was the output window with “Log:” and nothing else.

Note that the exposed python code has nothing whatsoever to do with the code on the blocks.

I have seen this happen several times, but have not figured out how to repeatably provoke this error.

Switching modes from Bloxter to Advanced Bloxter and back does not always clear it up. Putting the code in the trash, and then switching, always clears it.

Additional note:
It does not seem to be possible to specify a line-end such as “\n” as the “” is automatically escaped.

1 Like

One other thing I’ve noticed. It may be by design, it may be an oversight.


  • Network mode = “access point” (Possibly connected, possibly not)
  • Ethernet cable is also connected
    Network communication between the 'bot and the outside world is very strange. Particularly when using a VNC connection. Occasionally it works in strange ways, mostly it doesn’t.

What I would expect as a reasonable behavior:

  • If network mode = “access point” and NOT connected using Ethernet
    • Then access to external network should NOT work.
  • If network mode = “access point”" and IS connected using Ethernet
    • Then access to external network SHOULD work.
    • This should be independent of the access point connection status.

This would allow for the case where an instructor wants to update or configure the robot in ways that require internet access, without having to globally change the settings on each individual robot in a class. You plug it in, and it works.

What say ye?

Note that I have finally characterized this behavior:

If the bloxter session is abandoned for whatever reason with code in place, when returning to the bloxter session the user is presented with:

  • An empty Bloxter workspace
  • The “Python” coding pane contains the text of the last program built. (I do not know if running the program is required.
    • Note that this behavior survives a restart and/or a refresh of the browser.
    • Also note that this behavior was tested using Firefox.

Also note that this behavior survives a full reboot or a cold restart of the robot.