Challenging myself to learn something new

I have recently set a big challenge for myself. I want to know about Machine Learning. To add to the challenge, I am trying out using the Zettelkasten method. The tool that I am using is Obsidian.

What is Zettelkasten?

It is a system for note-taking and personal knowledge management. From my reading, it looks like students and authors could use this method to help them organize their thoughts, make connections between thoughts, and turn those thoughts into written communication like term papers, doctoral thesis, books, or blog posts.

The heart of the system is to make a note that is focused on one topic, self-contained (no other explanation needed), permanent, concise, and linked to another note or notes.

Why am I look at Zettelkasten?

My current job requires me to read about various technologies and think about how to apply that technology to a business problem. I am hoping that Zettelkasten method can help me manage what I already know, acquire new knowledge, and make connections between the knowledge.

At work, the team and I make use of a shared Microsoft OneNote. Over the last 3 years, this notebook has grown rather large. It can be hard to find information using just a search. I have read that there are people who have figured out how to use Zettelkasten with OneNote. I need to learn a bit more about the method before I can teach it to someone else.

Why use Obsidian?

I picked Obsidian because it is cross-platform, free, looks simple to use, and looks a bit like Visual Studio Code. In learning about the tool there additional benefits became apparent. Obsidian makes use of Markdown. If I wanted I could switch to using a different tool to create and edit the markdown files. Backing up a markdown file is easy. The community has created a large number of plugins to help customize Obsidian and add functionality.

Why Machine Learning?

Mostly because I like to learn. This is an area that I know very little about. It seems to me that one aspect of machine learning known as Deep Learning could help me learn more.

There is an article from Stanford entitled "Deep learning algorithm does as well as dermatologists in identifying skin cancer" that shows the potential good deep learning has to offer.

References

1. Machine Learning
2. Zettelkasten
3. Obsidian
4. Microsoft OneNote
5. Markdown
6. Deep Learning
7. Deep learning algorithm does as well as dermatologists in identifying skin cancer

Back to learning about Docker

A few months ago, I started learning about Docker. I got derailed with work projects and personal projects. Now that I have a bit of time, I want to get back to learning about Docker. 

I came across the book "Learn Docker in a Month of Lunches" by Elton Stoneman. Elton is putting a YouTube video each workday.

Day 1 - Understanding Docker and running Hello, World

Docker Commands covered in "Learn Docker in a Month of Lunches: Day 1"

• docker version
• docker-compose version
• docker container run {name of image}
• docker container run --interactive --tty {name of a image}
• docker container ls
• docker container top {container id}
• docker container logs {container id}
• docker container inspect {container id}
• docker container ls --all
• docker container run --detach --publish {local port:container port} {name of a image}
• docker container status {container id}
• docker container rm --force $(docker container ls --all --quite)

Notes from Day 1

• The Docker Engine is the thing that runs the containers.
• Container wraps the application and has resources that the container can access.
• Containers are like a virtual environment in concept. One major difference is the container relies on the hosting machine's resources.
• Containers stop automatically when the code in the container stops.
• The Docker CLI can be configured to run against a local docker server or against a remote docker server

Day 2 - Building your own Docker images

Docker Commands covered in "Learn Docker in a Month of Lunches: 02"

• docker image pull {name of image}
• docker container run -d --name {name I want the container called} {name of image}
• docker container logs {name of image}
• docker container -rm {name of image}
• docker container run --end {key=value pair} {name of image}
• docker image build --tag {name} .
• docker image ls
• docker image history {image name}
• docker system df

Notes from Day 2

• Dockerfile contains the steps needed to build a Docker image. This kind of like install instructions or a runbook.
• Docker commands follow a pattern
• docker {command} {subcommand} - with Docker 1.13 the CLI was restructured
  
• We talk about an image as a singular thing. An image is built up of many layers or parts. The images parts can be shared among other images.
• Dockerfile
• Dockerfile commands are capitalized (ie FROM, ENV, WORKDIR)
• FROM line is required and is first-line
• WORKDIR creates a working directory
• CMD is the startup command for a container
• The size listed from the command 'docker image ls' is the logical size.
• A good practice is to structure the Dockerfile in such a way that the cache is used. This helps reduce the amount of time it takes to rebuild an image. 
• The build process creates a hash for each step in the Dockerfile. This hash is used to help determine if that step needs to be rebuilt. Once the build encounters a step that needs to be rebuilt then all steps from that point to the last step will be rebuilt.
• Put the commands that are least likely to change first

Day 3 - Packaging apps from source code into Docker images

Docker commands covered in "Learn Docker in a Month of Lunches: 03"

• docker image build -t { name of image } .
• docker container run { name of image }
• docker network create { name of network }
• docker container run --name { name of container} -d -p { host port }:{ container port } --network { name of network } { name of image }docker co
• docker image ls -f reference={first image} -f reference={second image}
• docker system prune

