Here’s an interesting problem in Cab v2:

• Main app: Main app component.
• WiThrottle library: Lib component.

The design I want is for the library to be an extension to the main app. The library provides components/modules that the main app can use and inject. The library itself cannot use anything from the app (since it is app-agnostic).

In terms of components/scopes: the library is the outer component, and the app is a sub-component of the library. The app can use elements provided by the library.

When using component dependencies, which one depends on which?

• https://proandroiddev.com/dagger-2-part-ii-custom-scopes-component-dependencies-subcomponents-697c1fa1cfc
• https://proandroiddev.com/dagger-component-dependencies-for-library-development-e2df7ce68233

I think that means the app component has a dependency on the lib component.

This seems to work with some caveats:

• @Singleton @Component AppComponent // dependencies = { LibComponent.class }

Issue:

• At build time “dagger AppComponent scoped may not reference bindings with different scopes”.
• ⇒ Two ways to fix that: either remove all scoping info from the dependencies component and everything provided; Can’t even be in the same @Singleton. Obviously that’s not right.
• ⇒ Both components can have and likely should have different scopes. However the “root” component must provide everything explicitly by using getters in the component.

E.g.:

@Component LibComponent {
 ExportedType1 getExportedType1();
 ExportedType2 getExportedType2();
}
Etc

Module providers in the LibComponent are not exported to the dependent component unless explicitly stated that way. If something needs an explicit module provider, it also needs an “exporter” declaration in the component. If something is not explicitly exported by the root component, dagger will try to use the type as-is, notice the scope discrepancy and basically ask for either a different scope or an explicit provider if the object has no scope.

[win] d: t/dev/jadx … jadx-gui

select apk

prefs select deobfuscation

save gradle project in e: temp android apk

In the “game with train themes” department, it would be interesting to find an engine with actual already available resources to make one demo sample of either. One thing I could learn is the interaction model.

As far as 3D engines go, Godot seems like a viable choice for my needs. That or a full “do it yourself” LibGDX-based approach like I was trying for Tracks.

Eventually it all boils down to assets. That’s the key thing, and the one weakness I strongly have. Looking at both above: The train shunting puzzle is within my reach; except I’m not keen on the end result and thus consider not worth the effort going there; and the large popular game is out of my reach, the number of 3d assets being way beyond my abilities.

It’s also the same usual problem: I’m looking at a bunch of game demos, and realize I don’t really want to spend that much time to get that level of result (the usual 80/80 rule applies here). And I don’t want a me-too result either.

One feature I miss with trains is scripting. Back in 2014 or 2015, I wrote a very simple cab command interpreter in python for JMRI, “cab3.py”.

I should add something like in Cab Engineer:

• Tie it with an existing throttle (e.g. for a specific DCC address)
• Or let the script change/mix engines.
• Be able to save / recall scripts.
• Also control turnouts.
• Introduce a mini-editor with a less cryptic language, and buttons to quickly insert language keywords.
• Make it line-agnostic so that the script can be one line or multi lines.

Random examples:

Label start

Throttle 537 speed +12 for 5s until B370 then speed 0

Reverse T330

F2 press

F5 on

Throttle 113 speed +12 for 2s

Speed 0

Speed -12 for 2s

Normal T330

F5 off

Throttle 537 speed -12 for 5s until B310 then speed 0

Loop start

Here each command is one keyword + one value, and the “then” keyword is a no-op.

A command like “for” or “until” would simply introduce a pause.

A “function press” would toggle it for a fixed time, e.g. 300-500 ms.

A logical extension is a “record macro” mode, that records the actions, generates the script, which can then be edited, saved, recalled.

Recalling a script would open a card on the recycle view with a status/run/stop. Running would “inject” commands in controllers, but not block the user. E.g. one could try to “beat” the system, or start/stop an engine during a macro run. Useful for things like horn/bell, or prevent a collision.

A follow up to 2020-04-04 Cab Throttle aka “Cab Engineer”: Importing Cab Throttle source has been done. It’s called “Cab Engineer”, and as all the source from Cab Throttle + WiThrottleLib.

The project has been changed to be compliant with Permanent Service & notifications required by API 26+.

Next steps are:

• Add dagger support.
• Use my mini RxJava instead of the event bus.
• Add new features:
• Toggle turnouts. [added as of 2020-04-10]
• Recall previous DCC addresses.
• Recall JMRI roster.
• Some less important yet desirable features for me:
• Support Day vs Night modes (with a quick toggle change).
• Support “soft” consisting.

I may not do it in that order. E.g. dagger/rx are less useful than core new features.

Note that when I started it, WiThrottleLib was able to support 2 modes:

• “Single throttle protocol” with multiple sockets to JMRI, for JMRI < 2.
• “Multi-throttle protocol” with a single socket to JMRI, for JMRI >= 2.

Now that JMRI is in v4, I think the “< v2” support is… useless. I won’t remove it but I won’t extend it either. Things like roster & turnouts are only going to be added to the more modern part.

As for the name, I'm pretty sure I don’t want to tie it to the “DCC” name publicly, even though the current implementation is very DCC and JMRI centric. E.g. for addresses, only DCC specs are supported, with short vs long addresses.

I’m currently in the process of a full rewrite of Cab Throttle, and to make a long story short, I decided to entirely rewrite it. Cab v2 is the new project.

