Setting the stage for the cavalry

Video: Hong Kong leader Carrie Lam withdraws extradition bill

No, it is not enough. But that is the plan. She is just setting the stage. 釜底抽薪。

First, she has taken away the main reason for the protests: the extradition bill. This shifts the moral high ground away from the protestors.

Next, she has said that she will disclose all investigations about police action. That is basically a projection of the "we are open, there is nothing to hide" image. An image of calm and compromise that is in contrast to the mass mobs of the protestors.

Then, she goes on to say those arrested will be dealt with according to the law because to do otherwise would be against the rule of law. Brilliant move; real democracies cannot contradict this statement, even though it probably means those arrested will be charged and jailed.

Throughout this whole incident, the government has gone all out to maintain the moral high ground in the eyes of the international community. Why? I think it is because they are setting the stage. Setting the stage for stronger action should the protestors continue with their protests.

And when the time is right, when the groundwork has been properly laid, the cavalry will come in. By then, if the government has played their cards right, most of the international community would be on their side.

天気の子 Weathering with You

I watched this anime quite some time ago. On its opening day in Japan, in fact. More than a month back. It is the latest work by director Shinkai Makoto, who brought us Your Name.

And like his previous great hit, this new work took the box office by storm. The movie also continues to feature breathtaking and highly realistic scenes, painstakingly detailing places in various parts of Tokyo.

The movie continues on the themes of searching and self-discovery as well as love, but it also portrays a more realistic view of Tokyo, with scenes featuring night-time entertainment, love hotels, and even yakuza. While most mainstream animation works avoid these portrayal, it seems that Shinkai Makoto does not shy away from fully portraying reality in his works.

So which is the better love story? Maybe, Garden of Words.

I digress.

All his works are touching, and you can see his signature. The realistic portrayal of places, so much so that fans visiting those places portrayed in his movies have become a mini-industry. The common theme of love. Of searching for something. Of trying to find one's calling. Of hope.

I am looking forward to the next great work. 😉

Stress testing the MRR ESPA

To make sure the MRR ESPA works stably, I have been using it to print some stuff. Some of them were fan covers (40mm and 80mm) and bases for mounting the MRR ESPA board and the more advanced MRR ESPE. But some were more for fun. Like these.

All of them were printed on my modified Ender-3, which has a clone Titan Aero direct drive and is controlled by the MRR ESPA. I haven't done much tweaking; it is still using an old profile meant for use with linear advance (which is not enabled on the MRR ESPA). With coasting and such, I should get better results, but my purpose now is not quality, but more to test stability. All in, the MRR ESPA has probably completed several hundred hours of printing.

Compiling TMCStepper for ESP32

I was trying to test TMC2130 support for the MRR ESPA and MRR ESPE using Marlin 2.0 bugsfix. However, I kept running into problems.

It started with the lack of SoftwareSerial.h.  Searching around, there is a EspSoftwareSerial library. But even using that didn't work for me. There were errors about override and such.

Then I came upon these issues in the TMCStepper repo.
ESP32 is no SoftwareSerial Compatible Platform
ESP32 compatibility

It seems the issue is that TMCStepper library has defined the ESP32 as capable of software serial. Which, technically, it is, but the available libraries to support software serial on the ESP32 somehow does not work well with the TMCStepper library. The workaround is to remove ESP32 from the list of platforms which are capable of software serial.

In TMCStepper.h, change:
#define SW_CAPABLE_PLATFORM defined(__AVR__) || defined(TARGET_LPC1768) || defined(ARDUINO_ARCH_ESP32) || defined(ARDUINO_ARCH_STM32F1)
to:
#define SW_CAPABLE_PLATFORM defined(__AVR__) || defined(TARGET_LPC1768) || defined(ARDUINO_ARCH_STM32F1)

Marlin 2.0 should then compile without errors.

Next step, flash the firmware onto the MRR ESPA/ESPE and check that the stepper motor actually moves.

Back to a familiar place for practice

It is always nice to be able to practise at a familiar place.

Same place, same people.

MRR ESPA basic ESP32-based 3D printer control board

I am happy to say that I am almost ready to unleash my 3D printer control board to the world. It is based on the ESP32 microcontroller, and after many revisions and lots of testing, it is almost ready to be released.

