Update

Hey folks, here are the bits:

Operator: I’ve started pushing updated code to the dev branch. Updates include:

  • Two new services for accessing the cone and platform scales. The services support single readings for current weight, and streaming continual readings. It also includes the associated endpoints and support functions.

  • Updates to the Operator app entry file, mostly related to logging and overall app structure.

  • A bunch of improvements to the RFID service.

  • Other small odds and ends.

Pour by Weight: The pour by weight functionality is done but I have not pushed the actual service that powers it. I did push up a rough implementation so folks can check it out though. It’s on the pump-weight branch, accessed from a temporary endpoint that accepts the following parameters:

Target weight is in grams. Since a small amount of water will continue to pour after the pump is shutdown, the tolerance is there to help us calibrate the pour overshoot. So in the above example, the service will pour until it reaches 39.5 grams. If the tolerance is set correctly, the final value should be within a couple tenths of a gram from 40g.

I’ve been testing a lot today, and .5 has been pretty much on the nose for the test rig setup.

There is currently no client accessing the real time data produced by the pour by weight functionality. So to be able to kind of display it, I set the current weight value to be written to the app logs. Then I just tailed the pm2 logs from a terminal on the iPad while placing it behind the mug. This is a very rough demonstration, apologies if details are hard to read. It will make a lot more sense when the front end is connected!

In this is example, the weight parameter was 40 and the final weight was 39.4. I believe tolerance was set to 1.0, so a lower value would have resulted in a closer final weight.

Please note that if you’re testing out the demo, you will not receive a 200 OK response until the pour completes, as the demo does not currently use the actual service.

Other Bits:

  • DECAF and Operator work is blending together a lot this week as I continue to finish up the overall system setup. I have finished a ton of tasks over the last several days and code updates will continue throughout this week. But I can’t say that Operator is done yet.

  • I have been refactoring the cone mech communications service. This is the service that sends cone moves over serial to the cone mech. It was originally not part of Operator, but it now makes much more sense for it to live as a long running service accessed by Operator. This will be wrapped shortly and once done, I can sign off on Operator’s brew service, which orchestrates everything.

  • I need to work on Docs. Badly. There is a ton to detail but I just don’t have the bandwidth. I’m going to hold off until after DECAF updates are being pushed to the repos. DECAF code will definitely start being pushed this week, so best bet to start seeing improved docs is early next week.

  • The Github setup should really be a monorepo that includes Operator, DECAF and the frontend. It will simplify a lot of things while only introducing some minor overhead. Supporting repos like the Design files repo will still be separate. No specific ETA on this yet, but it will be sooner than later, and likely by the end of the week.

  • If you are playing with Operator, the apps are currently living in the home dir. In prod, all Mugsy apps will live in /opt. This will be handled when I set up the monorepo.

Ok, that is all for right now. I will have a quick check-in update later this week, with a full update going out on Sunday.

Cheers!

MComment