Open JamesNewton opened 5 years ago
Another possibility is making SD Card image updates possible without removing the SD Cards. It should be possible to use a 16GB SD Card and partition the unused 8GB of it into a duplicate of the standard 8GB image. Then, a new image could be downloaded and written to that partition. Once complete, the new partition could be marked as the boot partition and the system restarted.
The size of the downloaded .img file is a serious problem in any case. Being able to download the /difference/ between two images might decrease the size and speed things up. There are programs that can compute the difference between large binary files. For example:
https://github.com/jmacd/xdelta/blob/wiki/CommandLineSyntax.md
To create a patch file with the difference between the old and new versions:
xdelta -e -s old_file new_file difference_file
To apply that patch to an old file to make the new one:
xdelta -d -s old_file difference_file new_file
The downside to this is that it would require more than a 16 GB SD Card; at least 32 GB and probably 64. You would need a working drive to store the original .img file (8GB) for the hard drive, and the patch file (?GB), and then the resulting new .img file (8GB) which would then be used to create the new partition.
I'm not sure how useful this is. Testing show that a binary diff of two images in which the only change is to a couple of small text files results in a patch which is almost 1MB in size. It would be far more efficient and safer to just download the text files. The binary diff of the Xillinux 12 version with the new 16.04 version was nearly 3GB and since very large updates like that will be rare, it seems less useful.
I like the idea of being able to keep your old version while you download a new version to your SD card that's in the robot. Then if the new image screws up, you can revert to the old image. But as JamesN says, that means having a significantly larger SD card. https://www.google.com/search?q=Amazon+16+GByte+SD+card&spell=1&sa=X&ved=0ahUKEwj0sM7L2uvgAhWlY98KHeXCD9IQBQgrKAA&biw=973&bih=531&dpr=2 says 16GByte SD card is only $5 quantity one. 64Gbyte is $11.55. Making the update process easy is indeed important.
On Tue, Mar 5, 2019 at 12:23 AM JamesNewton notifications@github.com wrote:
The size of the downloaded .img file is a serious problem in any case. Being able to download the /difference/ between two images might decrease the size and speed things up. There are programs that can compute the difference between large binary files. For example:
https://github.com/jmacd/xdelta/blob/wiki/CommandLineSyntax.md To create a patch file with the difference between the old and new versions: xdelta -e -s old_file new_file difference_file To apply that patch to an old file to make the new one: xdelta -d -s old_file difference_file new_file
The downside to this is that it would require more than a 16 GB SD Card; at least 32 GB and probably 64. You would need a working drive to store the original .img file (8GB) for the hard drive, and the patch file (?GB), and then the resulting new .img file (8GB) which would then be used to create the new partition.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HaddingtonDynamics/Dexter/issues/52#issuecomment-469542673, or mute the thread https://github.com/notifications/unsubscribe-auth/ABITfZcOZaZEtPmFpf_JQzgcNPR213v4ks5vTf9egaJpZM4aNLnZ .
Based on the advice of a couple facebook friends, it looks like it's possible to use the apt
system to just install updates which are developed by packaging up the changed files as if they were a regular software program. e.g. you could apt-get update
and our files would be downloaded, compiled and installed automatically, accomplishing exactly what we do manually. That update command could even be triggered periodically. Or via #20 .
From the apt-get update manual: " update is used to resynchronize the package index files from their sources. The indexes of available packages are fetched from the location(s) specified in /etc/apt/sources.list. "
Building a package is complex, but not impossible. https://debian-handbook.info/browse/stable/sect.building-first-package.html
This video breaks the process down into the simplest steps for making an application. It may be that we can make a "Dexter Update" application which is installed with scripts that then copy files into the other places they need to be. https://www.youtube.com/watch?v=nhoRyd2CEVs
Multiple SD Card extension cables have been tried, but all are either mechanically unsuited (too wide at the point the go into the existing socket, or poor mechanical interface at the extended socket) or poor quality. It may be that soldering wires onto the back of the existing connector and running them out to a sub PCB may be an option. Perhaps a better cable can be found.
https://www.adafruit.com/product/3688 is too wide at the end that plugs into the MicroZed card.
https://www.ebay.com/p/18023470718?iid=131565092246 fits well, but the connector is the type where you lay the card in the tray and then close the lid, so it really needs to be mounted flat. UPDATE: This has been functioning for years on an HDI, with the tray epoxied to the shoulder of the fan mount.
https://www.robotdigg.com/product/1119/15cm-SD-or-TF-card-extender-cable-for-3D-printing Has not been tried.
Another issue is finding a good place to mount the extended socket. Perhaps on the bottom inside of a new skin segment? See: "Skins" Issue #4
Kamino cloned this issue to HaddingtonDynamics/OCADO
Because the SD card slot on the microzed PCB is on the back side, and the stepper motor drivers on the motor board are right behind it, inserting and removing the SD card can be very difficult.
If the fan has been mounted directly over the stepper motor drivers, it must be removed for access. A fan mounted on the inside of the skin or otherwise placed out of the way and then ducted to the motor drivers is better.
The connector pads on the SD Card must be oriented facing the user, opposite the motor drivers.
This SD Card Tool can be 3D printed to help hold the card in position for insertion. It rests on the edge of the terminal blocks for proper alignment. Because the model is made to the exact dimensions of the card, and 3D printer filament often spreads, you may need to scrape out the slot a little after printing. If available, a fine drill (around 0.035" diameter) can be used to drill out the base of the slot to accommodate the slightly wider base of the SD Card. SD_Card_Tool.zip