How to select the wireless mode for GPGOS at boot-time?

GoPiGo OS, DexterOS and Bloxter
1

@cleoqc,
@mitch.kremm,

Issue and/or enhancement request

At the present time, there are only two ways to change the WiFi mode for GPGOS:

  1. The Canonical Way:
    Boot into GPGOS, enter “Dexter” mode via the web browser, and change the Wifi mode. (And then mess with the /etc/System symlink if you don’t want the 'bot to revert to access point mode at the next reboot.)

  2. The Back-Door Way:
    Boot to the desktop, then add/remove/rename the “access-point” symlink in /etc/System (or something like that), and then force a reboot.

It would be very good if there were a way, during the actual boot process, to select the WiFi access mode.

For example:
I am doing something with the robot and I want to test it in both “Access Point” mode and “Local Network” mode.

It would be very convenient if I could, (for example), set a dip-switch that would select the WiFi access mode for the next reboot.  The existance of a file in the boot directory or a kernel boot parameter could be easily managed using a dip-switch.

Thinking about this, I could check the dip-switch at boot-time, check for the presence or absence of the symlink, and, (if necessary), change it to match the requested mode and then force a reboot.

However that’s clumsy and could easily create a boot-loop if exceptions are not carefully handled.

It would be better if there was a switch, or parameter, that could be passed at boot time that would accomplish that.

I can pass kernel/system parameters via the kernel boot command-line.  I am just not sure how to go about grabbing them post boot as a part of the startup process and using them.

Any ideas?

2 Likes
2

Actually there is a third way, but it’s a bizarre, three-handed, slopsided sneak.

  1. It requires a boot via PINN.
    • I do not think I can do this direct from any config.txt configuration.
    • I do not yet trust PINN to accurately place/replace an operating system due to issues with restoring permissions and/or access rights correctly.
  2. It also requires a specialized boot script within PINN that would:
    • Check special GPIO pin.
    • Mount the target OS partition.
    • Check for the special symlink, and modify it if necessary.
    • Un-mount the partition.
    • Boot the target OS.

Like I said, a three-handed, sideways-sort-of, sneak.  I don’t like it - for one thing error handling would be a $&#! - but I may not have much choice.
:roll_eyes:  :man_facepalming:

Bottom line, until either PINN gets access rights working and/or MR/DI come up with a solution, I’m stuck.

I may experiment with trying to get this working within PINN, but it won’t be my “main squeeze” untill they get it to where I trust it.

2 Likes
3

Update:

Procount over at the PINN sticky, has proposed a possible solution to PINN’s permissions issue.

If this works, the slopsided idea might work, but hopefully MR/DI will come up with a better way.

2 Likes
4

Hi Jim,

Thank you for all of these great details to bring to our team! We’re completely buried with work at the end of the month, but I’ll make sure Nicole and the rest of the team get eyes on this shortly.

Talk with you soon,

3 Likes
5

I am going to continue researching this and if I discover anything interesting, I will let you know.

1 Like