What is new in Farmbot version v1.4?

@Klimbim The co-processor would be dedicated to reading and reporting position feedback from the encoders, which it can do much faster (at a higher sampling rate, some discussion on sampling rate can be found here) than the Arduino itself. This means fewer missed encoder readings, which translates to increased accuracy. The goal is to get reliable, accurate encoder feedback at higher speeds to use for movements, instead of only using encoders for stall detection. Regarding differential signals, you are welcome to research how differential quadrature encoders work, but the basic idea is reducing signal noise.

1 Like

Are there any improvements to cater for belt stretch, such as moving the X axis motors down off the top of the gantry?

I still think you’re missing a trick here, why can’t you decode the encoder in hardware, pretty much all modern micros support encoders directly with their timers. Also, why stick with an almost obsolete 8 bit micro when all of your code is 32 bit or floating point? If you moved to a 32 bit ARM you’d get >10x performance, hardware floating point, hardware encoder support, Ethernet/USB. You’d likely be able to do away with the RPi too if you wanted.

It didn’t take me very long to replicate your Gxx/Fxx protocol in an ARM chip which I temporarily used with my Modbus stepper drivers, although I’ve since moved away from your software and just drive the steppers directly from the RPi. But I’d be willing to help port the Arduino software onto an ARM if you were interested in going that route.

I totally understand the reason you used the Arduino, but going forward I really do think you should consider ditching it in favour of something more suitable for your needs (and more modern too), and doing it sooner rather than later when it gets even more difficult (due to legacy support and a larger code base).

6 Likes

Can someone offer this guy a job at FarmBot, please?

4 Likes

@ Gabriel once again, up to which speeds to you consider the current Arduino system to work flawlessly?

What is the difference between using the encoder at higher speeds than to detect stall? The system behind those two topics is the same, if the encoder detects a stall this must not be connected to the speed?! Of course at higher speeds the current system is lacking samples and therefore can create errors. But higher speed still needs to be defined, see above.

Sorry guys @roryaronson @Gabriel but please, please, please be honest with us and do not try to fool your current very active and motivated community. At the moment I am feeling to be fooled as I think you are trying to argue that the current Arduino system does not work only at higher speeds, but it does not work at lower speeds properly as well!

So you are referring to differential signals instead of single ended ones? Or is this something specific to encoders?

The main idea here is that, as you’ve said, the current system does not have an adequate sampling rate to use the encoders to calculate motor movements at reasonable speeds, which is why the encoders are currently only used to detect stalls. At speeds around 100 steps/sec, enough encoder feedback is read to use the response for positioning. All of this has previously been discussed in the sampling rate discussion linked to above.

We’re not trying to fool anyone, it’s just that I do not find language such as “flawlessly” to be helpful when discussing developing and describing new cutting-edge technologies.

There are different types of encoders that send either differential (A, A’, B, B’) or single-ended (A, B) signals.

I’ll just add some clarification on differential signals.

Some (probably most) encoders have differential signal outputs, for electrical reasons and has nothing whatsoever to do with software. Encoder signals likely have to be wired in parallel with the motor drive wires (as they do with Farmbot along the conduits). The motor drive wires are switching high currents, which induce small electrical signals onto all adjacent wires. The whole point of a differential signal is that this interfering signal is common to both of the signal pairs, and at the receiver the common interference is subtracted (literally), leaving just the desired signal. Whether the encoder output is single ended or differential is only an electrical property, and if differential then the signal should be received by a differential receiver.

Those people with V1.2 kits have hardware which simply does not support the differential encoders. The newer Farmduino correctly interfaces to the encoders, so V1.3 kits and above will have less problems with using the encoder positioning (although this doesn’t address the sampling rate problem).

There is one thing people with V1.2 kits can do to help the encoder signal problem, and that is to connect the screen of the encoder cable to 0V on the RAMPS board. It won’t fix the noise problems, but it might help.

Hopefully @roryaronson will include enough ‘store credit’ for those people with V1.2 kits to at least upgrade to a Farmduino.

3 Likes

Amen to that!

Thanks @Gabriel that was the number I was looking for. Please do not get me wrong, I do not want to offend or accuse you but I am a friend of clear and transparent communication. This is needed when developing such a community project which shall get successful!
If one reads your words about why you jumped to the Farmduino, he/she could understand that you get the last 2% of performance out of that thing. That is wrong and I just wanted you to point that out. With the current Arduino setup the bot can only travel veeeeeery slow which might be not sufficient for some of the farmbotters (for whatever reason…)

I wonder how a noisy signal could be detected in the software? Of course differential signals are less prone to pickup interferences / noise as single ended ones. But is there a way to detect in the software wether the signal line was disturbed? Otherwise this statement to me is not verified…?!

I wonder how a noisy signal could be detected in the software?

