The current movement of my Farmbot is very basic. A more advanced movement would create a 3D grid, remove points with possible collision, create a path using A* Algorithm and then move without unnecessary z movements or destroying everything. That would be easy Lua code snippet but I’m limited to 3000 letters. that just doesn’t seem reasonable.
1 Like
Hi
I am experimenting using sequenced sequences to get around some of the limitations of the coding environment, setting up a launcher and then several loops to do the heavy lifting. It is not ideal but it is better than nothing but I agree three are some significant limitations in the coding environment.
I tried to code a circle but that was just nasty and there is no ability to set up ‘no go’ zones in 3D space. This can cause collisions with things like the gantry mounted seed tray and other areas.
yes, the whole purpose of my code is to set no-go-areas. splitting the code isn’t that easy. limiting the code length just leads me to never write comments and to use 1 letter variable names.
I am hoping that the FB development team start to recognise some of these programming limitation and start to code them out. I had an issue where I ran out of sequences. I think the limit was 75. The way I like to code is to use a lot of subroutines that do very specific things. This means the sequence can have a meaningful name and you just call that subroutine if you need it.
I have had a look at the LUA documentation and I did not find it that useful. Yes, there was a list of functions but I am interested in a primer so I can get used to the syntax.
For example the LUS code
update_firmware_config({movement_keep_active_z = 1})
I could not find clear instructions to assemble this line of code. I found some other examples and experimented to assemble the syntax.
For FB to really grow, there needs to be better support for coding else the hardware will be limited by the software confines.
I did some gross capacity and limit testing of the Farmbot system back a few years ( not long after Express v1.0 ) and found that a few resource capacity limits (e.g. count of Sequences) were reduced to those where the Raspberry Pi Zero W would remain reasonably performant with a ‘typical’ workload, over a slow network connection to my.farm.bot. The Pi3B based machine was capable of higher capacities.
Sequences in particular can be relatively ‘large’ objects since they each carry the full CeleryScript compilation.
A goal of the architecture seems to be (reasonably) to minimize ‘effort’ to do a Sync operation.
Hmm. Interesting
Firstly, I have not read a whole heap of information about the architecture so my assertions of how it works may be incorrect. I am working from my experience in attempting to get FB to behave. I mean no disrespect to all who have designed and worked on FB over the years. Disregard this post as you see fit.
My expectation was that sequences would turned into local code which was executed locally. That way, you get the high-level language user interface and the low-level code efficiencies. I am surprised that it is actually executing code over the internet. That is not how I would have expected FB to operate - but heyho - it is not my architecture.
It would be great if FB architecture was LESS dependent on the internet, especially for us overseas folks. In my view, the my.farm.bot should be a method of expressing a localised instance rather than part of the code itself. In my architectural design pattern all sequences would be stored and executed locally but updated via the web. This would mean that an internet connection was not required for execution but would be highly desired for maintenance and updates. By this design, you could set up a farm watering schedule that would run forever without an internet connection. I guess it comes from my fail-safe mindset of removing all dependencies unless they are absolutely required. The problem is that a change of this magnitude would require a redesign of the OS code base, as I doubt that it is likely at any time in the near future.
If I was going to architect this operating model, it would not be required to change everything at once. It would be possible to make a few changes and get them embedded into the OS whilst respecting the existing methods and, over time, migrate the various functions to operate in the more stand-alone method.
Working in the UK, I have to insert a 5-second delay between tool changes to ensure that the databases replicate, or else I get code failures. That is not a great experience and sort of indicated a less optimal approach. By my architecture all executions would be using localised database details and when it is possible, to update the my.farm.bot site when possible just as a display output. Yes, there is a downside that the web interface may be out of date or lagging behind the local FB. However, these issues are easily overcome.
I totally respect that I am a newcomer to FB with only a couple of months experience (compared to everyone else who has many years); however, I want FB to succeed in the long run. The hardware was good, apart from my overheating Z-Axis motor that constantly stalls - however, the ‘how to run a farm on FB’ has been less than optimal. At the moment I have a very expensive automated but accurate hose. For FB to become more than a hobby and more valuable to the world, in my view more needs to be done around the operation of automated farm. Changing the OS architecture would be just one of the changes I would recommend.
If anyone cares about who I am and my background, you can find me on LinkedIn. Matthew Villion - National Highways | LinkedIn
My background is computing, coding, electronics, cybersecurity, 3D printing and now Farmboting.
This is almost how ‘it’ works. My clumsy expression may have led you astray. A Sequence object is synched across the Internet as fully compiled CeleryScript, ASCII-coded and then scheduled (when the time is right) straight from the appropriate local Asset database.
But on device boot (from my own digging around in the Elixir code on FBOS) all ‘shared’ databases on the bot device need synching with “the truth” on the Web App backend databases.
After the basic Linux boot, the early Express would be 100% compute-bound for several minutes while getting everything up-to-date ! It’s a shame that current bots have to suffer the meagre limits that the RPi Zero needs. Someone should re-factor things so the RPi4B can be pushed past 8% busy 
I don’t work for FB Inc. but did help with testing in an informal ad-hoc way a while back.
I believe Rory wants Farmbot owners to contribute to the software ecosystem a lot more than they currently do.
The Software engineering team has one Developer member !
This is actual current bot behaviour. A Push Button on the electronics box will trigger a Sequence on my bot while it has no Internet.
Sure . . I guess the choice of solution components looked good 10 years ago (all royalty-free and OSS) but the contemporary landscape seems to offer more supportable and performant choices, Imho.
Yup.
Hi
Thanks for your thoughts,
I do understand the resource limitations, especially within FB.
I do hope that once this new release comes out (3D farming) a focus is placed on performance and usability. My wife, who supported the purchase at the beginning, has lost interest in the project because it has many issues and is not easy to use. After the build, there were no videos or tutorials on how to use it. It was more like a development kit.
In the last three months I have been learning about the system and my goal is to create a tutorial on how to use it. A basic guide on how to plant 5 plants and look after them, step by step guide kind of thing.
I want FB to be successful because being really cool, the success with mean better support for all existing FB users and longer support. etc. Win win for everyone
1 Like
This is good to know. So I have a question then. IF the code is local, why do I need such long pauses between the loading of a tool and the detection thereof.
A mount_tool() followed by an immediate IF statement to test the verification fails. In my world view the mount_tool() should not exit until the appropriate time period has passed for the code to know that things have been updated and that the tool can be detected, else the sequence has to add an extra delay to accommodate. This is what made me think that it must rely on the internet status to be updated as a local update would (should) be immediate.
Where this came about was attempting to code safely. Verify each command has been successfully executed (wherever possible). So a mount_tool() would then run a test to ensure the tool head could be detected and report a fault if it was not. Some of this was me testing for limitation and reliability. This is how I found out that the water head would not load successfully with a mount_tool() command as it is just to ‘perfectly programmed X,Y,Z’ that there is not enough kinetic force to ensure the connection is made. A manual tap and it makes connection - but I should not have to do that. I am going to try stronger magenets to see if the solves that issue.
Happy to delve into this one. I’m curious to compare the timings on my bot relative to yours at the other end of the planet
Can we agree on a short piece of code to test things with ?
I would really like this.
I am wondering if I am conflating two things here. (I always like to check my thinking as it is easy to lose a train of thought).
1 - Sequence detection timings [after mount_Tool() to verification via an IF statement]
2 - Web interface detection timings [after mount_tool() to web update]
Let me run some closer tests and I will report back as it is possible I have co-joined the two issues and drawn incorrect conclusions. I am also wondering if my unreliable UTM connection for the watering head (my favorite tool head) ‘might’ be in the mix here somehow. I know I am seeing something that should not be - just not exactly sure what.
Thread continues here
1 Like