I agree about the endstops, that was one of the first things I added to my unit. I now use the home endstop to set a very accurate reference position, and then move away slightly so that I don’t ever hit the endstop in normal running. See this link https://youtu.be/PqFkj8dMCJU
The home command moves towards the home sensor until it is activated, then it moves away at a slow speed until the sensor becomes inactive, and finally sets the zero point 50 steps away from the sensor.
As has been mentioned before, the vacuum pump needs to be mounted on the Z axis so that the tube is as short as possible. I’ve not tried planting yet so I can’t comment further on that aspect.
The basic movement accuracy is disappointing; due no doubt to many aspects not all of which are under Farmbot’s control. I noticed that having the X motor at the top of the gantry isn’t ideal (but is there for historical reasons), so I’ve moved mine to the bottom where the mechanical forces act on the bottom of the gantry rather than the top, this improved things quite a bit. Also, the amount of cabling causes quite a load for the motors, and the load is maybe uneven when moving due to the cable duct bending etc. You can improve things by increasing the current to the stepper motors; but it’s very difficult to get right and you risk overheating/damaging the driver (which isn’t capable of driving the full capacity of the actual motor anyway).
I noticed on my unit that when the X axis stopped, the gantry (on the side with all the cables) moved a few millimetres when the motors are de-energised. Without a holding current that will always be a problem and lead to cumulative errors. You can opt to have the motors energised all of the time, but a holding current is the ‘normal’ way of solving that problem. Unfortunately the current hardware doesn’t provide that level of control, and the accuracy problems aren’t likely to be solved until the stepper driver is fixed along with reading the encoders (which again is unlikely to be fixed without moving away from the Arduino/AVR).
I doubt whether the unit will survive European weather for more than a couple of years, there’s nothing to stop water and dust ingress into the motors (via the shaft), and corrosion of the contacts (and magnets!). I’ve moved mine into a greenhouse, which stops the rainfall, but it’s probably increased the humidity so I’m not expecting much. I’ll investigate swapping over to IP68 rated stepper motors in due course.
IMO the team are doing all they can and demanding they fix this or that problem I don’t think is very helpful. By all means feed back the problems.
I decided pretty quickly to move on from the Arduino/RAMPs. I work in this field and used (and quickly ditched) Arduino many years ago. The AVR micro was fine in its day, but well past its use by date now. I’ve designed a stepper driver board which attaches to each motor, so that I can remove the motor cabling and endstops from the cable ducts. This allows me to use a stepper driver more suitable for the motor (so I can microstep and set running/holding currents etc.). The micro also supports reading encoders directly, and I get a good match between the step and encoder positioning. Here’s a video of the X/Y movement: https://youtu.be/I_Hr1SED740.
I’m now ready to start planting and watering, but not sure how much confidence I have in the rest of the software stack and/or which features are working or still in the ‘planning’ phase. So I may end up just doing my own thing. Creating and running G code files would be pretty straightforward now that the machine moves reliably. The sequencing/regimens part sounds good but seems like it might be overly complicated, especially if there continue to be unreliable/intermittent connection problems. Seems to me that the Rpi could run a node.js server and do everything locally, just accessed from any browser, no need to involve the ‘cloud’.
YMMV,
Jon