Raspberry Pi based motor controller

[salmiac]

Now I don’t know if this a success. But here it goes.

I made a controller for AgOpenGPS with a Raspberry Pi 3. Software is written on Python. Now why an earth someone would do that? It’s just something I had lying around. At least it can be done. There are no custom PCB but too many wires.

I have installed steering wheel motor and wheel angle sensor for 3 tractors and 1 combine.

First I wanted to make hydraulic steering. Hydraulics are just not within my comfort zone. And I thought steering wheel motor is more safe if (when) something goes wrong. And cheaper.

There are no section control implemented.

GitHub repository

Components

• Raspberry Pi 3
• Wheel angle sensor RTY120LVNAA. ±60 degrees
• Adafruit ADS1115 4-Channel ADC
• Adafruit 4-channel I2C-safe Bi-directional Logic Level Converter - BSS138
• BNO085 Absolute Orientation Sensor. Adafruit version is really hard to find anywhere. I used Chinese Aliexpress version. I have doubts on whether it has the same firmware.
• Cytron MD13S PWM Motor controller
• a micro switch
• 4 LED:s (and resistors).
• 12 V cordless drill
• Motor wheel is a wire brush wheel, wires cut off, double sided mounting tape for a little cushion and hockey stick tape for a little grip. Self vulcanizing rubber tape has got a better grip, but it doesn’t last very long.

Control box

Wheel angle sensor installation

Steering wheel motor installation
There are some steering wheel motor designs. Two old 12 V drills and two new (cheapest I could find).

This is the latest desing. It is the most easiest to make, there is only one weld for the handle mount.

This is the first design. It’s not bad. It’s just really time consuming to make.

And one for combine.

This design is too weak.

Cabin
Computer is a used Surface Pro 4. It is actually quite good for this purpose.

[Erik]

Thank you! Exactly what I was looking for!

As a software engineer who has never really done anything with hardware I don’t really understand why we use expensive and complex PCBs for this project instead of handling everything with software on a cheap but powerful solution like a RPi.

If you’d ask me, next step is to decouple the auto-steering logic from the UI in AOG, and run that on the RPi as well, using a laptop/tablet/phone/xxx only as client, sending settings to the RPi.

But most likely my lack of hardware knowledge makes me oversee a few major issues with this idea.

@BrianTee_Admin Could you give your opinion on this?

[salmiac]

I don’t want to encourage You too much. There is still hardware and problems.As Raspberry Pi doesn’t have AD-converter or real hardware PWM. Actually PWM caused bad performance issues, at 20 kHz PWM uses almost all CPU. PWM frequency I use now is 2 kHz which causes annoying whining from the motor.
RaspbianOS is not real-time OS, but neither is Windows.

[Erik]

I understand, what I mean is that I think this is the right direction for AOG

[salmiac]

Yes. Having all processing on one device and only UI on another is one possible direction. I don’t know if RPi 3 can handle it all RPi 4 actually might. With new AgIO, load could be distributed over several inexpensive devices.
Have this discussion already been on some another thread?

[Erik]

Tbh I think a RPi 3 could easily handle the calculations needed to be done for auto-steering. UI rendering would be done on the client device like a phone or tablet.

Another thread I have found: Webbased version

[NorthernFarmer]

I see this RPi project a success, proving the engineering skills of salmiac.

I cannot see many other positive aspects, probably because of my non-existing software skills. I’m actually a bit concerned about many of these variants that experts build. Absolutely fine for their own benefits and nice to see how AOG can be used but I already see so many messages on farming focused forums about all the confusing stuff at this site. Considering RPi versus Nano, the latter would be less expensive, not many have RPi free at home and we still need another higher performance computer.

I’d like to see a clear and simple approach for all farmers who just start to think about auto steer or steer assist and find AgOpenGPS a candidate. I’d still stress that I’m not at all against these variants for individual purposes but the main audience should be farmers that have no SW or HW experience and are after a cheap but capable system.

Continuity is important. If farmers see us changing from one microcomputer to another and from windows to android etc. they start to hesitate. The change to CMPS14 was already somewhat a confusion but at least I have accepted that discontinuity.

