The ABS plastic levers we printed to replace the factory transaxle levers turned out to be too soft resulting in the levers pivoting on the shaft instead of turning the shaft under a load.
I ended up welding a piece of 3/16 plate steel to the factory levers in order to double the throw distance to match the throw distance of the servo.
The combination of the longer levers and shorter throw of the servo seems to have worked out just about perfect. The first set of linear servos I ordered have a 4 inch throw and the factory levers had a 0.900 inch throw. After a little research and some basic math that we should have started with, we ended up with linear servos that have a 2 inch throw and modified factory levers that now provide 1.8 inches of throw.
If we decide to change the levers for a more professional look the next set of levers will be machined out of aluminum and anodized but for the rest of this season the modified factory levers will be staying.
We temporarily installed the servo bracket, servos, wiring, and electronics over the weekend and managed to cut the front yard!
There is a lot left to do but it was nice to see the machine mowing without a person onboard.
Currently the mower seems to turn too fast and overshoot the turn causing uncut stripes and wide curves where the mower gradually gets back on track. I think this is related to a couple of settings like accel/decel and turning G’s. In addition, the GPS antennas being mounted at the minimum 30cm apart but any suggestions are appreciated.
Once we moved the mower to the backyard we ran into an interesting issue when attempting to upload the program to the flight controller. A quick search of the Internet revealed there is a hardcoded limitation of somewhere around 724 waypoints for the flight controllers not running Linux and around 7000 waypoints for the flight controllers running Linux from the ardupilot posts we looked at. Unsure at the moment of how to overcome the waypoint limitation with the current flight controller I went ahead and ordered a BeagleBone Blue. We will get it installed as soon as it arrives and provide feedback. If anyone has a suggestion for increasing the waypoints for the non-Linux boards particularly the Matek 743-Wing we would like to hear the suggestions.
Hey Jason! Looking good and congrats on the first cut. Quite an achievement!
Can’t help with WP issue, but do have a suggestion. Would strongly recommend that the GPSs get moved to the front and rear of the mower. They don’t have to be aligned along the axis, but the longer “sight radius” will help the FC recognize unwanted yaw sooner than your current placement. Geometry is your friend here. Congrats again!
@Swebre,
Thank you for the recommendation to move the GPS antennas to the front and rear of the mower. It makes complete sense to have the GPS antennas as far apart as possible in order to provide the greatest difference resulting in higher accuracy.
This sounds a lot like we found with the first set of servos and levers.
We will get the antennas moved and give it another go this weekend.
Requesting help understanding what the meaning of “origin” means so we can input the correct values in meters.
Quoted from Ardupilot GPS_POS1_X command description…
“X position of the first GPS antenna in body frame. Positive X is forward of the origin. Use antenna phase centroid location if provided by the manufacturer.”
We assumed origin was the center of the vehicle on the X and Y axis when we input the offsets for the location of the antennas in the current location.
“Origin” should be the location of the IMUs on your autopilot. Recommend its placement as close as possible to a location over the center of the rear axle on your mower for best pivot turn performance.
I’m not sure I’d go with a BeagleBone Blue just to get more waypoints crammed into the machine. There are countless threads around here expressing frustration with it.
You can easily write a script to execute missions in sequence on any H7-based autopilot (and some others, but I’d stick with the H7 processor for the moment).
What are you mowing that’s going to require 7000 waypoints? I should think you’d run out of gas somewhere around the 2,000 mark, depending on the distance between them. That’s only 3 missions of 700 waypoints, which could be scripted to execute consecutively.
@SJohnson,
Thank you for the compliment and thank you for all your help and willingness to share what you have learned along the way in your journey. You saved us a lot of time getting to a working state.
We would not have made it this far without your help, the suggestions from @Swebre, @Yuri_Rage, and the YouTube videos that @ktrussell and others posted that got us interested in taking on a project like this.
This project has inspired my stepson to enroll in a robotics class that starts in the fall. Can’t wait to see what he gets to build in his class.
@Yuri_Rage,
Thank you for the clarification of what is meant by origin.
I value your opinion and I will dig deeper on the BeagleBone Blue before replacing the Matek H743. After reading your response I will likely be leaving the H743 and figuring out how to reduce the number of waypoints or script consecutive missions.
There are several obstacles we need to avoid such as a pond, trees, propane tank, waterstove, outbuildings, and garden.
In MP we ended up drawing the polygon so that the obstacles are excluded requiring more waypoints.
When using the auto WP feature we could see the mower would not enter into areas it did not belong. When using a fence the waypoints looked like the mower would enter areas we did not want it entering. As this way the first test for the mower we did not want to take any chances.
Looking back we should have tested a mission in the open field with MP fences to see what the results were.
Certainly using fences would make creating a mission much easier.
We realize the method we used was probably not the correct way to avoid obstacles but we were eager to see the mower in action and if at all possible we wanted to avoid removing the electronics, servos, etc in order to manually mow the lawn so we did what we had to with the knowledge we had to get the lawn mowed.
As far as running out of gas, when I run the 18hp gas powered John Deere lawn and garden tractor it needs to be filled several times.
The 26hp Kubota diesel holds a bit more fuel and is by far more fuel efficient. I have run it for 8+ hours without filling the tanks.
Well I got a little further into the process of integrating the 2 Ardusimple SimpleRTK2B boards to be used for GPS for Yaw and I hit a (what hopefully is a minor snag). The original GPS unit plugged into GPS1 on the Orange Cube had the Ardusimple radio mounted to the Arduino headers on the board to receive the RTCM3 correction signal directly from my basestation. This worked fine and gave me a GPS: rtk Fixed indication on Mission Planner. Next I went through the installation instructions in the Ardupilot database on installing GPS for Yaw and set all the parameters, did the auto configure, and it seemed like both units are working as planned, except neither one was receiving the RTCM3 correction signal (even the one that had worked before with the radio mounted on the header). Having read many of the exchanges on the blogs, I knew that UART 2 on both boards was probably set by the auto configuration process to a baud rate not compatible with my radio. The radio that delivered RTCM3 signal also did go away after I ran AUTO CONFIG.
As a part of that setup I did set GPS_DRV_OPTIONS=1 to use the external radio
Next I decided changing the baud rate of the radio was beyond my skill level so I changed GPS_AUTO_CONFIG=0 and I used U-Center to change only the baud rate of UART 2 on both boards to 115.200 bps (this is the baud rate the radio is shipped with). Now, I can get the RTCM correction signal to either of the 2 GPS boards, if the radio is plugged into the header on that board. When I use the jumpers to bring the signal to the other board, nothing is ever sent to the other board. Based on the information in the blogs, it looked like the crossover wiring of the 2 boards needed to be reversed (due to a labeling error), which has added to the confusion, but I have tried all combinations and I get nothing. In the end I installed a full duplex crossover, with the wires soldered into the boards. It seems like the radio delivers the correction signal through the headers and the signal gets to the U-Blox F9P but it doesn’t get routed out to the rest of the SimpleRTK2B board over UART2 so it can get to the other board.
I believe on U-Center the format for UART2 was set for RTCM3 on both boards, but I didn’t pay much attention to that since I was only changing the baud rate. Has anyone experienced this issue of getting the correction signal to both GPS boards, while the RTCM3 signal is sent directly from the base station to the Moving Base, and then to the main Rover GPS? It seems to work fine with the radio plugged into either board. Either GPS will indicate RTK Fixed in Mission Planner if the radio is mounted directly to that board. It seems like buying another radio to have them both working, really shouldn’t be necessary.
and noticed in the Hardware Setup section this recommendation…
" * Two Ublox F9 GPSs should be place on the vehicle at least 30cm apart (horizontally)"
My question is does it matter what the layout is for the antennas so long as they are pointing forward and at least 30cm apart?
I’ve been told by folks smarter than me on this that it really doesn’t matter as long as the proper spacing is noted in the parameters. I don’t know enough about internal FC ciphering to question it, but can’t help but think that a longer spacing between the antennas can’t hurt…
Yuri, I know you are more familiar with the parameters than I, but I think that the origin is the center of rotation, which may or may not coincide with the IMU location. The IMU has its own parameters (INS_POSx_X, Y and Z) which define its position, also relative to the same origin (center of rotation). Right or no?
You’re correct. I explained poorly above. My own Cube resides very close to the rotational center, and I mis-spoke.
Origin is the body frame origin, which, for these zero-turn builds, should be the center of the rear axle. Measure all positions from there, including IMU offsets (INS_POS* parameters) and GPS offsets (GPS_POS* parameters).
@swebre, I don’t disagree that maximizing the distance between GPS antennas is good practice. However, the impact of increasing the distance is not likely to be very apparent, as the EKF does a great job of estimating position and orientation via all available sources. You may be able to measure the effect by comparing yaw innovation values in the logs if you’re careful to keep all other variables constant during testing.
The H-RTK F9P helical or survey grade antenna varieties certainly look good (I’d consider using the “base” models with survey grade antennas on a rover), but for the price, you could get a SimpleRTK3B+Heading board from ArduSimple, which is very nice hardware for sure.
Bottom line, I’m not convinced the price tag justifies the “polished” looks…
Well I just wanted to show pictures of my GPS configuration after Yuri and I got it working yesterday. Most of my other mower pictures are on this thread so I decided to put them here.
Here is what the Ardusimple boards looked like when we were done. The system is working fine now with both GPS1 (Moving Base) and GPS2 (Rover) both indicating rtk Fixed, along with giving a correct directional heading.
It consists of 2 Ardusimple RTK2B GPS/GNSS receiver boards (with headers) and one Ardusimple Long Range radio module attached to the Moving Base receiver board (on the headers). It is actually an X-Bee SX radio that Ardusimple has configured for RTCM3 data transmission and is supposed to have a range of 10 to 14 km LOS. I have not tested the range yet and to see how it works in the real world with obstacles in the way at times. So far it has been simple to use and gets the signal from my base station just fine. The only real issue with it so far has been that the radio UART is set for a baud of 115200 which means the UART2 on the Moving Base receiver has to also be set at a baud of 115200. This is not compatible with the automatic baud rate Ardupilot sets for that UART2. After Ardupilot configures things, it take a manual intervention to set the baud rate on UART2 using U-Center. It may be possible to change the radio baud rate by reconfiguring the X-Bee SX radio, but we have to try that out. We never got the crossover wire technique to work in connecting the UART2 of each board together to move the RTCM signal generated by the moving base back over to the Rover GPS. We finally just changed the parameters around and routed the signal through the flight controller.
Here is the picture of the GPS electronics box on my mower after I packaged up the GNSS receivers in the little boxes Ardusimple sells. It does make it look clean but I am not sure it is worth $50 for each little enclosure.
Now all three of my electronics boxes are full so I must be done. I have heard rumors that you are never done, but the good news is I have room for more boxes! I guess I went with this approach because I wanted something on each side to mount the antennas to, to contain the wires, spread out the heat load, and then there was visual cool factor involved. I guess it was just a personal choice.
Indeed looking good! I have one of those enclosures from ArduSimple as well and must agree - not really worth the price. I thought it was weather proof, which would significantly increase its value. But there are no seals, and the gaps are wide enough to let dust and moisture inside. Yours will surely be fine, double enclosed the way it is.
For comparison’s sake, here’s what happens to the best laid plans after a couple of years of over-upgrading and constantly testing new toys:
