Our longest-term, most broad vision for FarmBot is that it operates much like a home-appliance, for example a washing machine.
- Reliable - Doesn’t require much ongoing maintenance to keep the system functioning.
- Easy - Anyone can learn to use it with little effort. Doesn’t require a technical skill such as programming.
- Automated - Intelligently takes care of everything better than you could. Uses a combination of existing data (eg: how to grow a crop) and real-time data (eg: how wet the soil is).
Then where FarmBot differs from a home appliance (which usually has a very limited set of options) is in its customizability.
- If you don’t want to use the built-in “presets”, you can dive in and adjust anything and everything.
- You grow what you want, how you want. We don’t impose limitations on timing, quantities, spacing, inputs, methodologies, seed types, order of operations, etc.
- The software and hardware is generalized enough so you can easily adapt it to new use cases, methods, crops, environments, etc.
Strategies
Roughly, I think, there are two ways to build the product described above.
Strategy 1: Start from the appliance end of the spectrum (limited set of built-in options) and then add more options over time, and eventually full customization capabilities.
Years ago when we started building, we could have first allowed users to choose from a small set of crops (say, 20) to add to their map in pre-defined locations. Built-in sequences and regimens and events (or some other control paradigms) could have been automatically scheduled for every plant in a behind-the-scenes manner. The bot could have then taken care of those plants according to the built-in methods without any other setup required on the user’s part. Sounds great, right? Yes, but only if your needs aligned well with the limited set of built-in options.
If you wanted to plant a different crop, you would have needed to ask us to add it to the system for you and/or make a way for you to add custom crops. If you wanted to grow something with a different method, we would need to add that different method as a new built-in option, or again, build in ways for you to customize as you please (sequence editor, regimen editor, custom event scheduling, etc). Until the full-customization options were built, we would be getting requests every day, for us to add a built-in option for every user’s unique desires. You can see how that would have been a huge time suck and completely unsustainable. And none of those presets would be laying the foundation for future features - they would be a distraction from the end-solution.
Many products are built this way though, and oftentimes it is a great method. For example, a washing machine doesn’t need a high degree of customizability because there is a very limited number of parameters that can be changed anyways. A decent set of built-in presets often does encompass almost all user needs, and there is limited reason to offer more customizability. However, whenever the built-in presets do come up short, that often leaves users wanting more out of their product.
Compare washing clothes to growing your own food. There are maybe 10 types of clothes out there, but thousands of types of crops. There is hot/warm/cold water for washing, but practically infinite combinations soil type, weather conditions, and crop needs that can combine to determine the best amount of water to administer, and when. Etc.
It would seem then that offering a limited set of inflexible built-in options in the beginning would not have been a good strategy for FarmBot. Nobody would have been happy with our presets because there are simply too many parameters at play. Every day we would receive email requests and complaints demanding we add a built-in preset for crop X, or method Y. It would illuminate very quickly that flexible tools are key in the context of growing food.
And as a side, FarmBot, from a philosophical standpoint, has never wanted to impose any kind of growing methods or limitations on users. FarmBot is not a grow-broccoli-my-way-or-the-high-way kind of platform, nor should it be. That would not align with the concept of owning your food. FarmBot is much more about giving tools and knowledge to everyday people.
So, strategy 2:
Strategy 2: Start from the customizable end of the spectrum
The strategy we have been following pretty much from the start is to build tools that give users the most flexibility in configuring their bot. From the start we have had the sequence editor, farm designer, OpenFarm, and the event scheduler, allowing for very versatile operation of the machine.
However, without built-in presets, this strategy has come at the cost of requiring users to take time to learn the system and oftentimes perform tedious setup in the app. This is well understood by our team, and the main tradeoff we have made compared to strategy 1. Our current users though are by-and-large early adopter type people who are not only wanting, but sometimes demanding this flexibility so they can set up FarmBot how they want. And almost everyone has a different idea of how to set up their bot the best, which is again why a flexible tool strategy is better in this context.
While we do aim to reach the average-joe consumer eventually, we recognize that that’s not the arc that new technology takes, and we won’t get there with our technology or average customer for a few more years.
This all being said, strategy 2 does leave our customers always wanting more tools (rather than more built-in presets in strategy 1). And this is where we put most of our time and effort. The reality though is that tools take much longer to build than presets. A tool needs to be carefully planned and crafted. It must balance flexibility with ease of use. It must fit into a larger system of control paradigms. It needs to provide power users what they want, while protecting novice users from bad or easy-to-make mistakes.
With some recent milestones hit (sequence variables and filter-based groups), we’ve removed some of the most tedious aspects of the app experience. There is always work left to do though, which leads me to what all this backstory is getting at:
Roadmap
As mentioned previously, our project board is publicly available as well as the open issues in our GitHub repositories. This shows the features we are working on and have planned, which offers a glimpse as to what the app might be like going forward.
What you might not see though is that many of the open issues are stepping stones towards even farther ahead ideas. For example, we plan to build support for sequence variables of different types (eg: time for dosing water). That - in itself - will be a big undertaking. But then it paves the way towards watering information coming from OpenFarm and being dynamically loaded into a sequence. And that, paves the way towards an intermediary algorithm to adjust the water dose in real-time based on other data sources (weather, soil measurement, etc). And that, combined with plant growth analytics would allow for the training of an AI system.
With the way we’ve been building out features (strategy 2), everything sort of builds on itself. But we can’t just “jump ahead” a few steps. And the example above is just one of many dozens of spires and flying buttresses that are being built brick by brick to form the FarmBot cathedral. If we focus too much one one thing, people begin complaining the other things aren’t getting enough attention. It’s tough with a small team!
Anyways, I encourage everyone who is interested to look through our project board and if something in particular piques your interest, please leave a comment with your ideas or let us know it is important to you. Also feel free to open up new issues with your ideas, or write about them here on the forum. That’s the feedback that helps us steer.
There are also dozens of issues marked Good First Issue and Low Hanging Fruit which are great places to get started if you would like to contribute.
For the next few months you can expect us to spend most of our time on the following:
- MARK AS variable support and custom write-in options (in progress now)
- “Random Jitter” movements (immediate next feature)
- Working down technical debt and increasing test coverage, particularly in FarmBot OS (ongoing)
- Calibration and homing improvements in the firmware (in progress now)
- Improved support for our latest electronics boards and the Trinamic TMC2130 stepper drivers (ongoing)
- Minor UI/UX improvements (ongoing)
- Other issues tagged
High Priorityon our project board (exact issues subject to change)
After that we’ll have a discussion as to which major feature should be built out next. The decision will be informed by customer feedback, analytics of how FarmBots are being used, where we want to be at certain points in the future, what we think the market wants, the makeup of our customer base, market conditions, etc.