Jim, the issue is not the OS, it is that the version of the python2 and the python3 site-packages do not have the new GoPiGo3 serial number check and the encoder tick handling in the gpg3_config.json file.
I do not understand why performing the desktop Software Update did not update the site-packages, but my feeling is to keep the OS constant and only investigate the DI software.
(Performing the OS update at one point broke my sound output and text to speech, so I am very cautious with that.)
I appreciate everyone’s help. I figured it out. I was using Thonny to test and run the scripts. That always worked fine until the new GoPiGo’s. I put the json config file back, ran the scripts from the terminal, both of my robot buddies are now happily roaming around!
Thanks again!
Yeah! Great news. Hope to hear more about what your robots are up to after they “get out of quarantine”
I am a Computer Science instructor at Western Nebraska Community College in Scottsbluff, NE.
These are being used primarily for 4 students working on a NASA student fellowship this academic year. (and of course for my entertainment.) We are working toward streaming video, humidity, temp, barometer, air quality, etc sensors, GPS, etc. I bought a bunch of Dexter and Grove Sensors to work with. We built up our GoPiGo fleet over a couple of years, which is why we have some different models. We bought two of the new GoPiGo’s this year.
I do have to occasionally take time off from playing with my robot friends and do some teaching.
I will be very curious to hear how it goes with your I2C sensors. I have banged the bus hard with multiple I2C sensors and found soft failures (catch with try/except) must be tolerated, and occasionally hard failures that require full power down cold boots to clear (around 1-5 Million transfers, if detect sustained “Err no 5” will need to SMS someone to cycle the power!) Dexter/ModRobotics has not seen the hard failure errors - only I have.
BTW, If any of the sensors require clock-stretching I2C they must be connected to the AD1 or AD2 ports, not directly to the I2C sockets.
Also, you may want to have folks search this forum for tips on the Grove sensors that do not have exact match Dexter examples. I remember some DHT sensor questions and GPS sensor questions, but not the specifics.
Interesting!
AFAIK, Thonny defaults, out of the box, to Python 2 whereas Geaney defaults to Python 3.
Part of the issue might be the age of the operating system in use - if you copied directly over from the old systems, that might be a problem.
As a general rule, I recommend using the Latest-and-Greatest OS; Raspbian for Robots buster for advanced use and GoPiGo OS for less advanced students.
Here’s a thread I started. It’s both long and gnarly, but there’s a lot of effort and research there if you are interested.
Good luck with your students and your 'bots!
Don’t forget to post about what’s happening!
The Raspbian for robots Buster is listed as being experimental](Download Dexter Raspbian for Robots from SourceForge.net).
Is this what you are suggesting I use and what you are using?
Yes, that is the one.
Stretch can only be used on pre Pi-4 systems.
Install Buster, try it, and then clone the SD card.
Then do a DEXTER update, see what happens, and then clone the card again.
Then, (after you’ve cloned the card again), do an apt-get update and apt-get upgrade, (as root), try it again and see what happens.
At that point, you should have enough information to decide what operating system you wish to use.
@loringw That “experimental” is possibly the best starting point for a Raspbian For Robots based GoPiGo3.
The latest, most supported OS from ModRobotics is their GoPiGo3 OS 3.0.1 which is fully Python3-ified. It offers a lot of ways to get to know your bot all the way up to using TensorFlow-Lite for face recognition, and with programming either via Blockster, or Python in the JupyterLabs software development IDE. There are supported/current tutorials - where the Raspbian For Robots tutorials have not seemed to have continued growth by ModRobotics.
The extensive Grove sensor example code was written in the Raspbian For Robots “heyday” two years prior. I am pretty sure they work from the command-line in GoPiGo3 OS, but that is also a good question for Mitch as GoPiGo3 OS seems to be more oriented toward graphical development environments.
I have a three year old robot Carl which is running Raspbian For Robots, which I have needed to be oh-so-careful about updates because something always seems to break.
For the last three months, I have been developing robot Dave which is running ROS2 over 64-bit Ubuntu Server. This was definitely not an easy path, but the only way to use the GoPiGo3 to learn ROS2.
Before you get too far down any path, I suggest you pop the question off to @mitch.kremm at support@modrobotics.com, explaining your students’ levels and what you want them to accomplish. I am guessing they would like to help you to use GoPiGo3 OS if it will meet all your requirements.
True, every bit of it.
However you do NOT have to use Jupyter Labs. In fact, Jupyter makes me crazy since it seems to be “Power-Point for programming” - i.e. if you want to demo a piece of code with line-by-line commentary as an educational aid, you can’t beat it.
However, for any kind of (so called) “serious” programming, use something else, and push everything to GitHub.
Geany, Thonny, etc., are all good.
I use Visual Studio Code on my laptop and execute directly on my 'bot, though I may reconsider that in the future.
I’m not nearly the programming guru that @cyclicalobsessive is, and I really like the new GoPiGo OS because I can pop back and forth between Blockster and full-bore Python.
I “try things out” in Bloxter to smoke test them for feasibility and then do the heavy lifting in Python.
Though, I would be willing to guess that there’s little you can do in Python that you can’t do in Bloxter - though it might be less efficient.
Sending a line to the folks at MR is a good idea.
Just remember to tell us what they say!
Thanks for the tip about Geany, much faster and nicer than Thonny. It runs the python script in a terminal prompt very nicely while I am prototyping.
I like Raspbian for Robots much, much better for my purposes. It will also do C, Java and other languages. My students learn more about Linux. The GoPiGo3 OS has way too many training wheels for my community college student training needs.
Are there “find the bugs” in motors.py?
I am not sure what you mean, they all work. I was working on them this afternoon, and finished testing them all a bit ago.
I saw two suspicious statements and didn’t want to spoil if they were intentional:
Motors.py
BTW, there are some new orbit commands in the API that are pretty cool also.
That was a mistake, it was supposed to print 180.
I did add in an orbit, it is pretty nice!
I didn’t look over those. Will students ever use multi-threading, multi-processing, or multiple programs accessing the same sensor, or accessing the I2C bus?
The EasyGoPiGo() class defaults use_mutex = False. I believe this to be a philosophical error to not use the protection mutex in preference to speed. I believe in optimizing only if and where needed, and always coding for errors/exceptions/conflicts/edges from the start. Thus, suggest all instances be created with use_mutex=True, which will get passed down to sensor instantiation where important.
You might find this interesting:
I don’t think so. I can get them up to accessing the sensors while doing something else. I am going to try to get them up to multi-threading.
I appreciate the info on use_mutex=True. I haven’t dug that far into the API or know enough yet to quite understand how mutex relates to multithreading. Always something more to learn!
DI implemented optional mutex protection around the I2C bus to prevent multiple threads or processes accessing the bus at the same time. If egpg=EasyGoPiGo3(“use_mutex=True”) was declared in each egpg object when instantiated, then the process or thread that wants to access a sensor via the bus, either acquires the mutex or waits until it acquires the mutex, so that only one process at a time will be sending commands across the bus.
The concept of a single resource with multiple users becomes important when complex programs get broken up into smaller independent programs, beyond the I2C bus also. On my robot I have an independant health check program that instantiates an EasyGoPiGo3() object to check the battery and perform a system shutdown if the battery level falls to low. This way, I don’t have to write battery level checks into every single program I write for the bot.
BUT - every instantiation of the EasyGoPiGo3() class performs a set_speed(300) under the covers. This can set up a race condition of who started when. My “juicer” program that puts the bot back on the dock wants the speed set at 150DPS for most accurate turns. If juicer starts first, resets the speed to 150DPS, and then “thinks” the speed will not change, it will not know that the healthcheck program starting is going to set the speed back to 300 DPS.
This last case is not solved by mutex, but illustrates some of the complexities of multiple processes accessing a single resource (the GoPiGo3 red board in this case).
One of the most difficult transitions in my programming career was to stop thinking linear execution of software. Today with every processor having multiple cores and algorithms so complex that execution gets farmed out across multiple cores in nets or graphics, avoiding linear thinking is a must.
Just a thought.
