Hey folks! Here are the bits:

Monorepo:

I have reset the old original Mugsy dev branch to a clean state and started building out the monorepo. It currently just contains the main branch of Operator.

You can find it here: https://github.com/margyle/MugsyDev

One thing you may have noticed, is that the last time we discussed the DECAF architecture way back when, it was being built with FastAPI. I swapped this to Typescript and Express quite a long time ago but I’m not sure if I ever discussed it in an update. This was a simple and pragmatic decision. I code almost exclusively in Typescript at the day job, so I am way more efficient with it as compared to Python. This extends to architecting solutions, tests, configs and everything else that comes along with having it as my daily driver.

I also really like the dev experience and the library ecosystem, so it was a no brainer when I made the call.

Python is still the right choice when it comes to direct GPIO manipulation, so it will always be a significant part of Mugsy’s codebase, and Operator will continue to be a Python and FastAPI application.

I have also updated the outdated DECAF readme on the Org site to reflect this info.

I will continue building out the monorepo, while keeping active dev on the Org page. Once the monorepo is fully fleshed out, with all the individual pipelines running correctly, I will add it to the Org page. Anything that is not directly related to one of Mugsy’s three primary applications will still live in its own repo.

Mech Control Command Bug

While testing the brew control service, I discovered a bug in how Cone move commands are being processed. Here are the symptoms:

• First set of received move commands run without issue.

• For any subsequent sets of move commands, the first move is always ignored.

So if you send Mech Control four moves, the cone will only make three. If you send one move command, it won’t move at all.

I’m currently working on debugging the issue, but no closer to a fix from when I discovered it. I’m going to time box it and if I’m unable to resolve it in that time, I will probably just refactor this section of the Mech Control code. The fact that it isn’t a quick and obvious fix is a sign that it should probably be simplified. Feel free to take a poke at if you have some thoughts on it. The code is the Microcontroller directory in the Operator repo.

Other Bits:

• Grind by weight has been tested and is working well. Will be pushed up within the next few days.

• Pushed assorted updates to Operator, and some additional improvements to the RFID service.

• I have not pushed the initial DECAF setup, think I will have time to do this on Tuesday or Wednesday.

Ok, that is all for right now. I will push an update once I resolve the bug. Should be Tuesday. Thanks!