The wxPython module is required to run this program

[jimrh]

Ref:

Install ROS on GoPiGo

@cyclicalobsessive, Rerunning curl -kL dexterindustries.com/update_gopigo3 | bash created the GoPiGo3 sub directory in the Dexter directory. I suspect that if you have not installed R4R, then you have to run the curl -kL dexterindustries.com/update_gopigo3 | bash twice, once to create the Dexter directory and then again to install GoPiGo3 in its own sub directory. By the way, I still have the problem of not being able to copy and paste into the VNC Viewer Raspbian Desktop from Windows so I s…

My original install of Raspbian for Robots (12/29 - Buster) worked wonderfully until I tried installing that cursed Vellman touchscreen which made a total balls-up of everything.

I re-flashed and re-installed Buster from the same image. Doing this, I did the following:

1. Flashed a fresh copy of Buster on Charlie’s SD card.
2. Installed and did the initial configuration - things like IP addresses, hostname, WiFi credentials, etc. etc. etc.
3. Ran apt-get update and apt-get full-upgrade
4. Ran the Dexter updater.

Attempting to run the control panel returns a series of errors that boil down to the fact that the “wxPython module” appears to be missing.

Python 3.7.3 (/usr/bin/python3)
>>> %Run control_panel_gui_3.py
Traceback (most recent call last):
  File "/home/pi/Dexter/GoPiGo3/Software/Python/Examples/Control_Panel/control_panel_gui_3.py", line 14, in <module>
    import wx
ModuleNotFoundError: No module named 'wx'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/pi/Dexter/GoPiGo3/Software/Python/Examples/Control_Panel/control_panel_gui_3.py", line 16, in <module>
    raise ImportError("The wxPython module is required to run this program")
ImportError: The wxPython module is required to run this program
>>> 

This error is a “new” error for me. I noticed it after Charlie was befuddled after the Vellman touchscreen was installed - however this is a new install and the touchscreen has not been re-installed yet.

As I said in my post:

Charlie has an Identity Crisis! Vellman 3" display befuddles my GoPiGo

Did this. I’m going to make sure everything ELSE is working before I plug the screen in again. . . . And I am tempted to make an image backup of my SD card too!

I want to get things working again first.

Now I am getting this error on a clean install. What do I do to clean this up?

Thanks!

[jimrh]

Update!

I discovered that running the control panel from the desktop works. However, opening it in Thonny and trying to run it there, shows the error shown above.

The desktop “shortcut” executes the following:

python /home/pi/Dexter/GoPiGo3/Software/Python/Examples/Control_Panel/control_panel_gui_3.py

Running that directly from a terminal window also works and displays the control panel.

I then ran “python” in a terminal window, and got this:

pi@Charlie:~/Dexter $ python
Python 2.7.16 (default, Oct 10 2019, 22:02:15) 
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
pi@Charlie:~/Dexter $ 

Interesting! Thonny, by default, runs Python 3, as shown in the shell window:

Python 3.7.3 (/usr/bin/python3)
>>> 

So, I am assuming that the problem is that the control panel - for whatever reason - is still running in Python-2, even though it has been ferociously depreciated and isn’t even being included on recent distributions.

Is this correct? (i.e. These things running on Python 2 instead of Python 3?)

Shouldn’t we, (Dexter, it’s code, and the 'bots), migrate to Python 3? Especially if we’re going to be using this in a teaching environment?

I am assuming the “ultimate” resolution of this problem is to re-direct Thonny to the “correct” Python interpreter.

What say ye?

[cleoqc]

While the robot itself supports both Python2 and Python3, and we favour Python3 over Python2, all the GUI were written a few years ago, using libraries that do not exist with Python3. So this is a full rewrite that we’re talking about and is, unfortunately, low on the priority list.

Most users are either on DexterOS, or those who are on Raspbian for Robots don’t go in and play with the GUI code.

I fear this will stay this way for a while.

[jimrh]

I fear this will stay this way for a while.

Sigh. . . .
Yet another thing for my ever lengthening “things I’d like to do for the R4R / Dexter community” list.

Most users are either on DexterOS, or those who are on Raspbian for Robots don’t go in and play with the GUI code.

That’s the way I happen to learn the most quickly - take something and chew on it. This kind of “learning process” uncovers all kinds of (ahem!), “interesting” things that others might never see.

On a slightly different topic, I also took a peek at the “easygopigo3” and “gopigo3” library code - wow! My hat’s off to all of you - what a piece of work!!

Of course, the problem with reading things like that is all of the “Hmmm. . . I wonder what would happen if I tried this?” kind of thinking that happens. One relatively obvious, (to me), extension to the easygopygo3 class is a brightness setting for the LED’s. (Dex’s eyes are way too bright.)

Adafruit has a nice article on power management for NeoPixel based displays which is relevant for anything with LED’s on it.

Sipping Power With NeoPixels

and

LED Tricks: Gamma Correction

The gist of it is that if you reduce the brightness (duty-cycle) of a PWM driven display element by 50%, the apparent change in brightness is less than 10%. In other words, you can spend only half the needed power and still get over 90% of the light.

That’s also on my list. . . . .

[jimrh]

Found this:

What is wxPython Phoenix?

wxPython’s Project Phoenix is a new from-the-ground-up implementation of wxPython, created with the intent of making wxPython “better, stronger, faster than he was before.” In other words, this new implementation is focused on improving speed, maintainability and extensibility of wxPython, as well as removing most of the cruft that had accumulated over the long life of Classic wxPython.

The project has been in development off and on, mostly behind the scenes, for many years. For the past few years automated snapshot builds have been available for those adventurous enough to try it, and many people eventually started using the snapshots in their projects, even for production releases. While there are still some things on the periphery that need to be completed, the core of the new wxPython extension modules which wrap the wxWidgets code has been stable for a long time now.

Due to some things being cleaned up, reorganized, simplified and dehackified wxPython Phoenix is not completely backwards compatible with wxPython Classic. This is intended, on purpose, by design. In general, however, the API differences tend to be minor and some applications can use Phoenix with slight, or even with no modifications. In some other cases the correct way to do things was also available in Classic and it’s only the wrong way that has been removed from Phoenix. For more information there is a Migration Guide document available at: https://docs.wxpython.org/MigrationGuide.html.

The new wxPython API reference documentation , including all Python-specific additions and customizations, and also docs for the wx.lib package, is located at: https://docs.wxpython.org/.

This could be interesting. It supposedly supports Python 3.

[cleoqc]

If we were to put time in recoding those GUIs we would be using tkinter from now on.

[jimrh]

If we were to put time in recoding those GUIs we would be using tkinter from now on.
[text to prevent the system from deleting this]

That’s a thought.

I’ve just read some interesting stuff on tkinter, it would be interesting to see what I could do with it. Would you be interested in seeing, and perhaps messing with, code examples?

There’s a lot for me to learn, but this seems like a way for me to get my feet wet.

What say ye?

P.S. How do I prevent the system from deciding for me what I should, and should not, post?