Improved circuit boards are welcome and no problem with PCB2 variants like the one from Kaupoi but I think we should try not to confuse farmers with their first choice. The path with a Windows laptop and PCB2 or the Kaupoi PCB (forgive me if I do not mention others that should be on the list) is simple and has existed a long time and still works with the latest AOG releases. It is the safe path and the others are for experts that want to prove their skills or have some very specific needs of their own.

[GoRoNb]

Congrats, very nice work!
I started from the hardware side exactly that way. As you can see in one of my last posts, it’s working in a real-world application as well. But I’m definitely lacking software skills . Maybe we can combine this and also think about a web-based approach?

AgriBerry - hardware draft

For those, who only read the first line: This is no ready-to-use project! I just want to share a first idea of a web-based steering control based on a Raspberry PI as discussed in many different posts before: [grafik] Instigation: World keeps turning and new game-changing software techniques like web-based engineering capture many areas, e.g. here (unfortunately German only). Why not using this for smart farming, too? The hardware is based on my existing PCB design, but much simpler and eve…

[Erik]

You’re overestimating the amount of computing power needed for the auto-steering, it is actually very little. If there is any part of the system that’s using a sizable amount of processing power it’s the rendering of the map + tractor in the GUI, but this would be handled on the laptop/tablet/phone.

To me using an expensive, complex PCB is way harder than installing software on a 40$ RPi, or buying a pre-installed AOG sd-card.

[Erik]

I am afraid a complete rewrite of the source is needed for a web-based version, since the UI code is tightly coupled with most of the logic

[NorthernFarmer]

I at least tried to say that RPi would not be able to handle it all. No doubt it could handle the tasks Arduino is currently doing. You say the GUI is handled by the laptop and I also assumed a laptop would be needed anyway. Now that a laptop is needed, we do not need a powerful pi when a nano can do it all.

PCB2 is not complex. It was already mentioned that a PCB is needed with the RPi too. How do you consider the PCB with the RPi significantly less complex than PCB2 today? It was already mentioned that we need the ADC and the motor/hydraulic drivers, we would need well isolated inputs etc. RPi would not make any difference to the PCB parts.

[GoRoNb]

Full installation of “AOG” on a RPi would be: Copy .iso image to SD card

[NorthernFarmer]

What does full installation mean in this case? No need for a laptop, RPi only with some kind of a HDMI display?

I’m not concerned about SW installation be it Nano, Windows laptop or RPi. The complete system counts.

[GoRoNb]

Exactly. You simply use your phone or tablet with any browser and type in “AgOpen.GPS”

Of course! This is why I made this hat for the RPi.

[salmiac]

My RPi solution doesn’t need custom PCB. There are many little boards. It would be nice and cleaner to mount all those on one PBC. Can you do Arduino based design without PCB? Yes I think so. Again PCB is way cleaner.

What comes to AOG on RPi as a server for web-based UI. Tablet is less expensive than Windows laptop. But is that good enough reason alone for full rewrite of the program?

What I think of, there might be one benefit to keep all autosteering code in RPi, communication delays. Now is that significant? I don’t know. However that design would increase delays on UI side. Now is that significant? I don’t know.

[salmiac]

I have redone my Raspberry Pi based unit.
More details at Github:
Github pi-steer

First I tried to use Raspberry Pi Pico but I had to gave up on that. Breaking problem was USB serial communication. Windows and USB COM ports are real pain. There might be something useful bits of code if anyone is interested - or not:
pico-steer

I have used two units this spring. One with BNO055 IMU and the other with BNO085. BNO055 is kinda usefull for heading but mostly useless for roll.
Most parts are the same as last year. Python code is mostly rewritten.
New for me this year is section control. Actually I have only used one section for implement up and down control. I used pneumatic cylinder to control manual hydraulic lever. It’s a kind of hack but it works… Might be a little dangerous for fingers.

AgOpenGPS pneumatic control for manual hydraulics.

Finally, I don’t encourage anyone to use this kind of setup. It is just something I have done and used.