I know that Dexter OS is deprecated but, since I am following handsonros (see my newbie post in General Discussion), I thought I should do things by the book (well, that book anyway) and calibrate my GoPiGo3 starting with that OS.
The simplest calibrations are the ones built into help icon of the Dexter OS - see here. For the “driving proper distance” calibration, the default wheel diameter = 66.5 but you adjust that value up or down to make the robot drive the standard distance (2 meters or 2 feet). When I did this calibration, I found that a wheel diameter = 62 mm gave a drive distance that was too short and wheel diameter = 61 mm gave a drive distance that was pretty close but still too long.
Here is the odd part though. When I tried wheel diameter values in the range of 61.1 mm thru 61.9 mm, the robot always stopped at the same distance as for wheel diameter = 61 mm. It seems that, in this context, the wheel diameter parameter behaves like (is converted into?) an integer with truncation of any float you type in. Has anyone else seen this behavior in the Dexter OS calibration tool? Is there a similar calibration tool in the GoPiGo OS and does it have the same behavior?
@este One problem of using an old OS is that I stopped messing with that version when GoPiGo OS replaced it. Dexter Industries that produced the Dexter OS was bought by Modular Robotics, which luckily continued to fund the GoPiGo3 software support. Modular Robotics fixed many of the bugs of the Dexter OS, enhanced it to support Pi4 and some new features, and “rebranded” it as GoPiGo OS.
Also you have probably seen that official support for the GoPiGo3 is support@modrobotics.com
Hearing your description of the problem makes me wonder what is in your /home/pi/Dexter/gpg3_config.json file? Is it changing to the desired value when you set it at 61.1 thru 61.9? Did you hit return after entering a new value? (I don’t know if that makes a difference, just brainstorming here) You may have to set a value, hit return/enter, then save and exit and return to the calibration function. I remember some issues with calibration back then but I don’t remember details as it has been so long since I messed with Dexter OS.
If the same issue exists in GoPiGo OS 3.03 (I think that is the latest version) then MR will definitely want to hear from you. I will fire up my copy (a bit of a pain as I couldn’t reliably get it configured to my router, so I have to use an iPad and connect to the GoPiGo SSID) tomorrow to re-familiarize myself with the cal function’s “personality”.
I just compared the 3.0.x dialog - the function has changed since the version you are running - at the minimum to support the 16 tick encoders, and another refinement (Try Again Button).
Download the latest GoPiGo O/S which is 3-dot-somrthing last time I checked.
That old software was deprecated for a reason so, unless you’re running a very old robot using an ancient Pi board, you will want to use the latest GoPiGo OS.
Normally, I would bypass the Dexter OS but I am really trying to follow the handsonros book to see what still works and what does not work ca. 3 years after the its release.
There may never be another edition of handsonros so, as time allows, I will try to compare Dexter OS and GoPiGo OS in the context of what that book is trying to achieve along its path to using ROS.
I don’t know if you mean the actual Dexter O/S, or the Dexter Industries/Modular Robotics releases.
Dexter O/S was originally intended as a “closed”, un-tweakable OS that school children couldn’t bork-up.
The current GoPiGo OS is designed to incorporate both the features of Dexter OS and Raspbian for Robots and is the recommended OS for normal use.
For advanced use-cases like ROS, the usual path is an Ubuntu download modified by installing the ROS libraries on top of it.
Note that I am not an expert in ROS, having discovered that GoPiGo OS is more than sufficiently difficult for me.
@cyclicalobsessive and @KeithW are the resident ROS experts. I can heartily recommend reading anything and everything they’ve written, ROS related or not. It will amply repay the time spent.
Yup, I mean the original and now deprecated DexterOS used for what @brjapon in handsonros referred to as Unit Tests (i.e. test if individual units like individual motors and sensors). Just following the plan in handsonros.
Unless you’re using an earlier Raspberry Pi board, (possibly 3 or earlier?), the original Dexter OS won’t work due to architectural differences between the earlier and later board types.
Supposedly, there are some boot-tweaks that can be done to bypass some of these differences, but the current GoPiGo OS should provide all the unit test functionality you need, and then some, like camera testing.
There are a few quirks which have been documented elsewhere within these forums, but overall you should find it more than adequate for testing and familiarization with the 'bot.
In my own case, I often use the “Bloxter” language environment for quick “sandbox” or “proof-of-concept” testing. I find it especially valuable since once you get something working in Bloxter, you can “flip” it to native code to see how to actually code it in your own programs.
The Dexter documentation is generally good, but like any documentation project, “a code snippet is worth a thousand words”.
@jimrh Thanks for mentioning that. Page 20-21 of handsonros indicates a Raspi 3 B+ so that is what I used. I have several, not counting the ones running Octopi on my 3D printers so no problem!