The MRR ESPA is the basic version. No whistles, no bells. It supports 4 stepper motors, a single hotend, and a heated bed. It can be connected to a host computer via USB, and can read directly from a microSD card too. The heated bed is isolated from the rest of the board via an optocoupler, so a separate power supply can be used to drive the heated bed, and this power supply can even be a different voltage.

 This is the MRR ESPA hooked up to my Ender-3.

A sample of the print. This is a simple test for stringing. I am using a direct drive setup on my Ender-3, and this was printed with 2mm retraction with a retraction speed of 25mm/s.

There is also a connector for a touchscreen controller like the MKS TFT32 (which is basically a host computer). However, common LCD controllers like the RepRap full graphics smart controller are not supported due to a lack of pins.

Wait, no LCD controller? Then how do you control the board?

Well, there is the USB port, right? This means you need to connect the board to a host computer, either a PC, or maybe a Raspberry Pi running Octoprint.

But that defeats the purpose of using the ESP32.

The ESP32 microcontroller comes with WiFi. And there is actually a fork of Marlin out there now that can be used on the MRR ESPA, and this fork gives the MRR ESPA a web UI. All you need to do is flash the firmware, and do the initial configuration to allow the MRR ESPA to connect to your home network via WiFi. Subsequently, all you need is a web browser; this can be a PC, a tablet, or even a smart phone. Files can be sent to the MRR ESPA via the web UI, you can start prints, set temperatures, move the print head, etc.

Sound great! But what are the limitations?

Well, this is the basic version, and due to a lack of pins on the ESP32, you are basically stuck with the features that this has. For stepper drivers, it can support the normal A4988, and you can use the silent TMC2130 and TMC2208 drivers in standalone/legacy modes. Basically, no SPI or UART control. However, there are two spare pins on the board, so if you really want TMC2130 drivers in SPI mode, you can actually use up to 2 of them (probably for the X and Y axes). Still, this support is in the pipeline, because from the software aspect, SPI mode support of TMC drivers for the ESP32 is still under development. But it should be ready soon.

And watch for the more advanced version of the MRR ESPA, which expands the board with additional outputs, allows up to 5 stepper drivers, and can be used with a LCD controller like the one on the Ender-3.

Note: Pre-launch version now available here. Some information on this has been updated here.

Playing with fans

In dabbling with 3D printers, one of the things that I had to deal with is ventilation. Fans.

Fans are used to cool the hotend so that the filament does not melt too far up the heat throat, causing clogs. Fans are used to cool the filament after it has been pushed out of the nozzle so that it hardens and bonds with previous layers. Fans are used to cool down the main control board, especially the drivers for the stepper motors, which can get quite hot.

And fans can also be quite noisy.

The standard fans you usually find on a 3D printer are these 40mm fans. They are 40mm by 40mm, and 10mm thick. They come in both 24V and 12V versions, as these are the common voltages used for 3D printers. There is also the blower type of fan, usually known as 5015 fans as they are 50mm in diameter and 15mm thick.

Fans, however, are available in other dimensions too. Recently, I have been playing around with 80mm fans. These are 80mm by 80mm; thickness can be 10mm, 15mm, or 25mm. What is amazing is that those 80x80x10mm fans are really quiet. They push out more air, but generate less noise that the 40x40x10mm fans. And so, I have been using them for my case fan (to cool the control board) instead of the usual 40x40x10mm fans. Super reduction in noise. I recommend them to everyone who wants to have a quieter setup. It is probably the reason they are used in computers too.

The 80x80x15mm fans push a lot of air too, but also sound a lot louder. To me, they are great as generic fans, like if I need to make a small desktop ventilation fan and don't mind the noise.

Blower type fans are also found in other voltages too, like the 5V ones below.

Back to the sound level issue. There are people out there who would spend the extra money (like, 5 times the money) for quiet fans like the Noctua. Unfortunately, I do not have that kind of money, so what I do is to get a fan rated for a higher voltage, and use it at a lower voltage. For example, I use a 12V fan to cool my Raspberry Pi, running the fan at 5V. It pushes out enough air to keep the Pi cool, but generates a lot less noise. This is a bit difficult for 24V setups, since 48V fans are not as readily available. Still you can always connect a power resistor in series with a 24V fan to lower the voltage across the fan; this waste energy, though. And make sure the resistor is rated for that kind of heat dissipation; a 2W resistor should be enough, but those 1/8W or 1/4W resistors we usually use for breadboards will NOT do.