It can’t which is the whole problem. The reason differential signals are widely used is because they offer protection against interference. Noise on the encoder signals presents as missed or additional ‘counts’, effectively rendering the position useless. The software currently attempts to make some sanity checks and performs some noise filtering, but in the end there is simply no way for the software to know whether a count is genuine or in error. Much better to have the signal intact in the first place.

The sampling rate (speed) issue is separate, which hasn’t been addressed with the Farmduino. The sampling rate effects both the ability to read the encoders reliably, and also to generate the correct step frequency. There is no reason for the sampling rate to be an issue with modern microcontrollers, so it’s disappointing to see it unresolved in the Farmduino(other than just wanting to stay in the ‘Arduino’ family).

2 Likes

It would be really interesting to get a counter or something when the sanity check fails which could mean noisy signal. I am just searching for evidence which justifies the jump to differential signals - which of course if you can prevent it, do it…

Why was that not addressed with Farmduino? Maybe you don´t know but Gabriel does? It thought this was the major problem with the Arduino layout?! Sad to see as well…

This is exactly the solution we’re implementing in the next Farmduino:

The coprocessor will live alongside the Arduino MCU and communicate with it over SPI. It is an STM32 processor with timers, which, as you mentioned, should make the sampling rate a non-issue. In the future, it is possible we might eliminate the Arduino MCU and shove the whole firmware into the STM32 for simplicity and cost reasons. Though we’ll need to determine if it is worth doing that and sacrificing being in the Arduino family.

The first (current) Farmduino was primarily designed to have a better board layout and connectors that are more optimized for FarmBot rather than 3D printers. This makes setup of the v1.3 electronics much easier, which was a pain point for v1.2 people who had RAMPS. The first Farmduino didn’t significantly improve performance over RAMPS, only the ease of use.

The next Farmduino aims to increase performance through the features mentioned above.

As with the development of any project, we must tackle issues in stages. Even with the next Farmduino, and the ones after that, there will be things to improve. Each iteration will get better (more performant, more reliable, lower cost, smaller size, easier to work with, etc), but we can only improve so much with each version because we have to continue shipping products and releasing new designs frequently.

4 Likes

Thanks for the good response @roryaronson, great to see the future plans for Farmduino. As a user I have different requirements from a supplier/developer, so thanks also for putting things in perspective from your side!

2 Likes

It will also eliminate needs for encoders (and encoder cables, board connectors, less computational power needed, etc…). Trinamic looks like responsive and cooperative company in regards of opensource projects.

I am trying to decide to buy the existing v1.3 kit or wait for the v1.4. Is it known yet what improvements will make it into the 1.4 kit. Seeing that there is only 2/3 months till the 1.4 ships I feel that there should be a good estimation of what upgrades discussed in this thread will make it in the kit. Also is it going to be possible to easily upgraded the 1.3 once these parts are available?

The FarmBot 1.4’s are shipping in July, but the growing season here starts in May.

Is there an upgrade path from the currently available FarmBot 1.3’s to the FarmBot 1.4’s? If so, how much would it cost?

Does the existing FarmBot 1.3 easily support longer beds than what comes with the Genesis?

I want to piggy back on CM843’s comment here. I’m still mulling over jumping to v1.4 even though I literally just purchased the v1.3 upgrade kit. While mulling this over, a part of the upgrade calculus is "What do I do with the old hardware?" One idea I had was to build another Farmbot for less ‘mission’ critical’ farming adventures (spices, succulents, maybe indoor plants in the winter). This will require some level of software support (from myself, from FarmBot, Inc, the FarmBot community, some combination thereof). This ‘recycled/upcycled hardware’ scenario would be a very interesting second tier use case that fits in with FB’s ethos of sustainable farming. Is there a roadmap for software support for legacy hardware? Even if that roadmap is “It’s all open source and on GitHub; go knock yourself out!” I know FarmBot is aware of Microsoft’s legacy issues with Windows and at some point, the software just needs to move on. As Farmbot moves away from general purpose hardware, the associated software will begin to suffer from this legacy support conundrum. Having a communicated plan is much better than not having a plan at all, even if the plan is to ‘let it die’.

The latest software can be installed and used on older hardware by selecting the FarmBot Genesis kit version in the FarmBot OS Configurator hardware dropdown menu.
New versions are added to the menu as they are released, and previous versions remain available for selection for those with a previous kit version.

Excellent. Is this the forever plan? Meaning, when version 3.14 of the hardware is released running a snapdragon processor/Farmduino, my trusty 1.2 version of the hardware running a Pi/RAMPS will still be able to run the latest software available (e.g. version 9.8) assuming it has that piece of abstract hardware (e.g. say a future ‘pause’ button but not say, controlling a new rototiller attachment)?

A post was merged into an existing topic: Farmbot Board used as a CNC Router