Notes from Day 3

• Able to run commands inside Dockerfile
• examples would be expanding zip files, running Windows installers, running a git command
• Dockerfile can contain multi-stages
• the final stage should contain only what is needed to run the application
• the image size can change while the image is building
• With Docker, it is possible to build an image from source code without having an SDK installed
• Dockerfile
• EXPOSE - port the container should listen on
• Multistage Dockerfiles are important and useful
• Helps standardize your project across various OS
• Helps standardize processes across projects. Any project using a Dockerfile basically need two commands to get the project running
• docker image build
• docker container run
• The use of layers within an image reduces the amount of time spent in rebuilding images
• The first time an image is built all the layers need to be pulled, processed, and cached. After the first build, the cached layers can be used.
• The order of the commands in the Dockerfile is important
• The use of layers and cache comes at the expensive of hard drive space
• Docker doesn't auto clean the cache
• Separates the build & package tools from what is needed for deployment
• Within a multistage Dockerfile, the steps in each stage should be organized so the steps change slowly or whose results are not like to change goes first.
• You can only optimize so far. If one step relies on the results of a previous step then the steps must appear in that order.
• An example would be the run command 
• 
  

Resources

• YouTube Playlist for the series
• GitHub Repo for the series
• Docker Docs
• Docker Docs on the Docker CLI

Fighting with the first layer

Recently, three events happened in a row that is leaving me with the problem of getting the first layer of my 3D prints to stick. The PLA filament that I was using ran out. An update to OctoPrint went sour, resulting in a rebuild. Lastly, I updated the version Cura I am using. 

I have tried several ways to get the print to stick. First was flipping the glass bed over. I have gone through the bed leveling process (both manual and automatic) several times. According to Bed Visualizer, I am close. In Cura, I have tweaked the 'Initial Layer Height' to 0.1 and the 'Build Plate Temperature' to 65C. The results I have gotten so far are either the filament doesn't stick or after a few layers, the edges start to curl and pull away from the bed. 

My next set of changes involved using a glue stick and switching from a skirt to a brim. I was able to get a 'CHEP Calibration Cube' to print. The print popped right of the bed. Closer inspection of the print revealed that the first layer is under extruded and the edges of the print pulled away from the bed. The top of the print (last layer) looks like the nozzle dig in a little (over extrusion).

I compared the latest print to prints from the previous roll of filament. The first layer on the previous filament is much thicker.

Possible Options

• Make sure the bed is level
• Good prints start with a level bed. 
• Did this 4 times earlier in the day
• Reduce the print speed for the first layer
• It idea behind the slower print speed is to give the filament time to flow out of the nozzle into place and harden.
• the current setting is 25 mm/s. This seems reasonable speed. I will skip with option
• Increase the height of the first layer 
• From what I have read, increasing the initial layer height can reduce the backpressure on the filament which should let the filament flow out a little easier.
• Increase the extrusion amount for the first layer
• This should force a bit more filament out. There is a possibility of the print suffering from an elephant's foot. It could also increase the backpressure on the filament.
• Increase the extruder temperature
• A little more heat could allow the filament to flow a little easier. 
• Check the filament diameter setting
• The filament size is 1.75 in the settings. 
• Checked the nozzle diameter at the same time. 

Setting up for the next test print

Reprinting the CHEP Calibration Cube. Changed the initial layer height from 0.1 to 0.12. Changed printing temperature from 195C to 200C. Used the glue stick on the bed. 

Results

The print stuck to the bed a lot better. The first layer doesn't have as many defects and imperfections. I can clearly see a space between each line the makes up the first layer. This looks under extruded.

It seems this filament like the 200C. 

Setting up for the next test print

Reprinting the CHEP Calibration Cube. Changed the initial layer height from 0.12 to 0.18. Used the glue stick again. 

Results

There is even less under extrusion with the first layer. 

Setting up for the next test print

This time, I going to print the CHEP Calibration Cube, one of the tolerance tests from Makers Muse, and a few models of my own design (drop ceiling clip). Changed the initial layer height from 0.18 to 0.20. Changed from brim to skirt. Used the glue stick on the bed.

Results

I canceled the print just as the 3rd layer was starting. One of the models was not sticking to the bed. The first layer is under extruded. 

Setting up for the next test print

Just printing the CHEP Calibration Cube. Changed the initial layer flow from 100% to 102%. Wiped the bed down with Isopropyl Alcohol. Used the glue stick.

Results

The print was really stuck down. I have to use a putty knife to get the print free. The individual lines that make up the first layer are a little fatter and there is still a bit of space between the lines. 

Wrap up

This turned out to be a good learning experience. The lesson of a 'level bed is the starting point' was re-enforced. I learned that the distance between the 'bed and the nozzle', 'how fast the material flows out of the nozzle', and 'type of bed surface' all impact each other.  

OctoPrint Reinstall

