Currently working on Inkblot v2 Scoring Web App.

The suggestion was to evaluate AWS vs Firebase (nodejs based, not Android as I usually do).

AWS is working really well work Inkblot v2 right now, so there’s little incentive to also do a Firebase version.

I’d still like to do a web app using Firebase to have a comparison with AWS, and Seeds seems like a good candidate for this. I have the Android app working fine, however my old Chrome extension does not work anymore since the AppScript-based apps have been deprecated.

Rebuilding it using Firebase would be a good target:

• Rely on their free tier, and measure cold latency (one of the big drawbacks of app engine in their free tier, which I do not see in AWS).
• Nodejs + React + Bootstrap, similar to what’s used in Inkblot v2.
• Google-only auth… how well do they integrate that in Firebase?
• Backend storage… how does it compare with GraphQL + DynamoDB?
• Note: the only thing I really need is to store the GDrive doc id.
• Deployment/hosting… this one would likely go on something like “seeds.alfray.com”.

Updated 2020-09-24: That project could also be a candidate to look again at Angular. I remember looking at Angular before React and couldn’t figure out the model… However now that I’m familiar with React (non native), looking at Angular a second time would be worth it, for a good comparison.

Current projects, either actually ongoing or started/pending:

• Conductor 2, the rewrite using a Groovy DSL. Want to continue. Perpetual hold.
• Low interest as the current version is “working fine” (with its limitations).
• I would have some renewed interest combined with home usage.
• Timeriffic 3…
• 2019 attempt did not work, it crippled most of the functionality, the impl was borked, it didn’t even really work well for basic stuff.
• That needs a full reboot if it’s going to go anywhere.
• This could be a candidate to do an app using RxJava + Kotlin.
• Jump Godot game.
• This is mostly a “technology” demo for Godot 3d to understand limitations.
• Got initial MVP (without the IAB part) on Play.
• There is no interest in making it a full blown complex play.
• I should take the MVP down, e.g. keep it alpha instead of public.
• Asqare.
• A reboot using Godot 2d.
• Sudoku
• May have some limited interest if it were to be a Kotlin + RxJava test bed.
• Risks having the usual issue of not going past the MVP.
• Dcc Cab:
• Current version is on Play. Not advertised much. Does what I need from it.
• Rig4r:
• Limited interest in Rust itself, however I can see how it is appropriate here.
• May continue… slowly?
• ESP32 vision.
• The 2 initial targets for this are crossing signal and virtual block detection.

Starting one and exploring a tech is easy and fun. Jump/Godot is an example where I had fun starting it. It fell a bit flat once I had the premise of a working version. I lack a push to complete these, and once the novelty wears off, there’s little incentive to continue adding to it instead of focusing on another idea.

For Rig4r, the initial objective was to spend a long week-end learning what Rust is all about. I’ve done that. I have no specific love for the new language, but neither did I for any other new language I’ve tried recently (Haskell, Go, Kotlin,... and now Rust). That’s because these languages do not fill any need that I don’t really have -- they really do not do anything Java can’t already do, no matter what the fanboys say. For example I’m not really happy with the current implementation of Rig4j, and that’s really not a Java/Dagger issue at all.

No amount of language hype is going to magically fix an implementation.

The other realization I made with Rig4j, the Java version, is that external libraries are what matters. In this case, the availability of a G Drive API and the HTML jsoup parsers were keys.

Would a rig4 reboot be a good target for Rust?

Rust and Google drive api: https://docs.rs/google-drive3/1.0.14+20200618/google_drive3/

Rust and html soup parsing: https://docs.rs/scraper/0.12.0/scraper/ and some more references.

A real reboot needs to focus on 2 different issues:

• The GDrive api to fetch docs is slow as molasses. It would make sense to separate this process, e.g. download and cache locally. The obvious issue is that fetching a doc requires parsing it to find its dependencies.
• More robust sanitizing of that drive html into rig 3 syntax.
• The tree parser and generator.

The focus here should be on caching to avoid fetching from drive as much as possible.

The other focus is on parsing that html and stripping it even more than I do now.

There could be 2 tools:

• Rig4 docs downloader that takes drive docs, the index, the blogs, and generates local rig4 files, updating assets when needed.
• Rig4 generator that only works locally.

Currently Asqare is totally off Google Play due to an injection vulnerability in the SQL code handling the score saves. The issue is rather irrelevant, but the automated Play tools don’t care and backlisted the app years ago.

Rebuilding it is possible… One reasoning a while ago was to do a reboot.

Today if I had to do Asqare again, I’d do it in Godot.

When a “custom Android build” gets created from the Godot android export, the generated GodotApp contains references to a GodotLib, which is provided as an AAR in the project.

A quick look at it in Studio shows references to a lot of stuff like event management, but also Payments classes, etc.

So let’s look at what Godot has that is linked to Android:

https://docs.godotengine.org/en/stable/tutorials/plugins/android/android_plugin.html: A “Godot Android plugin” is an independent AAR that one can add to a Godot project, and then use from the GDScript.

For example there’s a plugin for Oculus VR, and an official one for Google Play Billing compatible starting with Godot 3.2.2.

GodotPaymentsV3 is an older library that is superseded by the above Play billing plugin.

Now it's time to take [...] and understand Godot with 3d.  

Link to blender 2 godot exporter:

