Humble Dave was programmed to start flashing his LED at 10v and safety shutdown was at 9.75v
I’ll probably use the 9.75 safety shutdown, and I want to add the “if it is 10v and between 8am and 10pm, shout HEY HUMAN, A LITTLE HELP HERE…”
Encoder Travails:
I was feeling good about my progress porting the Python easygopigo3.py to C++, and even figured out how to use VSCode to remote edit and build everything.
Today, the encoder handling is all over the floor. Whoever wrote the C++ GoPiGo3 used int32_t for the encoders, but 0 ticks minus 1 encoder tick returns a big positive integer like unsigned math, not -1 like signed int32.
I thought I was only going to be porting the EasyGoPiGo3 class but it seems like I need to do some mods on the C++ GoPiGo3 class as well. It is fun relearning C++; although C++ is a total PITA made even more crazy when I can’t trust the C++ that I’m attempting to learn from.
Decided to add my own explicitly unsigned integer encoder and raw encoder methods to the GoPiGo3 class to use in my EasyGoPiGo3 class.
(Using signed int methods and parameters for the encoders is just too confusing for me. For a 6-tick GoPiGo3 MOTOR_TICKS_PER_DEGREE is 2.0. Dividing an unsigned integer UINT_MAX by float 2.0 gives UINT_MAX/2 if done correctly, but UINT_MAX as an integer is -1 and dividing integer -1 by 2.0 is ???. Not sure how to use the official C++ encoder methods, so made my own unsigned int cognizant methods.)
What better way to understand some C++ code than to look at the same code in Python!
I had previously done all the work to get the GoPiGo3 Python API working on PiOS Bookworm, but the Pi5 introduced a new issue - no pigpiod on the Pi5.
Well guess how simple the fix for Pi5 was…just commented out the import and the five lines that used pigpio - done.
Python with all the sensors, motors, LEDs working like a charm!
Years we’ve been dancing around this pigpiod package and now I find out it isn’t needed and no one knew!
I came to the conclusion those lines of code are for setting up the SPI interface, which perhaps are needed if you don’t manually enable SPI in raspi-config (which I always do along with I2C as part of my base OS prep). I only needed to remove the pigpiod dependency for Pi5, but it may be it could have been eliminated long ago. (I cannot test other configs now that Dave has a Pi5 - only one PiOS will work on Pi5.)
This whole process (Bookworm PiOS and now Pi5) has led me to diverge farther and farther from the official ~/Dexter/GoPiGo3/Software. I think the only officially supported OS is the pre-packaged GoPiGo OS image. Probably still the right business decision since new GoPiGo3 users don’t seem to be showing up every Monday and Thursday asking for the latest PiOS, but if they will show up I think they can follow my documentation to get up and running on Pi4 or Pi5.
-c 5 Set it to check after every 5th mount if it hasn’t been caught by something else1.
-C 6 Set the current mount count to “6” so it immediately forces a fsck when rebooted.
-i 5 Set the interval based checking to every five days if it hasn’t been caught by something else1.
-e "remount-ro" If something is found, immediately forces the filesystem to remount as a read-only filesystem.
Note this only works if you regularly reboot. If your robot stays on-line continuously, it will never “catch”.
You set this for each partition individually if there are more than one ext-formatted partitions.
====================
“Catch/caught”:
Anything that compels an e2fsck resets the interval and mount-count dependent checking as it is “[condition] since last fsck”.
P.S.
If you are going to perform a manual fsck, also pass the “-D” parameter as it allows e2fsck to optimize the directory tree structure to make it more efficient. Note that it doesn’t change the actual hierarchical structure, (the order of the directories doesn’t change), but optimizes the physical structure within the filesystem to make sure it’s organized efficiently and doesn’t use more i-nodes than necessary. Sort of like defragging, but different.
I set it up for /dev/mmcblk0p2 but that misses the /boot/firmware partition, no?
This is what it says when I try for the whole parent device /dev/mmcblk0:
pi@GoPi5Go:~/GoPi5Go $ sudo tune2fs -c 5 -C 6 -i 7d -e remount-ro /dev/mmcblk0
tune2fs 1.47.0 (5-Feb-2023)
tune2fs: Bad magic number in super-block while trying to open /dev/mmcblk0
Found a dos partition table in /dev/mmcblk0
pi@GoPi5Go:~/GoPi5Go $ sudo tune2fs -l /dev/mmcblk0p1
tune2fs 1.47.0 (5-Feb-2023)
tune2fs: Bad magic number in super-block while trying to open /dev/mmcblk0p1
/dev/mmcblk0p1 contains a vfat file system labelled 'bootfs'
pi@GoPi5Go:~/GoPi5Go $
Rule 1:
Tune2fs is used for a partition1, (i.e. /dev/sda1, /dev/mmcblk0p2, etc.), not an entire block device, (i.e. /dev/sda, /dev/mmcblk0, etc.).
Rule 2:
Tune2fs is only valid with ext partitions. ext2, ext3 and ext4.
That’s correct. /boot isn’t really a part of root’s ext4 filesystem, being mounted on top of the /boot directory there.
e2fsck only works on the exe2/3/4 partition itself, skipping any overlay mounts as it functions at the partition filesystem level.
tune2fs actually does nothing to the partition per-se as it simply sets partition metadata/flags that control the way the partition operates with respect to its filesystem. For example, “has-journal” is a filesystem attribute. Likewise, so is the current mount count, the maximum mount count, the filesystem’s UUID, label, etc.
If you look up the man-page for ‘mkfs’ will be useful as you can set flags/properties at format time. These properties can also be passed via a manual mount or within the mount string in fstab.
Especially interesting is the “discard” option which enables “discard”/TRIM for solid-state media. (It is disabled by default.) Virtually all SSD’s, both internal and external, support it and some of the later, brand-named, SD cards also support it, or ignore it if specified.
====================
It is possible to format an entire block device, (there are some early systems that used a partitionless hard drive format, such as early Winchester-type MFM/RLL hard drives), but it’s very unusual and is not normally done in a modern operating system.
I actually did that once while trying to create one of my very first RAID systems on a 'nix box, but it was strange and did weird things - I ended up moving the data off of it and reformatting it in a more conventional way.
And GoPi5Go-Dave really needs a hardware doctor. I do not believe my GoPiGo code can make the sd card suddenly non-readable to an “ls” command, (and prevent further remote connections).
The GoPiGo3 programs continue driving Dave, and reading the GoPiGo3 battery voltage as long as the program operates on RAM, but die if they try to write to the SDCard.
I have a status program running that says no temperature or voltage throttling is or has occurred, (and that low voltage detection is really sensitive and trustworthy, at least it always has been on Pi3 and Pi4).
Since the only way to recover is to reboot, I don’t know how to see a log entry of why the SDCard became inaccessible.
Did you try a hard reboot? (i.e. full shutdown, remove power, wait 30 seconds, and reboot.)
Did you try removing the SD card and inserting into a different Linux system? You can fsck it there, even if it remounts r/o, because fsck only works on unmounted partitions.
No other way to recover, since any command I enter, such as “shutdown -h now” tries to find the shutdown program on the card which is not readable. I have to jerk the power, which luckily is no longer risky because the SDCard is not accessible at that point.
The tune2fs -c 5 -C 6 caused the check before the partition was mounted at boot time, as I understand it, but no, I have not tried from another Linux system.
