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.

Android development: what is needed to do a theme changer that supports light, dark, and system dynamic theming?

A good candidate is Seeds.

JavaCV: Used in Randall’s camera proxy app to capture data from an RTSP h264 / MJPEG feed, and produce jpeg images or publish an MJPEG web (via a Jetty web server).

OpenCV: for the Randall camera proxy project, need basic motion detection.

Some good tutorials here: https://opencv-python-tutroals.readthedocs.io/en/latest/py_tutorials/py_video/py_bg_subtraction/py_bg_subtraction.html

Example in Python. Java API available here: https://docs.opencv.org/master/javadoc/org/opencv/video/package-summary.html

And in JavaCV it shows how to convert frames between the FFMPEG input and what’s needed by the OpenCV library using “Mat” and an OpenCV converter.

Update 2020-06-09: The “cam-proxy” project is working nicely.

One realisation: I picked up the JavaCV approach as it seemed easier to get started, and that paid off. However it’s worth pointing out that the generated fatJar is an impressive 760 MB!

That is quite a feat.

Looking at the APIs, do I need all of JavaCV, or could I use only OpenCV with its Java bindings? Let’s see which APIs I’m using here:

• JavaCV.FFMpegFrameGrabber ⇒ there’s an OpenCV specific one.
• JavaCV.FFMpegFrameRecorder ⇒ to generate the MJPEG stream. Alternative?
• JavaCV.2dFrameConverters + CanvasFrame ⇒ there’s an OpenCV one.
• OpenCV core: IplImage, Size, Rect, Mat
• OpenCV imgproc: resize
• OpenCV video: cvCreateImage, mediamBlur, createBackgroundSubstractorMOG2.

• Thus one question is whether it’s possible to generate the output stream (MJPEG or h264) using OpenCV and its Java wrappers, or is FFMpeg needed for that?
• Uncompressed fatJar size:         2,762,758,664 bytes
• org/ part of the jar:                 2,227,823,156 bytes
• Opencv:                                1,065,264,936 bytes
• lib/ part of the jar:                  629,358,581 bytes
• Ffmpeg:                                  371,946,457 bytes
• Javacpp:                                   10,261,365 bytes
• Javacv:                                      921,733 bytes
• Jetty part:                              318,8118 bytes

So essentially trying to only use OpenCV would likely not save that much. A huge part of the JavaCV package is indeed OpenCV and a quick look at the final Jar shows that it contains not only java wrappers but also hpp headers, some xml, and most important the jni+si native libs for a lot of architectures (e.g. armhf, armeabi-v7, arm64-v8a, x86, x86_64). If an effort was needed to trim the jar file, it could be by avoiding packaging these in the first place by removing all the arm ones (3 out of 5 archs).