You do know that pressing the off switch on the robot will first do an actual shutdown on the Pi, before attempting to remove power, right?
I have found some interesting discrepancies that I’d like to share. However, before I do that, would you please provide a checksum for either the ZIP file, the image file, or (better) both?
Preferably SHA-1 or longer.
I want to verify that my image is valid before writing bugs since these discrepancies (apparently) didn’t happen with the other users.
However, having a way to shut it down remotely is always a benefit.
Especially with Carl. He “lives” down where I cannot see that tiny button, so remote shutdown saves my back and keeps me from poking Carl blindly.
After spending some time with this new release, I am becoming very excited about it!
It appears possible to use this, (or create an instance of it), that combines the best parts of both DexterOS and Raspbian for Robots.
On the one hand, it appears to be open and accessible. If the normal R4R features do not already exist, I suspect they can be added very easily. Customization appears to be no less difficult than R4R.
On the other hand, the availability of things like Bloxter and, ultimately, the ability to contribute program elements to it, provides an excellent sand-boxing environment. This way I can try out ideas in a simplified environment that provides a way to experiment in a controlled way and work with features without needing to worry about inadvertent side-effects of other parts of my code.
Even though, (as a beta), it still needs a bit of work, I am excited about this and look forward to using it as a development platform.
My hat’s off to the people at Modular Robotics who helped put this together!
However, the converse is NOT true.
Starting a commanded shutdown on the Pi does NOT shutdown the GoPiGo controller board.
IMHO, this is functionality that should exist and that a commanded shutdown from any source, be it the desktop, command-line, SSH, Aliens from Mars, Russians tampering with the elections, (), or whatever, should do the exact same thing the “button-push” does - i.e. totally shut down the entire robot, including the controller.
Also, a hardware enhancement request:
It would be damn convenient if there were solder pads or through-holes in parallel with the push-button, (or even better, a couple of pins on 0.10" (2.54mm) centers), that people can use to wire in an external button. This way if the robot is more built-up, (like Carl and other robots I’ve seen), the “commanded shutdown” push-button can be made easily available.
Along with the ability to shutdown the 'bot remotely and wire an external switch, it would be handy to have a hardware method for rebooting the robot instead of just shutting it down.
(Compulsive Thread Police: Suggest new thread for collecting GoPiGo hardware suggestions)
Not a bad idea.
Does that actually throw an error?
What it looks like to ME is that they have an argument called “–confidence” (with two preceding dashes), that’s a float, and that “confidence” (note the lack of preceding dashes) is “–confidence” re-cast as an int.
Though I’m puzzled about the dashes. Are they legal?
No - but int(0.6) is 0, so later “if prob > confidence: tell us about it” will be more chatty than desired.
Python’s argument parser is quite versatile. For example:
# ARGUMENT PARSER import argparse ap == argparse.ArgumentParser() ap.add_argument("-c", "--confidence", type=float, default=0.6, help="Optional minimum probability to report object, default 0.6") args = vars(ap.parse_args()) min_confidence = args['confidence'] # float value
would allow invocations:
- myPythonProgram.py (min_confidence will be 0.6) - myPythonProgram.py -c 0.7 (min_confidence will be 0.7) - myPythonProgram.py --confidence 0.7 (min_confidence will be 0.7)
This does seem like an error. Since our pull from Tensorflow is pretty recent, it might still be in their github. Want to do a PR on their repo?
Too complicated for the moment; I’m not set up to do Jupyter notebooks actually. I found a “cheat path” to this running the GoPiGo OS beta on a bare Pi board (Carl is “busy” running a R4R PiOS HW I2C stress test.) but it isn’t exactly easy to get to it.
An update about the WiFi mode.
The two commands noted above, in essence, do the following:
- “Disable” removes the
start_as_access_point.servicesymlink from the
- “Enable” adds, (replaces), that symlink (which points to the
start_as_access_point.servicefile in the
I have deduced the following rules:
The only way to CHANGE the networking mode of your robot is via the web interface .
(as Nicole noted above, though somewhat hidden near the bottom of the section)
start_as_access_point.servicesymlink, if it exists, serves to force the next reboot to be in Access Point networking mode, regardless of what the current networking mode is.
Note that the converse is NOT true. That is, the absence of that symlink does NOT force Networked networking mode.
If that symlink is NOT present, the ‘bot will return to whatever mode it was in before the reboot occurred.
If the robot was in Access Point networking mode prior to the reboot, it will be in Access Point networking mode after the reboot.
If the robot was in Networked networking mode prior to the reboot, it will return to the Networked networking mode after the reboot.
If you want your robot to ALWAYS return to “Access Point” networking mode after every reboot, (the default behavior), run the “Enable” command.
If you want the robot to REMAIN in the current networking mode after each reboot, run the “Disable” command, or remove the symlink, and then change to the desired networking mode via the web interface.
A lot of the "Dexter/GoPiGo OS stuff seems to presuppose a lot of knowledge about Jupyter and Jupyter Notebooks and such.
Though I have been around the block once, maybe twice; I had never in my entire life heard about Jupyter anything until I bought my GoPiGo and ran the included DexterOS
Aside from wading through the copious documentation on Jupyter’s web site, (which goes to great lengths to tell you how wonderful Jupyter is, but little actual hands-on training), I haven’t found much in the way of “what do I do with this stuff?” What is there appears to be scaled to work well when projected on a 7-foot screen, but does little good on a 15" laptop monitor.
Recommendations would be appreciated.
@cleoqc Why you no longer support using 8xAA batteries??? I ask because of my post on Very hot components with External Power Supply / Power over Raspberry Pi and I use such an “empty battery holder” with 8xAA batteries. What can happen?
Note the following from the last PM I sent you. Hopefully Cleoqc and the rest of the MR team don’t object to me posting this here.
Redact/delete if necessary.
This is all I know.
As far as the first battery pack is concerned, it is very likely that the manufacturer of that pack recalled it, and Dexter/M.R. did the same with it’s customers in response.
The current battery pack, based on pictures and what I hear, appears to be a Hot Smokin’ Weapon, (figuratively!), and I would love to get one or two. The only disadvantage I can see is the relatively long charge time.
As far as powering the robot during development, where I need the Red Board powered up as well, I have a 12v supply with a barrel-plug the same size as the GoPiGo, and I use that with the robot sitting on my desk.
“live” testing where the robot moves is done on the floor with the batteries installed.
I used to test with both batteries and a 5v adapter, (and that caused no problems), but it was damned inconvenient, especially as the batteries would still die after a few hours of Dev work, requiring a re-charge. I have a total of three sets of batteries so that Charlie always has access to a live, fully charged, set. It’s still a pain though.
What is your native language?
P. P. S.
You should place some black electrical tape over the exposed metal contacts on each side of the battery. This will prevent accidental short-circuits and resulting damage.
Thank you for your help. I will place some black electrical tape over the metal contacts for safety.
My native language is german, sorry for my bad english, I hope it will get better someday…
Ihr Englisch ist sehr gut. Zweifellos besser als mein Deutsch. Schön Ihnen hier zu haben.
Don’t worry, your English is excellent! It’s much better than my German, or even Russian language skills.
Keine Sorge, dein Englisch ist ausgezeichnet! Es ist viel besser als meine Deutsch- oder sogar Russischkenntnisse