GoPiGo OS 1 entering Beta!

[cyclicalobsessive]

@cleoqc

You do know that pressing the off switch on the robot will first do an actual shutdown on the Pi

@jimrh

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.

[jimrh]

Greetings!

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!

[jimrh]

@cleoqc

You do know that pressing the off switch on the robot will first do an actual shutdown on the Pi

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.

[jimrh]

P.S.
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.

Thanks!

[cyclicalobsessive]

@jimrh

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)

[jimrh]

@cyclicalobsessive

Suggest new thread for collecting GoPiGo hardware suggestions

Not a bad idea.

[cyclicalobsessive]

Tensor Flow Lite Jupyter Notebook Example Error

(This comes from TensorFlow with the defect…)

[jimrh]

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?

[cyclicalobsessive]

@jimrh

Does that actually throw an error?

No - but int(0.6) is 0, so later “if prob > confidence: tell us about it” will be more chatty than desired.

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?

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)

[cleoqc]

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?

[cyclicalobsessive]

@cleoqc

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 I²C stress test.) but it isn’t exactly easy to get to it.

[jimrh]

@cleoqc

Things to know about the wifi feature:
Every boot-up will be in Access Point mode. . . .

If you know that the robot will always stay home, you can disable this and take full responsibility. Go to the Jupyter terminal and type in :

sudo systemctl disable start_as_access_point.service

Should you ever need to take the robot elsewhere, you will have to remember to run

sudo systemctl enable start_as_access_point.service

before you leave!

Things to know:
<snip>
Please note the limitation that you cannot switch from Access Point mode to Wifi mode through VNC. It has to be done via the browser.

An update about the WiFi mode.

The two commands noted above, in essence, do the following:

• “Disable” removes the start_as_access_point.service symlink from the /etc/systemd/system/dexteros.target.wants/ directory.
• “Enable” adds, (replaces), that symlink (which points to the start_as_access_point.service file in the /etc/systemd/system directory.)
   

I have deduced the following rules:

1. 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)

2. The start_as_access_point.service symlink, 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.

3. 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.

Important Takeaways:

• 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.

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

P.S.
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.

[woody123]

@cleoqc

ger sell the empty battery holder. We had a major recall on all battery packs. In other words, we no longer support using 8xAA batteries, for safety reasons.

@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?

[jimrh]

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.

@cleoqc
Redact/delete if necessary.

Viz.:

What happened to me is that the 8-cell AA battery holder that used to ship with the GoPiGo has exposed metal contacts on the outside of the battery holder, and the outer-shell of the plug that goes to the GoiPiGo made contact with one of those contacts near the end of the battery, putting about 10v at about 2 amps through it as a direct short-circuit.

The resultant short-circuit caused a (very) small fire, smoke, and a lot of plastic damage to the battery holder itself. I was able to keep things happy, got the holder working again and eventually bought a new 8-cell holder from a local retailer here in Moscow Russia. I attached the GoPiGo barrel-plug and cord to it, taped over the ends with black electrical tape to prevent future short circuits, and this is what I currently use.

I mentioned this to the people at Dexter Industries, (this was just before they were bought out by Modular Robotics), and they, (apparently, as I am guessing now), went with a monolithic, rechargeable battery pack right afterwards.

THAT particular battery pack, (for reasons I am not familiar with, they never went into details), was recalled, and has now been replaced with a modular Li-Ion battery block and charger. Were I in the US, I would order a couple of packs and a charger for it.

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.

P. S.
What is your native language?

P. P. S.

@woody123

I use such an “empty battery holder” with 8xAA batteries. What can happen?

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.

[woody123]

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…

[KeithW]

Ihr Englisch ist sehr gut. Zweifellos besser als mein Deutsch. Schön Ihnen hier zu haben.
/K

[jimrh]

@woody123

My native language is german, sorry for my bad english, I hope it will get better someday

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

[cleoqc]

@woody123

Why you no longer support using 8xAA batteries???

Once we put the stickers on the battery holder, it was perfectly fine. We didn’t get any reports of any issues after that. But these robots are meant for the classroom, and students are prone to, hmmm, not always do the wise thing.

So while the battery holder was just fine, the lack of any protection circuit at all was worrisome. We decided it was best overall to only offer batteries that do have a protection circuit in place.

[jimrh]

@cleoqc

But these robots are meant for the classroom, and students are prone to, hmmm, not always do the wise thing.

Oops!
Can you say “YouTube”? Ahh! I KNEW you could!