why it is necessary to use a custom linux distro and kernel build for FBOS? Is this because of real-time constraints?
FarmBot does not have real-time constraints. In our case, we need a build system that is easily customized and can be reproducibly built on any machine, and reliably generate build images that will work for customers without intervention. Back when FarmBot was in its “garage prototype” phase, we did in fact build on top of Raspbian like you are suggesting. The build process was lengthy and hard to reproduce. The performance was dismal (FarmBot Express did not exist yet, but I imagine that would have made things even worse). It was uncommon for a device to operate for more than a few weeks in real-world conditions, for a variety of reasons. We switched to Nerves, which uses BuildRoot under the hood. Memory usage went down, production image sizes went down, SD card corruption became far less common, and the amount of time we needed to waste hunting down build issues went down to nearly 0. It was very different than desktop Linux, but these are the tradeoffs that must be made for embedded systems.
The vast majority of commercial IoT projects are using either Buildroot or Yocto. There is a reason for this and I am unaware of any commercial products that ship software updates to their customers running desktop Linux distros.
If we need to put together our own solution because we can’t rely on the internet then will we also need to build off of this custom Linux system?
If you don’t care about using the web UI at all, and you really just want to use Raspberry Pi OS, the answer is “no”, you do not need to use FarmBot OS at all. You can flash Raspberry Pi OS onto an SD card and then directly talk to the Farmduino via /dev/ttyACM0. It is relatively simple to write a GCode parser- mostly just string manipulation. Any programming language that can split a string into tokens will work. You can even find the old serial port adapter I wrote in Ruby if you are curious how such a script might be written. Some of the GCodes have changed, but they haven’t changed that much. Controlling a FarmBot is just a matter of sending and receiving GCode over a serial line.
FarmBot, from a hardware perspective, is just a raspberry pi plugged into an Arduino-like microcontroller. You could flash Raspberry Pi OS onto your SD Card and then write a script to handle the test from /dev/ttyUSB0. It’s all ASCII based- there is no magic binary protocol to learn. You could even run a cable from the Farmduino to your laptop and control the device from a terminal emulator if you wanted to.
I would imagine that in Elixir we could expose the low-level operations of the FarmBot via a JSON API in a single file that just takes in args and calls the same functions you use now to emit GCode to the Farmduino.
There are a lot of things that seem “easy enough” to do. Unfortunately, adding new developer APIs implies that we will support them for a very long time. If we make the decision to create a new set of RPC APIs, we have essentially doubled the cost of ownership for our RPC system (again, we only have one FBOS maintainer- me). People will begin to write critical systems on top of the new APIs, and we are then in a position where we must support these users or jeopardize system stability. A good example is the Farmware system- we specifically said that it was beta only and could be changed without notice. When the system had scalability problems, or we needed to make changes to the system because of unrelated environmental issues, people would become very disappointed with that, regardless of the fact that we provided numerous disclaimers about the stability.
The API you are suggesting is not impossible, but it does not fit into our long-term roadmap, and creating new developer APIs is not a tax you pay once at the time of development. It requires an extreme amount of forethought and constant maintenance as the system evolves. We learned this the hard way with the Farmware subsystem and won’t repeat that mistake. We simply don’t have the resources to say “yes” to every feature request that is suggested. I hope you can understand that.
If you still wanted to implement the API yourself, the file can be found here. This is the HTTP server that the configurator exposes and it would be a good starting point if you are truly interested in contributing code to FBOS. By all means, do feel free to fork FarmBot OS. That is the beauty of Open Source. I can’t teach you how to write Elixir code (great resource here if you are new to the language), but I’d be happy to answer questions you have about environment setup.
Would that not be an easier way to enable this kind of thing rather than requiring a custom OS build? I guess I was hoping that we could contribute something of use to the community, rather than just go build our own playground.
The best solution would be to add additions to the Lua sandbox. Lua has long term support.
It just seems like it would be ideal if there was also the hacker access point so that we could easily connect and control the bot from our own random scripts without requiring cloud access.
Again, your best bet would be to either fork FBOS to meet your needs or write a script that runs on Raspberry Pi OS and which writes directly to the Farmduino’s serial bus.
Thanks a lot for your help and explanations.
No problem! Happy to answer any questions you have, regardless of which solution you chose moving forward. Please let me know if you need help along the way, either here or via PM. This helps us find places that the developer docs need updating.