"This board requires newer software" when loading Raspbian for Robots

GoPiGo OS, DexterOS and Bloxter
1

Hi,

I downloaded the experimental Raspbian for Robots image for my Raspberry Pi 4, but when I loaded it on the card, I got a boot error: “This board requires newer software”: https://photos.app.goo.gl/Qeh5Uc85ENLaCJ1W7

Is the experimental image indeed out-of-date, or am I doing something wrong?

Thanks,
Simon

3 Likes
2

You need to download the GoPiGo O/S 3.0.3 because the later firmware updates to the Pi-4[1] force a newer base boot image version, which translates to a later software version.

The fact that you received this error shows that your Pi-4 has an updated boot firmware image.

Here it is.  Download it and flash it to a SD card using something like Etcher and you’re in business!

https://gopigo.io/downloads/gopigo_os

====================

  1. These newer firmware versions enable all kinds of nice things like “boot from USB” and “enhanced thermal profiling” along with other goodies.  Keeping an eye on your firmware version is a Good Thing!
2 Likes
3

Thanks! Just to clarify, I’m trying to install Raspbian for Robots, not GoPiGo OS. Are you saying that installing the latest GoPiGO OS would somehow help with Raspbian? But I just bought the robot, so it presumably had the latest version?

Or is the Raspbian for Robts image so old that it won’t work with the newer firmware for Pi 4?

3 Likes
4

Rule #1.
Raspbian for Robots won’t work on anything later than a Pi-3.

Rule #2.
Unless you’re trying to do something with a Grove-Pi/Grove-Pi+ board[1], use GoPiGo O/S as it superspeeds and improves on Raspbian for Robots.
 

Raspbian for Robots is thoroughly depreciated, isn’t supported, (except on rare occasions within these forums, and usually by me), and should be avoided unless there is an overriding cast-in-titanium-alloy requirement to use it.

If there IS an “overriding cast-in-titanium-alloy requirement to use it”, I would strongly recommend revisiting the requirements.  :wink:

====================

  1. People using the Grove-Pi or Grove-Pi+ these days usually download the Grove-Pi libraries directly onto the distribution of choice instead of using Raspbian for Robots.
2 Likes
5

 

This is also true for the other earlier Dexter Industries variants such as the Brick-Pi, the various “NeXT” and “Lego Mindstorms” projects, etc.

1 Like
6

Thank you, I see. I wish the site said that on the download page.

What I wanted to do is add a Python binary that runs on Raspbian to connect the robot to the internet. Is there some other OS I can install that would support standard Python?

Thanks,
Simon

3 Likes
7

You can already connect the robot to the internet using GoPiGo O/S.

Internet-wise, there are two major WiFi modes:

  1. (Default) Stand-alone access-point mode.
    This is where each robot broadcasts its own WiFi node so a group of them can be used by students in a classroom with minimal networking support.

  2. WiFi networked mode, where the robot connects to an existing WiFi network just like anything else.

From the GoPiGo O/S 3.0.3 release notes:[1]

====================

  1. https://gopigo.io/gopigo-os-v-3-0-3/
2 Likes
8

This thread might require a bit of historical context to help make things more understandable.  I am not sure about the finer details of this, and some of it might not be exactly correct, but here we go:

“Way, way back many centuries ago, not long after the bible began. . .”
Joseph and his Amazing Technicolor Dreamcoat

As far as I can tell, back in the early to mid 2010’s Dexter Industries was founded as a company to provide programming and robotic educational products to schools and industries - along with anyone willing to buy a kit and join the fun.