From the OctoPrint web site, I downloaded a new version of OctoPi 0.17.0 image. Used gparted to wipe out all the partitions on an SD card. Next came flashing the OctoPi image to the SD card using Etcher.

Modified the octopi-wpa-supplicant.txt on the boot drive with my network credentials and modified the country info

After placing the SD card back in the Pi, I powered the device up and waited 5 minutes. I found the IP address of the Pi then opened a terminal window and started an SSH session to the Pi. 

From the command line on the Pi, I ran the command 'sudo raspi-config'. I changed the Password, changed the Timezone, and updated to the latest version. For good measure, I rebooted the Pi.

Once OctoPi was up and running, I opened the URL to the local version of OctoPi, I went through the standard setup screens. After another few minutes, I was prompted to updated OctoPrint to 1.4.2.

Once the OctoPrint finished updating to the latest version and rebooted. It was time to get some plugins.

Plugins

• Bed Visualizer
• Ran multiple times and made small adjustments between each run. 
• EEPROM Marlin Editor
• Navbar Temp
• Octolapse 
• Starting off with this disabled. I will need to come back later to config and enable. 
• Octoslack 
• Themeify
•  Applied the settings from Teaching Tech
• Added a new style. Selector '.navbar-text', CSS-Rule 'color' Value '#667cea'
•  
  

In Cura, set up a connection to OctoPrint. The set up is found in Preferences -> Printers -> Select the printer -> Connect OctoPrint button.

 

Upgrade to Cura 4.7.1 and Upgrade of OctoPrint to Python3

Cura

Today, I made the jump from Cura 4.62 to Cura 4.7.1. In reviewing the release notes, for Cura 4.7.0 there were a lot of updates. I should have updated to Cura 4.7.0 earlier. 

There are some items in Cura 4.7.0 that I am looking forward to playing with or will make using the tool a little easier. 

• Rotation widgets
• Moved tree-support from experimental to normal settings
• Adjust initial layer horizontal expansion
• Allow a g-code to be inserted before or after pausing

Cura 4.7.1 contains a small list of bug fixes. 

 

OctoPrint

When I fired up OctoPrint today, I was greeted with the notice 'Upgrade your OctoPrint install to Python3!' After reading the blog post, I couldn't see a reason not to update. I open a SSH session to my Rasberry PI running OctoPrint and ran the commands from the article. It took a bit of time for everything to download and install.

There are some messages from the updated that will need to be researched or addressed at a later day. 

• Plugin Bed Level Visualizer successfully installed
• Warning: You have installed Bed Level visualiser. There is a known issue with it failing silently on Python 3
• See more here: https://github.com/jneilliii/OctoPrint-BedLevelVisualizer/issues/213
• These plugins were not found on the repo
• Please install them manually, from OctoPrint's plugin manager
• - HeaterTimeout
• Cleaning up...
• Finished! OctoPrint should be ready to go
• Once you have verified the install works, you can safely remove the folder /home/pi/oprint.bak
• If you want to go back (If it doesn't work) to Python 2 download the file at: https://raw.githubusercontent.com/cp2004/Octoprint-Upgrade-To-Py3/master/go_back.py

After rebooting the Raspberry Pi, I am now getting a message that 'The OctoPrint server is currently not running'. When I SSH to the Raspberry Pi, the message 'OctoPrint version : unknown' and 'OctoPi version : 0.17.0' is now displaying.

After a bit of thought, I am just going to rebuild the OctoPrint installation.

Updating the version of Docker on my primary machine

I noticed that the version of Docker that I am running a little behind the current stable version. I am thinking it is time to update.

After reading the 'Install Docker Engine on Ubuntu' page, I needed to make a few changes to my system.

My first step was to remove the source 'https://download.docker.com/linux/ubuntu disco stable' from sources. It was simple to follow the steps.

Ran the following commands

• sudo apt-get remove docker docker-engine docker.io containerd runc
• This made sure that any older versions were removed from my computer.
• sudo apt-get update
• sudo apt-get install \
      apt-transport-https \
      ca-certificates \
      curl \
      gnupg-agent \
      software-properties-common
• This allows apt to use a repository over HTTPS
• curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
• Added the Docker's GPG key
• sudo apt-key fingerprint 0EBFCD88
• Verifies that I have key with the correct fingerprint
• sudo add-apt-repository \
     "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
     $(lsb_release -cs) \
     stable"
• setup a the stable repository
  
• sudo apt-get update
• sudo apt-get install docker-ce docker-ce-cli containerd.io
• installed the latest version of Docker Engine and containerd

Trouble with updating version of GO on my Linux box

I had a little trouble with updating my version of GO. 

I started running the following commands

sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.14.7.linux-amd64.tar.gz

Now I should be done and ready. When I ran

go version

the old version number was reported. This is strange. My solution was to run the commands

which go
whereis go

to find out where GO was being referenced. After deleting all the references I was finally able to install the new version.