I’m assuming that the Vellman screen is I2C and uses one the addresses that GrovePi uses
You could disable the automated robot detection, it should take care of the split personality your robot experienced.
How is that done? What I2C address(es) does the Grove Pi use?
Even after removing the Vellman board, Charlie’s install was so messed up, half the functionality doesn’t work anymore. Guess that was not a wise move. At least I can re-flash the SD card and I’m back in business!
I don’t have a Raspbian for Robots next to me at the moment. I’ll see if I can find it in the code repo.
Try this:
sudo systemctl disable auto_detect_robot.service
sudo systemctl stop auto_detect_robot.service
It’s possible your card is messed up. It would be easier to start from a fresh one. That’s the cool part about GoPiGo, you can’t really mess it up to the point that it stops working forever.
Then run the above lines before adding the screen.
Truer words were never spoken! The only fussy part is if you have work stored on the card. I’m going to have to copy it off before I flash it again. And then re-configure it. And then change the name. And then. . . .
On Raspbian for Robots, you have an SD card copier available to you to keep a backup.
I suggest you start using it
And where might that be hidden? I’d love to make backups!
Do I have to pull the card to do it, or does it back up the card in place?
I can do this, but once that’s done, do I have to do something to make sure it comes up as a GoPiGo? Or, will it just use the “Detected Robot” file as is? (i.e. Let the rebuilt instance of R4R run normally once and let it autodetect, then disable autodetect?)
As long as you don’t swap the card for another robot, the detection will stay in place.
Did this.
I’m going to make sure everything ELSE is working before I plug the screen in again. . . .
And I am tempted to make an image backup of my SD card too!
While it is certainly possible to make a copy of the SD card by removing it from Charlie, and make a binary image, since the mere act of extracting (and reinserting) the SD card requires more dexterity than I can often muster, I use rpi-clone and a USB SD card adapter on Carl:
==== ON RPi: rpi-clone to make backup to a uSD card in USB adapter of RPi ====
Installation:
at ~/ (/home/pi/ )
git clone https://github.com/billw2/rpi-clone.git
cd rpi-clone
sudo cp rpi-clone rpi-clone-setup /usr/local/sbin
USAGE:
insert sdCard into USB Adapter
insert USB Adapter to RPi
df -h to find disk (/dev/sda and /dev/sda1 probably)
or more /proc/partitions
or lsblk
sudo rpi-clone sda [-L CARL] (to rename ext4 partition)
… unmount?: yes (/media/pi/xxxxx-xxx-xxx-xxx)
… unmount?: yes (/media/pi/boot)
… Init and clone to sda?: yes or Ok to proceed with the clone?: yes
… Opt label: (return for none)
…
Resizing last partition to end of disk … Resize success <-- when disk is smaller
…
Done with clone to /dev/sda
… Start - 17:17:08 End - 17:22:22 Elapsed Time - 5:14
Cloned partitions are mounted on /mnt/clone for inspection or customizing.
Hit Enter when ready to unmount the /dev/sda partitions …
… unmounting /mnt/clone/boot
… unmounting /mnt/clone
. . .and you can do all of this on a “hot” system?
Exactly the point of it. It does require a second card, the only drawback.
. . . . and that should be my biggest problem!
Acronis True Image claims to be able to perform “hot” backups too.
I’ve just never been able to get my arms, (or my sense of trust), around the idea of a “hot” backup on a running file-system, with files open, and things potentially being modified, and. . . .
Well, maybe that’s my years of WinDoze experience talking - I just don’t trust it!
Of course, those years of WinDoze experience haven’t made me overly confident about much of anything - Windows 10 still cannot find my Mint 19.3 installation on the same physical hard-drive!
Mint, on the other hand, has no difficulties finding - and booting! - my Windows 10 partition.
I guess I’ll have to (grinning wildly) condescend to allow LINUX to be my Windows boot manager!
Regarding the “backup files” from the Dexter desktop and the SD copier utilities, how big should the flash-drive / backup SD card be?
The mere act of extracting (and reinserting) the SD card requires more dexterity than I can often muster
Did you try this?
Greetings!
Here’s an idea I had that I thought I’d share.
Issue:
MicroSD cards are tiny, and they are easy to loose.
MicroSD cards are tiny. They can be difficult to remove from tight spaces without dragon-claw fingernails, tweezers, or small pliers which can damage the card.
Once written, there is no way to know what’s on them by simple visual inspection.
Having run into all three of these problems - loosing them, damaging them and accidentally overwriting something important - I needed t…
Did you try this?
Yes, I use 2 inch long segment of 12mm label maker tape folded in half making a 1" pull tab.
BUT, It still takes a prayer, a dance, and a miracle to get it back in.
“hot sys backup” - I just don’t trust it!
I have tested my monthly clone backup twice - everything seemed in order, but I didn’t run a MD5 sum or such.
the SD card copier will indeed let you backup the inserted SD card that’s up and running. it works. it’s linux
yes, you do need a second SD card to back up to.
I tried that today and, indeed, it appeared to work. That is, it didn’t throw any errors! I am planning on actually trying a “swap” of the SD cards tomorrow to see if the copy boots and runs.
With regard to backups in general, there appears to be some, (possibly), un-documented assumptions about the file backup process.
I inserted a 64gig, NTFS formatted flash drive into my 'bot, and hit the “file backup” icon on Charlie’s desktop.
Several interesting things happened:
- The file-backup process appears to expect the drive to be mounted on /mnt/bak_drive (or something like that, Charlie is asleep now and I can’t check the exact path).
- It wouldn’t use the existing flash drive, (mounted on /media/something-or-other), though it was visible, writable, and usable - it complained about not being able to get access to it.
- It went ahead and created a “bak_drive” folder under /mnt and placed a gzipped file there.
- If I forced the card to mount on the special /mnt/bak_drive (?) mount point by putting the flash drive’s UUID in fstab and mounting it there at boot time, it will use it - once - and then un-mounts it.
Interestingly enough, if I re-install the flash drive by removing and re-inserting it, it does NOT re-mount on the /mnt/bak_drive mount point. That only happens when the drive is in place during a reboot.
IMHO there appears to be something missing here - assumptions about what should be happening, and I seem to have missed that particular memo when it went around.
What are the expectations for a “file backup”? What am I missing here?
I’m planning on looking at that script tomorrow, though I thought you might want to help clarify a few things first.
Thanks!