I have found that Farmbot is VERY dependent on the internet connection.
Has anyone else noticed that when a tool is changed, if you query if it is detected, it will fail unless there is a delay inserted into the sequences? I think FB does not keep a local state and is completely dependent on the internet version of its state.
As a workaround I have created a ‘Dismount tool - SAFELY’ sequence. This inserts a 5 second delay after executing the dismount command. I have done similar things for all of the mount commands too which seems to make the system repeatable.
Has anyone else noticed this and found a better way?
I would prefer it if the architecture was different, as in FB would not be dependent on the internet but supplemented by it.
I somewhat agree, though, with persisted databases ( which Farmbot uses ) distributed on device and on back-end internet-connected servers, and with no (smart) caching, there’ll always be sync-points needed.
edit
More accurately, there are over a dozen SQLite3
databases, each partially replicated between device and backend machines.
Thanks for the info.
If this is true, why is it that a dismount followed by a check to see if the tool has dismounted fails, unless I insert a significant delay between the dismount command and the check command? This indicates that the query has to go to the internet hence the delay.
I have been expanding the sequences with things like dismount safely.
This only works with the significant delays inserted into the code.
Also, why does the web page store what tool is loaded in the tool head, but it is not possible to query what tool is loaded?
(I don’t intend to give you a hard time - Far from it - I am just grateful to talk to someone who understands and responds). I have written to FB and get no responses.
Hi @mvillion
The Farmbot device does keep the mounted tool id handy ( in the Device asset db ) e.g. use the IEx console on the bot to see it:
iex(farmbot@farmbot-0000000058098dc9.local)17> FarmbotOS.Asset.device :mounted_tool_id
4822
iex(farmbot@farmbot-0000000058098dc9.local)18>
but maybe the Lua sandbox doesn’t have an access method ? We could check the code . . it’s all publicly available.
I might do some tests to investigate this . . I loathe blind waits like this and 5 s seems way generous, even for my bot way down under in Australia 
@mvillion Just following up on this topic . . I’ve checked that Lua code can read the mounted tool id : Yes it can. A change to the Mounted Tool from the Web App takes between 1 < 2s to be updated in the Farmbot device database.
The Tool Verification Sensor is a local Pin Read operation on the Farmduino : < 1s to get a result.
Just curious whether your Dismount Tool - SUB procedure is your code and whether you have tried the FarmBot Inc. created Featured Sequence Dismount Tool to do your tool unmounting ?
Dismount Tool - SUB is the renamed FB dismount tool code.
This is just a wrapper to detect IF a dismount is required, dismount it, wait to ensure it has settled then check to ensure that it happened.
I am interested to create wrappers for the tool type check as that would be really good.
For me, it is annoying that IF the water head is loaded AND a watering sequence is triggered, I have to Dismount the tool and pickup the water head rather than check if water head is already loaded. I now understand it is possible in LUA code to get that variable.
I try to code with safety in mind so each sequence ASSUMES that the previous one may not have completed correctly (eg. dismounting a tool after a watering or other sequence ), so a validation check of status is required prior to execution.
Over time, I would also like to find methods to code in HARD AREAS where the FB is not allowed to go. For example, the corners where there is wood, it should not be able to attempt to plant, and the area underneath the gantry seed trays. Somehow My UTM got stuck under those seed trays the other day and there does not seem a current method of declaring hard areas that preventing failures caused by PEBCAK. At the moment, we rely on the user to not do it rather than helping them prevent failures. Effectively it is like geofencing no-go areas.
2 Likes
@mvillion I ran into the same issue with a raised bed and a path in the middle that I want to exclude parts. What I did now is create a python notebook to delete detected weeds taking into account the movement of the weeding sequence with a small margin. I hope to find some time this week to clean the code from credentials and IPs and make it public.
Red are the weeds I keep, yellow is non-reachable because of movement, blue: outside the inclusion areas, or inside an exclusion area.
To be continued
1 Like