Somewhat of a tangent, looking back at Cab Throttle vs Cab v2 makes me wonder: is LibUtils useful anymore?

Maybe, but I think it’s time to change from android-lib-v2 to android-lib-v3

https://bitbucket.org/ralfoide/libutils/src/android-lib-v2/LibUtilsAndroid/build.gradle

One of the issues here is the cross-project dependencies. LibUtils depends on Dagger, on Mockito, on Robolectric, and on JUnit. All these versions must match together, otherwise imports get wonky. Robolectric and Dagger are the main drivers and are very opinionated.

For example that means I can’t have a lib with Robolectric v3 and a main project with v4. And even within versions, I’ve had conflicts when multiple JUnit or Mockito libs are imported.

One thought is to fix that by revisions. Lib-v2 goes up to Robolectric 3, and lib-v3 is to be used for “modern” projects with Robolectric 4.

Tutorials / intro / 2d game step by step:
https://www.gamefromscratch.com/page/Godot-3-Tutorial-Series-Index.aspx

https://godotengine.org/download/windows

The download is not an installer, it’s the full thing just zipped in-place.

Which means if I won’t use C#, just use the standard thing and I can always trivially change later.

“Godot… standard vs Mono C#” -- the difference is that the 2nd supports everything(?) including C#, whereas the former is limited to using GDScript (a python look-alike). I’d venture the C# one is designed to ease people coming from Unity.

The C# version requires the Mono SDK: https://www.mono-project.com/download/stable/

Or the Visual Studio Build Tools: https://visualstudio.microsoft.com/downloads/?q=build+tools (which seem packaged separately from the full VS.Net?)

Thus going with Standard for now.

Doing what?

Either 2d or 3d (fixed perspective, toy like rendering), something with trains and tracks. First do a prototype demo to see if I can even render what I like. Game wise I'd like a tower defense/attack.

Pending home projects, in that order, that I’d really like to see completed this year:

• React Otter:
• For the demo, finish learning how to do the data-server backend part.
• For the MVP, implement a cron task sending tweets & creating images.
• Conductor 2:
• Finish the Groovy design. It has potential, yet right now it is in an unfinished design state.
• Rework the implementation with a focus on tests.
• ESP32-CAM:
• Work on video track detection, with the smaller goal of doing a crossing gate controller.
• The desire is for that work to be later used to control Fairfield or other automation.

Specs:

• Target: Froyo Android 2.2
• Keep screen on when plugged in.
• Release screen lock when on battery.
• Remember timer / restore after restart. Compensate for time off (if accurate).
• Change timer color:
• white default.
• orange if > 24h
• red if > 48h
• red blink if > 72h
• Email updates notifications.

And yes, the target really is Froyo Android 2.2. I like to reuse old phones as dedicated one-off appliances.

One discussion on the Arduini mailing list centered about the use of Arduinos to commonly do Crossing Gates mechanisms. The projects are considered “trivial” as they involve commanding servos (to move gate arms) and blinking LEDs for the crossing lights. There are modules to do sound too. Both are ubiquitous with Arduinos and well designed for that.

Typically inputs come from photoresistor, IR leds for detection, or less commonly from existing block detection modules.

This makes me think an ESP32-CAM would be almost suitable for that. What form would it take?

• First, I should wonder whether something like OpenCV is even needed here. I’m not familiar enough with it to know whether it would help. On a fixed camera, simple naive image detection would be enough to see if there’s any motion change on a masked area. A simple average+diff algorithm would probably be good enough.
• Second, implementation wise, C or MicroPython? I’m surprised we don’t see more of the latter. It’s certainly slow yet good enough to just blink a LED or move a servo. It would not be suitable for image analysis, though.
• The ESP32-CAM MicroPython fork made it clear this is done by taking a specific commit on the ESP32 repo, not all of them are suitable; then add the camera module in C as a Python module, then use it from Python as a black box.
• At that point that does mean that developing on the module is best done in a separate C sketch. And from a distribution model, an Arduino sketch is still the easiest way to deliver this to an end user who needs to tinker with it. What does using ESP IDF or even MicroPython add here?
• MicroPython does add that it becomes trivial to talk to JMRI via a JSON client/server, but that’s not exactly hard from C either, just a bit more clunky. One of the original demo suggestions was to split both.
• One does wonder why Swift or GoLang is not more popular on these. They would be good fits. Swift is probably too Apple centric. There’s a TinyGo.

There is one obvious downside to using an ESP32-CAM to do a grade crossing module, and that’s the location of components. The camera is attached to the ESP32 with a short ribbon (either 1 cm or the 10-ish cm one). This cannot be much longer. And mounting location would require a good view of the track that is to be detected. For example directly on the ceiling, or maybe 1-2 meters above. Track level would be possible but would probably be hard. Perspective/distance means that scale/precision won’t be the same in different places of the camera view. A direct view of the track is needed. That precludes having tunnels or bridges in the way, as well as potentially operators.

The connections for the LEDs and servos could be longer, using twisted wire pairs it would not be unreasonable to have 2-4 meters or more.

Another option is to use more than one module, for example an ESP32-CAM can be mounted on the ceiling, communicating to another Arduino next to the crossing with a simple RS485/RS232 link. In that case, a much longer distance can be achieved.