• https://gamefromscratch.com/blender2godot-add-on-released/
• Points to https://www.zammedev.com/home/wip_projects/blender2godot
• Points to https://gitlab.com/Zamme/blender2godot

This seems like a good way to get started. Create something in Blender and convert it to Godot.

One obvious teaching from some games is that a 3D game can basically be just a 2d game with a 3d rendering. That is probably the easiest way to get started.

Here’s an interesting topic to look into: Rust language, which presents itself as a Go / C++ alternative. But more importantly, how would it far in the content of:

• ESP32 or Arduin dev
• Integration with current libraries for Arduino.
• Integration with “generic” libraries such as OpenCV.

There’s something here for ESP32: https://github.com/MabezDev/xtensa-rust-quickstart

Several comments indicate that the rustc compiler can target ARM CPUs; and while not stated I’m guessing that would exclude all the AT-based Arduinos.

OpenCV bindings for Rust: https://docs.rs/opencv/0.45.0/opencv/

So that seems like it is a choice.

Apparently Rust stuff is packaged in “crates” and using a tool named “cargo”.

This reddit post indicates that “The only complete binding to the C++ API is opencv-rust, not to be confused with rust-opencv and rust-opencv-sys, which bind the C API.”

Here’s a random post on doing a React-like single page web application. One keyword I see often is “documentation is sparse”. One thing a lot of people misunderstand with new languages is that doxygen-style or javadoc-style API documentation is not a developer usage guide.

Apart from that, code examples seem fairly Go-like in spirit.

(Future self comment: I’ve made 2 attempts at jumping on the Rust hype bandwagon so far, one for server and one for ESP32, and these efforts didn’t go anywhere. I wasn’t exactly impressed.)

Interesting comment here in an Adafruit guide:

“If you're new to wireless communication and want to use BLE to make a group of microcontrollers talk to each other, we recommend you STOP RIGHT NOW AND GO LOOK AT THE PACKET RADIO FEATHERS.”

What they call “Packet Radio Boards”, namely RFM69 modules or RFM95 Lora (19 kpbs at 100m / 500m line of sight respectively) in either 433 MHz or 900 MHz.

“Feather” is the Adafruit name for an ATmega32u4 that has an RFM69 module directly on it. The RFM module uses the 3 SPI pins (SCK/MOSI/MISO).

The antenna for the US 915 MHz is simply a 3 inch long wire.

Guides:

• Adafruit RFM69HCW and RFM9X LoRa Packet Radio Breakouts.
• Using the RFM69 Radio with “RadioHead RFM69 library” example. That library has a simple send/receive for a binary blob buffer.

(Future self comment: this, of course, is a bit Adafruit selling their own stuff… Although there’s merit in the suggestion above especially for people who feel stuck on Arduino for some reason, yet there’s an alternative to consider here: ESP-NOW on any ESP32).

Current projects, in no particular order:

• Non-started un-ended research with OpenCV / ESP32-CAM.
• Interested in treating these as pages / research articles on the train site.
• Start with one such page for the “Layout Vision / Cam Proxy” one.
• Cab Engineer:
• Basic version was released on Play.
• Was not able to get Wear part distributed via Play.
• Turnout card does not scale well with many turnouts.
• Publicly available but not advertising it right now.
• Should list it on the train site.
• Quote Otter:
• Stuck in whatever-land.
• Randall:
• Nothing going on right now. Completed my “cam proxy” prototype.
• Conductor 2… limbo state. Want it. Tons of work to get there.
• Of interest:
• Circuit breaker for the Stockton Station
• One more LED for T150.
• Myriad more options like more block detectors, more turnout controls, and the whole Fairfield idea.
• Rig4j…
• Some gaming project.

So from all of that, what do I want to start with?

I’d say start with Godot and do something with it. It’s summer time.

Speaking of Godot, there are options: https://defold.com/about/ Defold, a “turn key game engine… Lua or C++”.

Although this should be in its own research doc, here’s a summary of two separate things I’d like to get done with model trains image detection. There’s some overlap yet they are different.

The first research subject is automated mapping: given a static image, find all tracks in the image, and create a visual schematic map of the network. There are two possible representations:

• Tracks form single paths (both lines and curves) with node intersections matching the frog of turnouts.
• Track segments -- lines, curves, and turnouts.

The first part of the problem is finding tracks in an image.

• A track is defined as two parallel rails with perpendicular ties in the middle. An additional constraint is that rails always have the same distance. Some obvious complications arise when we have parallel tracks. Outlier cases such as heavily weathered tracks where ties are invisible could be omitted. The outlier case of road crossings should be optionally treated though.
• Turnouts may be more difficult to detect. One approach is consider them the intersection of tracks, using a pure path/node approach. Turnouts geometry can be complex (e.g. double slip, X crossings). A first approach could just detect the “typical” simple turnout cases -- yard ladders, single sidings, and simple crossovers.
• Elevation is expected to be a problem, as detailed below.

The second part of the problem is to be able to map a layout by taking a series of “aerial” pictures, mapping track on each picture, and then merging them by detecting the edge overlaps.

• One simplification is to get images that are as much “from the top” as possible. Some kind of perspective should be expected and corrected. However this erases elevation and would make it nearly impossible to detect.
• Eye-level images would not be ideal as perspective is distorted and can make tract analysis a lot more difficult. There might be some compromise e.g. 45 degree view that would make the track still visible yet elevation possible to account for.

The second research is detecting trains on the track.