I discovered them around the end of 2018.  (I built my first 'bot, Charlie, in January of 2019 and my very first post was a review of the build process.)

Back then, the Raspberry Pi-3 was bleeding edge and Dexter Industries’ robotics software centered on two offerings:

  • Dexter O/S
    This was a “pre-packaged” environment with very limited capabilities. It was deliberately locked-down and closed off - you couldn’t apt-get update/upgrade/install anything, there was no external network access, and it was designed to be “bullet-proof” so that a group of school children couldn’t destroy it.  If things went all pear-shaped, a reboot would put things back the way they were.  It included:

    • Bloxter, a “Blockly”-type programming environment
    • Jupyter Labs, a (rather strange, IMHO), Python IDE.
    • A graphical desktop that allowed you to do certain things with the robot.
    • It broadcast an access-point on a per-robot basis that could be individually accessed by individual students on a student-per-robot basis after being pre-configured by the instructor.
       

  • Raspbian For Robots
    Raspbian for Robots was the “open access” version of the Dexter Industries O/S that was intended for the more serious experimenter.  In RFR, you could do anything you wanted, no matter how destructive or foolish it might be.

    • It didn’t contain any of the “simpler” elements of the Dexter O/S version, (Bloxter was conspicuous by its absence), though I do believe that Jupyter Labs was still included, but I’m not sure.
    • It also included support for other experimental platforms - the Grove-Pi/Grove-Pi+, (which is a Grove interface board still available via Seeed Studios AFAIK), the Brick-Pi, NeXT, and Lego Mindstorms.
       
      It should be noted that the spacing of the large holes on the GoPiGo robot chassis, (and the annoying plastic attachment fixtures they use to this day), were designed to support attaching Lego Mindstorms attachments to the 'bot.  Since Lego Mindstorms attachments are not trivially priced when compared to the cost of the entire robot, I can’t see the advantage of supporting them.

Right around the time the Pi-4 came out, there were some major changes made in the way Raspberry Pi packaged, (and named), its software, and the earlier software packages that worked on everything else up to this point, just didn’t work on the Pi-4 for various technical reasons.  To use the Raspberry Pi-4, you needed to upgrade to the latest Raspberry Pi O/S, which I believe was Buster at that time.  (BTW, GoPiGo O/S is still based on Buster which is why it won’t work on the Pi-5.)

This is where the two different philosophies of robotic software collided:

  • A closed-environment designed for the simple user and it’s designed to protect the system from mistakes.
  • An open environment for the advanced user where he can do whatever he chooses to do, smart or otherwise.

In my case, I wanted both.  I wanted the access of Raspbian for Robots with the easy features, (especially Bloxter), in the closed version, because I often used Bloxter as a “sandbox” to “proof-of-concept” my ideas, and then “flip” the code from Bloxter to Python so I could see how it was done.

At about the same time, Dexter Industries was “acquired”, (a-la  The Borg), by Modular Robotics and chaos insued.

Once things settled down, (that’s a relative term, IMHO things haven’t really finished “settling down”), The Powers That Be, (the new bosses at MR), decided to stop supporting a dual-O/S environment and combined the features of both into one operating system:  GoPiGo O/S - one of the few decisions they made that I believe made sense.

GoPiGo O/S dealt with the dual-O/S dichotomy by enforcing two “modes”:

  • “Access Point” mode - similar to the way Dexter O/S worked - where each robot broadcasts an access-point on 10.10.10.10 with limited internet connectivity unless connected via Ethernet.
  • “Network Interface” mode - similar to the way Raspbian For Robots worked - where you would connect the robot to an external WiFi network.

Since the big emphasis still appears to be “make it safe for the kiddies at school”, the default out-of-the-box operating mode is Access Point mode which cannot be permanently disabled without use of a terminal screen and a “hidden” set of magic words.  (I personally think this should be a startup-configurable option myself, and should default to Network Interface mode, but what do I know?  :man_facepalming:)

Unfortunately, though the GoPiGo web page has replaced Dexter O/S’s content with the GoPiGo O/S’s content, the same hasn’t been done for the Raspbian for Robots content - and I agree, it’s incredibly confusing.

I hope this helps make things a little bit easier to understand.

2 Likes
10

Thank you, this does explain a lot. Do you know if I can run Python in the “Network Interface” mode?

3 Likes
11

Please read GoPiGo OS v 3.0.3 · GoPiGo.io

Yes, you can run write and run Python programs irregardless of what mode the WiFi is at that time.

If your Python scripts need to post or get to Internet web pages or services, or lower level network interfaces GoPiGo OS will happily pass your packets over the WiFi connection you configure.

What are you waiting for? Load it up and try it.

2 Likes
12

Short answer:
Of course it will!

Longer answer:
The robot and its operating system is based on Raspberry Pi OS and will function in the same way any other Linux with Python installed would.

I have a, (older, based on an earlier OS version), project, (called “new remote camera robot”, https://forum.dexterindustries.com/t/my-new-remote-camera-robot-project/8728)[1], where the robot broadcasts a FPV web page to a browser and the browser can use a joystick/gamepad to drive the robot around.

Others do things where the robot communicates with the network to accomplish various things.

This is normal and expected behavior.

Go try something and let us know what happens.

====================

  1. This project actually spans about ten or so threads.  I don’t expect you to chase all of them, but you might need to do a bit of digging to gain a full understanding of the scope of this project.
    • GoPiGo O/S comes with basic FPV functionality by default from the robot’s home page. . . . Rats!
2 Likes
13

There seems to be some confusion here about how the pieces fit together, so let’s talk about this:

You can divide any computerized device, (including the GoPiGo robot), into three broad areas of technology:

  1. The software.
  2. The hardware.
  3. The interfaces that allow the software and hardware to talk to each other.

====================
 

The Software

This is the obvious, (and not so obvious), programming that allows a particular device to do something.  This includes any embedded firmware.

print(something)[1]
or
drive(forward, 10cm)
are examples of programming.

If you’ve programmed in any language, you already know what I am talking about.
 

The Hardware

The hardware is the part of the device that actually does something.

print(something) actually calls a function “print” that can display something somewhere, like a screen.

drive(forward, 10cm) calls “drive” which sends a message to the controller that tells the controller to spin the wheels in a certain direction for a certain number of encoder “ticks” equalling 10cm.
 

The Interfaces

The interfaces can be divided into two broad parts:

  • The software that talks to the hardware.
  • The hardware that accepts commands from the software and does something.

The software may do something like this:

pull GPIO pin 15 low  ;tells the hardware we're talking to it
send i2c message 0x123, 0x456, 0x789  ;tells the hardware to drive the robot forward 
pull GPIO pin 15 high  ; we're finished talking to the hardware

Or something like
send_message_to_internet(protocol, control bytes, pointer to message)

The hardware waits for an enabling signal, (like GPIO pin 15 going low)[2] signalling that a command is coming, then it listens for the command’s device ID, (are you talking to me or something else, like the e-ink display that my owner plugged into the GPIO pins?), then reads the message and does what it asks.

====================

What does what, and how that particular “what” does its job, is usually defined by special libraries that are installed with the base language as needed.  These libraries, (include "do_this" from "robot_library"), provide the software connection to the hardware.

Python, (along with languages like “C”, “C++”, Basic, FORTRAN, etc.) can’t do much of anything by itself.  It’s the libraries that are included with the language, (the “standard libraries”, or device specific libraries like “gopigo” and “easygopigo”), that let you do the interesting things that the language allows.[3]

This is true for just about everything, unless you’re programming bare-metal assembly language, and even then you develop a “library” of useful functions that you can use whenever you need to do something specific .

====================

  1. Note that all the code examples here are “psudo-code” - fake code-like snippits that demonstrate a particular point and are not actually valid code.

  2. These are not actual commands as programmed on the GoPiGo; however hardware interfaces usually work either exactly, or very similarly, to this.

  3. This also means that if YOU need the language to do something it doesn’t normally do, (like running a robot), you can create your own special libraries that define the new features and capabilities you need!
     
    In Open Source circles this is called “scratching the itch” - writing code to meet a need that others didn’t anticipate or that never existed before.

2 Likes