Conclusion:
- Use 80x80x10mm fans for cases and such to cool the control board.
- Use a lower voltage to drive the fan (5V for 12V fan, or 12V for 24V fan; doing the reverse will overwork the fan, generate lots of noise, and shorten the life of your fan dramatically).

Diff/merge tool: Meld

In my work with designing a 3D printer control board, there is a need to work with the latest developmental version of Marlin firmware. But updating the configuration files can be quite tedious, since I need to do line by line comparison.

Then, I came across Meld.

And kicked myself for not finding it earlier.

It makes line by line comparison so much easier. The program itself compares the two files (it can actually compare up to three files, but I only need to compare two), and highlights all the differences. With a single click, you can choose to copy lines from one file to the other, either to update file A with the corresponding lines in file B, or the other way round.

This makes it so much easier to update the latest version of the configuration files with the settings that I have been using. And I can't believe I have lived with my manual, line-by-line way of doing things all this time.

Update 6 on ESP32-based 3D printer control board

Finally managed to test the updated control board.

The MRR ESPA (3D printer control board based on an ESP32 microcontroller) is finally in the final stages of development. Features include:
- Built-in WiFi, which allows a 3D printer to be controlled via an online web interface if the appropriate Marlin firmware (luc-github's Marlin fork) is used. The web interface is basically his ESP3D. There is even support for push notifications but I have not tested this out yet.
- 4 stepper drivers ready for standard A4988 drivers, but with jumper pins which will allow easier connection of TMC2130 drivers in SPI mode. With the jumpers in the right positions, you will only need to use jumper wires for the CS pins (one per stepper driver board).
- Opto-isolated bed heating rail, so that you can use a separate power supply unit of a different voltage (up to 24V) to heat the bed.
- Support for single hotend with part cooling fan.

Here is a test print. A quick one.

The main change from update 5 is that traces carrying high currents were widened and placed on both top and bottom copper layers. The bottom traces are also exposed to help with cooling. I had originally thought the heating problem near the 20A fuse was because the fuse was being used at close to 100% rated current, but I think it is more a case of the traces being too thin for the amount of current being carried. Anyway, after the changes, that area of the board no longer seems to be going above 100 degC when I am heating the bed using 12V (which translated to about 15A of current). When used with a 24V system, it is not a problem at all since the current is much lower, and therefore less heat is being dissipated.

Besides the MRR ESPA, I have also been working on a more advanced version of the board which uses I2S for stepper stream control. This is the MRR ESPE, which will feature the use of serial shift registers (74HC595) to convert an I2S stream into parallel outputs, which can then be used for the step, direction, and enable pins of the stepper drivers. The outputs from the shift register should also work for PWM control of MOSFETs and LCD data, and I will be testing them out. Meanwhile, here is a prototype of the MRR ESPE using I2S for stepper driver control.

It is not doing much, just doing a first-layer test print to help me make sure my bed mesh data is still good.

Anyway, future updates will probably be using the names of these boards in the title to better differentiate between the two (related) projects.

Note: Pre-launch version now available here. Some information on this has been updated here.

Sequel to the Tonkin Gulf Incident?

US Navy: Mine in tanker attack bears Iran hallmarks

Two ships were attacked in the Strait of Hormuz. Such attacks bring back memories of the 1980s, when Iran was attacking shipping in that very same location during its war with Iraq. And now, the US is saying that these recent attacks were conducted by Iran.

The US Navy, which said that North Vietnam attacked them in the Gulf of Tonkin in 1965, sparking the Vietnam War, is saying that Iran attacked innocent shipping in 2019. And just like 1965, the evidence is sketchy. The evidence is circumstantial; there is no "smoking gun," or "caught in the act" stuff here.

This is all the more worrying because witness accounts from the Japanese ship attacked stated the ship was hit by flying objects. Implying an attack either by projectile shells from a naval gun, or a missile. Both scenarios are not anywhere near to the limpet mine scenario being painted by the US Navy.

Even if we assume that the US Navy is being honest and that the attacks were caused by limpet mines. It was reported that they had a hard time trying to pry the magnets off the ship. If the magnets are so strong, it is going to be really hard for a boat to close the ship at sea, travel alongside it while braving the waves to place those mines. That implies the mines were planted in harbor. And if the mines were planted in harbor, it can be anyone who has access to that harbor. Not just the geographical neighbor of Iran where the explosion actually took place.

Whatever it is you choose to believe, a few pieces of magnets is not a smoking gun. Before going off on another Vietnam as "retaliation" or another Iraq to find "WMDs" based on how we feel about who the perpetrators may be, we should be asking ourselves, "What are the facts?"

Let's judge and act based on facts, not feelings.

What is the limit of personal land ownership?

Sky's the limit: Rise of delivery drones has U.S. cities asking who owns airspace

With technology moving much faster than laws, we are now caught up with this question: who owns the air above a piece of land, and how far up (or down) does that ownership extend?

When we started digging pipes and subways, the question of land ownership below the surface was more or less addressed. Most, if not all countries have laws in place delineating how deep land ownership goes.

But now, we start to have things flying over our heads, above our houses, over our yards. Yet, the legislation regarding ownership of space over a piece of land is still very much in its infancy, if born at all. Nations have such a definition for delineating between territorial airspace and outer space. But such a definition cannot serve private use. We can't have private ownership extending into the stratosphere; how can commercial aircraft fly if they have to get permission to fly over every piece of privately owned land?

So what is a realistic height for private ownership? We really need to answer this question NOW. Not just because of delivery drones. There are already companies working on the next step: flying Uber. Before we know it, there will be flying cars, and we will need to have boundaries in place for these flying cars because, unlike land-based cars, there are no physical roads to show them where they can and cannot go.

Just like we need rules to govern AI, we also need rules to govern this new dimension of personal mobility. I hope the relevant people get to work on this soon, because it is never good to be lagging behind. Companies should have the rules in place before they start research and development within those rules. Once they have come up with something, spending all that money, it is difficult to draw rules that will limit use of new technologies. If we try to do so, we can expect those companies, who have invested so much, to invest in lobbying to prevent such restrictions on what they have spent money on trying to earn more money. That's a sad fact of life.

Building Visual Studio Code on the Jetson Nano

After fixing my firewall, I tried to install Visual Studio Code on the Jetson Nano.

Following
Quick build guide for visual studio code on the nano
didn't really work out that well, with errors running gyp.

Searching around, I found this post (Building Visual Studio Code on Jetson Nano) and managed to build and install Visual Studio Code by merging the commands from the two posts.

The series of commands used:
curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -
sudo apt-get install -y nodejs
curl -sL https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list

sudo apt update
sudo apt install -y libx11-dev libxkbfile-dev libsecret-1-dev fakeroot npm curl nodejs nodejs-dev yarn

git clone https://github.com/Microsoft/vscode.git
pushd vscode
sed -i 's/4095/2048/g' package.json
scripts/npm.sh install
yarn
yarn run gulp vscode-linux-arm64-min
yarn run gulp vscode-linux-arm64-build-deb
sudo dpkg -i ./.build/linux/deb/arm64/deb/code-oss_1.??.?-*_arm64.deb

Then, to add the extensions manager, I followed this post.
Basically,
sudo nano /usr/share/code-oss/resources/app/product.json
and then, after
        "checksums": {
                "vs/workbench/workbench.main.js": "BompYN/DPDENjDaaz6Tl3w",
                "vs/workbench/workbench.main.css": "B0uvAV0QuNsAXdBJwcuhfA",
                "vs/code/electron-browser/workbench/workbench.html": "SJ2O65ioC$
                "vs/code/electron-browser/workbench/workbench.js": "+0ieKuns+AJ$
        }
add this:
,"extensionsGallery": {
    "serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery",
    "cacheUrl": "https://vscode.blob.core.windows.net/gallery/index",
    "itemUrl": "https://marketplace.visualstudio.com/items"
}
before the final bracket at the bottom.

Then reboot with:
sudo reboot

And after rebooting, run with:
code-oss

Hurray! 🎉🎊

Repairing Linux firewall

This is more a note to self, in case I mess up again.

I was playing around with the firewall on my Jetson Nano because I was testing out how to install NextCloud on it. However, I managed to thoroughly wreck my firewall settings, and in the end, I could not SSH in nor use VNC. So, I had to reset the firewall.

Here's how.

First, set all rules in iptables to ACCEPT.

sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

Then, flush the nat and mangle tables, and all chains.
sudo iptables -t nat -F
sudo iptables -t mangle -F
sudo iptables -F
sudo iptables -X

Then I did a reset of ufw with:
sudo ufw reset

I also had problems with the ufw rules, so I did something really stupid:
sudo rm -rf /etc/ufw

In the end, I had to reinstall ufw, and copy the default rules files by:
sudo apt remove ufw
sudo apt install ufw
sudo cp -p /usr/share/ufw/before.rules /etc/ufw/
sudo cp -p /usr/share/ufw/before6.rules /etc/ufw/
sudo cp -p /usr/share/ufw/after.rules /etc/ufw/
sudo cp -p /usr/share/ufw/after6.rules /etc/ufw/
sudo ufw enable

Then, add back the ports I need, like SSH, by:
sudo ufw allow ssh

And it seems I managed to get it working again. Phew!

Thoughts on "Should AI Research Try to Model the Human Brain?"

"Should AI Research Try to Model the Human Brain?"

My first thought was: what is intelligence? If intelligence is about being able to learn and apply new things, then whatever we try to come up with needs to be able to learn on its own and then apply that knowledge. The way this happens in the animal kingdom (including human beings) is the use of a brain. Neurons and synapses in the brain form a network, over time and stimulus, that allows learning and the application of learning.

In the past, getting machines to do things was also based on this model of learning and applying. But learning was not autonomous; the machine learns through the program fed in by the programmer. Simple programs evolved into more complex ones simulating learning through the use of more complex mathematical models and concepts.

As computing power increased, the implementation of simple artificial neural networks simulating the way neurons function in animal brains became possible. So now, we have deep learning as another field in machine learning, and we see progress each day. Machines are now able to learn complex games and beat humans at them.

But the model is still the same: a neuron connected to other neurons by synapses. The only difference is that human intelligence is limited by the number of neurons and synapses we can fit into our skulls, while computers are limited by the number of artificial neurons and synapses that we can fit into the computer's implementation in terms of hardware and software; it is limited by our current computing technology.

So is there a better model for learning and applying? We can understanding an AI model for learning and applying that is based on the human brain, because that is something familiar to us. But is our human/animal model the best model? Are there alternative models? Are there better models?

And if there are better models, what is the implication of their very existence? Does it mean the human brain can further evolve to that better model? Or does it mean that there may be a day when intelligent life based on this other model can appear?

Basic ESP32-CAM sketch

Some time back, I got myself some A.I. Thinker ESP32-CAM camera modules. Basically, these are camera modules controlled by an ESP32 microcontroller.

These modules actually work with the example found in the Arduino-ESP32 core. Which makes them very easy to program. But the example comes with a web interface for configuring the camera, such as resolution, white balance, etc. This web interface takes up quite a bit of flash memory space, actually. In fact, the example needs to be flashed onto the ESP32 using the "Huge app" partition setting in Arduino IDE for the ESP32.

The example also has another problem. It doesn't allow the ESP32-CAM to be used as a network camera on MotionEye. I tried; MotionEye refuses to recognize the module as a valid network camera. I think it is likely the web interface getting in the way.

Searching around, there is this basic sketch which removes the web interface. Wi-Fi credentials need to be put into a separate header file, which is included into the main sketch. And the sketch automatically sets the resolution to UXGA if PSRAM is found, and SVGA if not. The sketch is also small enough to fit into normal partitioning of the ESP32.

An improved version of the sketch can be found here. Basically, the changes are:
1. Wi-Fi credentials moved into the main sketch, just edit them directly without having to come up with additional header file (this may not be a good idea if you are sharing your sketches, but it is convenient otherwise).
2. mDNS is added to allow the camera module to be accessed by hostname; there is no need to hunt around for the IP address. For example,
http://esp32cam.local/
gives access to the video being streamed by the camera module if the hostname is set to esp32cam.
3. Resolution with PSRAM is set to SVGA (800x600) because that seems to be the best balance between resolution and FPS.

Anyway, MotionEye recognizes camera modules flashed with this sketch as a network camera. So when adding a camera, just select "Camera Type" as "Network Camera" and then enter "http://esp32cam.local/" (of whatever you change the hostname to) for the URL. Hook the module up to a small USB power supply, and put them in a corner of the house, and you have your own cheap surveillance camera.

Hurray!! 🎉🎊