Don’t worry, I’ll work some codes out for them too and get you on the right path 
7 Likes
I’ve already been down this road and it’s much more complicated than codes. There’s intercommunication and handshaking between at least three different CAN ids. There’s autotrac itself which seems to be a submodule within the brown box monitor, then there’s the steering control module (SSU), which is in the tractor somewhere. Then there’s of course the receiver itself, and the armrest controller. They all talk back and forth together to steer. I’ve spent quite a few hours tracing the traffic and while I can understand a lot of it, I don’t think it’s really feasible to drive the SSU directly from AOG unless the complete protocol between autotrac and the ssu was figured out. I think it’s far simpler to just unplug the SSU from the steering valve and drive it directly with arduino. Steering angle data is available on the bus (see one of my other posts on that), but I’m not sure if it’s a raw or calibrated value. I’m pretty sure the raw value is on the bus somewhere, probably the tractor bus, not the implement bus, the latter is the only bus I’ve done any analysis of. Also I’m sure the raw enable autosteer button event from the armrest controller should be on on the tractor bus too–it’s certainly not on the implement bus.
I’m not sure how much and for what purposes CNH and Trimble use canbus. The receiver talks to the NAV II controller over RS232 serial using TSIP protocol (see @PotatoFarmer 's post on TSIP). I’ll check my sprayer’s service manual to see what drives the steering valves.
It is certainly refreshing to see that at least one company follows the standards! Kyler Laird down in Indiana has switched all his machines to Agco because they are much easier to drive from his robotics software (just as you’ve discovered). And they are not openly hostile to the idea of turning their tractors into autonomous machines. Many thanks to Brian for introducing me to Kyler. He’s brilliant like Brian.
1 Like
I think I should do a condensed thread on here of TSIP and the joys of Trimble. Time to close down the emlid thread, as there should be more interest on this forum. Plus since I do not think emlid will fully open up ubx or nmea message selection anytime soon its really F9P applicable.
Emlid is a great unit, for base, and for regular AOG users. But F9P is truly the science project machine.
Ive got CAN hardware layer down, its the message protocol layer, timings, responses that are the hard part.
But I still love this CANBUS thread you cant build a pyramid without a good base.
I used to be a read but not comment user on forums for quite awhile. Ive learned a ton from @BrianTee_Admin and @torriem from what they have written on combine forum about GNSS.
3 Likes
Project Two - Steer the Fendt SCR, S4, or Gen6 around the yard
Ok, so this is one for all the Fendt fans. When Fendt sell a steer ready tractor they provide a fully functional steering controller built in ready to go. Then you can use the Fendt branded navigation software/system or use any other 3rd party navigation system to provide the desired curve (or wheel angle degrees) without any problems.
Step One:
Load the Fendt navigation program onto the Arduino Uno, with CAN-BUS shield, with a pot connected to A0, and a switch connected to A1-GND.
Step Two:
Load the “show all CAN messages” program onto a second Arduino UNO with a CAN-BUS shield.
Step Three:
Add the CAN wires so you have a setup like this picture, then watch the first video. All this can be done and tested on the bench before needing a tractor.
Video Fendt CAN Steering Part 1
Step Four
Load the “Filtered F02C Messages” program onto the second Arduino UNO with a CAN-BUS shield. Watch the second video then its time for a test in the Yard.
(upload://2Tqy5bw6nGVYzpBNlX1Y5bN3qr.ino) (3.6 KB)
Video Fendt CAN Steering Part 2
Zipped folder with the 3 test Arduino programs:
Fendt Test Programs.zip (3.5 KB)
10 Likes
…well that’s my weekend sorted!
Brilliant. Hurry up and arrive CAN controllers!!
4 Likes
This has me thinking I should get the other green tractor.
But Deere did such a great job of indoctrinating me at a young age. I still love the Old AR… but its 2021. It looks like fendt is not putting up unneeded barriers to interface.
Is this the same for all AGCO?
Project Two will only work with Fendt. I’ll make a video on how the other systems works and how to steer via CAN (same idea just different messages)
4 Likes
They have arrived and project 1 is working a treat on the bench!! 
724 next…
For me, probably the most exciting topic on here, ever!
3 Likes
I have an MF 7350 READY tractor, is it from the agco group, will these steps be used to make it work? So I order the pieces, also I wanted to know if this could be used instead of the Arduino Uno.
In this post I have images of my valve and connector in the cabin, there I could connect the cables for the canbus?
I only use the Arduino Uno as that is what my program is for (Not ESP32). Start with reading any CAN messages.
The ESP32 has very different I/O pin assignments, and everything is at 3.3v. So it probably won’t work with the CAN shields that are meant for Arduino. Also the CAN libraries would have to be ported to the ESP32 as well. Once you have experience with the UNO setup, you might try the ESP32 in the future. The ESP32 actually has a CAN port built into it, so you only need a transceiver chip. Demo 31: How to use Arduino ESP32 CAN interface.
3 Likes
Its hard to know which embedded system is best.
I like Arduino cause its pretty straight forward to learn. But requires a lot of workarounds for data manipulation. The IDE implementation of C is very sparse command wise.
But this threads about can and uno, lets keep it uno. If you can Due it on Uno, its only a Teensy job to convert it to another platform.
1 Like
2 Likes
The only limitation to the Uno as a CAN platform is that the CAN chipset is completely external (a shield), and the only means of communicating with it from the Uno is via a UART serial link, which limits data throughput to around 110kbit/s. CAN networks typically run at 250,000 kbit/s or faster. But if you’re just looking for specific bus messages using a filter (implemented by the CAN chipset itself) and broadcasting a few messages, the UART speed is more than fast enough to do the job. 12 bytes 10 times a second is not very much. If you’re trying to analyze bus traffic more generally, the Uno won’t be sufficient. The Due or Teensy are both excellent for that with their on-board CAN ports and fast USB-native serial output for dumping data. Also the difference in the CAN libraries used for the different devices isn’t huge. I have a bunch of code that uses a few #ifdefs to compile on Teensy or Due, and the rest of my code functions the same.
The ones used here are SPI which is way faster than uart isn’t it?
…or do you mean its ability to communicate it back and forth to the PC?
Oh yes you’re correct. I was talking about the communication between the Uno and the CAN shield. Yes it looks like most are SPI, which can do 4 Mbit/s on an Uno (theoretically). As far as dumping data out to a computer for analysis, you are limited by the UART speed on the Uno. Native USB is nice/required when doing that.
I have such a set, it will be ok to start playing with CAN?
1 Like
Build the Project One, and just get it working on the bench to test your set.
Glad someone picked that horrible humour up, haha.
Due Is also the only Arduino that can handle a double floating point number, just for this one reason it is my only choice. But that little teensy 4.0 will win out eventually at 600mhz, rather be waiting on incoming data to process, than waiting for the data to process.
2 Likes
did not work