I do like ROS. I have implemented very little on it, though. I just use it for message passing with Tractobot02. I used the joystick node for Tractobot00 but wrote my own joystick node this time. (It publishes data that’s easily digested by the Arduino that runs the steering and transmission.) I want to start integrating IMU, GPS, EKF, etc. and use ROS mapping tools.
APM’s poor handling of many waypoints was one of the reasons I wrote my own Python script for Tractobot01. Although I expect to get back to more waypoint-oriented operation eventually, it is wonderful to be able to code the implement raise/drop as a function of the position, speed, and latency of the implement, all referencing the headland line. And it’s handy to be able to say “Turn around and do the next pass 15’ offset from the last.”
I am definitely interested in supporting a F/OSS solution that moves APM components into ROS as Earle Robotics started to do. I don’t want servo control. I don’t want MAVLINK. I want a node that subscribes to on-course heading, cross-track distance, and IMU, does its fusion/EKF magic, then publishes steering commands. I’ll do the rest.
I expect that I will eventually have to learn about “fusion/EKF magic” so that I can write the code myself.
I’ll have a lot more to say once I get Tractobot02 on automatic guidance. It has vastly finer steering control than my first two projects. I’m excited to see what difference that makes with my dumb 10Hz GPS-only guidance system. If it performs well, I can delay diving into IMU code for a little longer. Also, I might try some basic fusion using my IMU Brick v2.0. It is constantly self-calibrating and returns easily-digested pose information at a high rate.
I can see that Emlid and Earle want people to buy their hardware in order to use APM. But I get the feeling that there are more than a couple of us who want to be able to cobble together our own systems and do things way beyond APM’s scope.