Rotary Encoder Troubleshooting

I’ve managed to fry three rotary encoders on the left motor now. The first one was when I discovered the issue. The second one was when I switched the left and right encoders to try and see if the issue was specific the encoder or something else. And the third one was a spare 900CPR encoder I plugged in just to see if it would work.

When I write computer code, I’m pretty cavalier about testing it. If I get an error, I just go back to the code and tweak it. The computer typically doesn’t go up in smoke if I forget a parenthesis or colon.

On the robot lawn mower, however, there are consequences for this kind risk taking. Installing a new encoder in a scenario where I’ve just watched one get fried is, well, pretty stupid. The results are predictable.

Because they’re not particularly cheap, I decided it would be best to sit down and figure out exactly why the encoders keep breaking. To summarize the symptoms:

  1. Only the encoder on the left motor breaks. The encoder on the right motor works fine.
  2. After installing a new encoder on the left motor, it will work fine for a while, but eventually stops working.
  3. When an encoder fails, it will oscillate around the zero point by a few counts. It still outputs data, it’s just really crappy data.

After installing the encoders and building the drive motor assemblies, I bench tested the encoders. I wanted to make sure I caught any issues before I installed them on the mower. They worked great at the time, but I only applied 12V to the motors. They receive 24V the way they’re wired in the robot lawn mower.

So my initial hypothesis was that perhaps the current sent through the motor wires was inducing current in the adjacent encoder wires. Maybe at 12V it’s not enough to matter, but with 24V, it causes an issue. The maximum current rating for the E5 encoders I’m using is 85mA, not much. But if this were the case, you would think the same issue would present itself on the right motor. They’re wired identically, but the right motor works just fine. So that can’t be the problem.

After tracing my wire runs and verifying everything worked, I was at a loss as to what was causing the issue. So I took apart the motor to see if something weird was going on inside.

IMG_5569
Encoder signal sires inside the cap of the motor housing. No wonder I kept frying encoders. The purple wire was to the A input of the encoder.

Well, a nicked signal wire could definitely cause an issue.

The two brass extrusions on the left and right side of the picture are for seating the motor brushes. With all the exposed, energized metal in this area it wouldn’t surprise me if the wire made contact with something and fried the encoder.

I’m guessing I pinched the wire when I installed the cap. It’s pretty tight in there and you kind of have to hammer it into place. You’d have no idea something got pinched until, well, the encoders stopped working.

After replacing the encoder wires and rebuilding the motor, I used the 900CPR encoder to make sure things were working. So far so good. Hopefully I’m done buying rotary encoders for a while.

ZED-F9P Notes

I updated the firmware for my SimpleRTK boards this evening. Below are my notes for the process in case I need to do it again. There was some obscure information I had to hunt down to get things working right, and I’m linking to it here so it will be available in the future after I’ve forgotten.

  1. Download the latest firmware from the u-Blox website. As of this writing, HPG112 appears to be the latest and greatest. Save it to your computer to a place you can get to it.
  2. Open up u-Center, u-Blox’s GNSS evaluation software.
  3. Connect the GNSS module you want to update to your computer via USB cable. Connect to the appropriate COM port within the u-Center software by going to Receiver > Connect.
  4. Within u-Center, go to Tools > Firmware Update. Navigate to the location of the firmware .bin file and check the boxes as shown below.

    firmware update
    The settings I used at the advice of the ArduSimple website.
  5. In the lower left of the Firmware Update Utility window, there should be a green Go button. Click it to update the module.
  6. Repeat this process for the second ZED-F9P module.
  7. I reset the configuration files for both modules to the default provided by ArduSimple. You can find those configuration files on their GitHub page. Download both and save them to a location you can get to. I have the LR xBee radios, so I used their srtk2b_rover_FW_HPG112.txt and srtk2b_base_FW_HPG112.txt files.
  8. To upload a configuration file, go to Tools > Receiver Configuration.
  9. Before you upload the configuration files, it’s not a bad idea to back up the existing ones. Use the Transfer GNSS > File button to create a backup.
  10. To upload a new configuration file, select the appropriate configuration file for either the base or rover module you’re connected to and use the Transfer File > GNSS button.

    loadsave receiver config
    The Receiver Configuration window. Save a back up of your existing configuration, just in case!
  11. I got a warning that said the firmware version of the module didn’t match the configuration file. I took a gamble and ignored this message. Things turned out okay, as of this writing.
  12. Repeat this process for the second module.
  13. Unfortunately, after updating the firmware and the configuration files, the xBee radios weren’t working. I found this thread on the ArduSimple website to be helpful. Basically, after you upload a configuration file, you have to save the configuration. It doesn’t do so automatically.
  14. To save the configuration, you need to go View > Configuration View, and then click on the CFG option in the left panel on the screen.
  15. There should be a radio button labeled Save Curent Configuration. If it’s not selected, select it. Then click Send in the lower left of the window. This will send a save command to the module.
  16. Take the modules outside and test them. I connected both to my laptop so I can toggle between the two in u-Center to make sure the base module reports TIME and the rover module reports 3D/GNSS/FIXED in the black window that has the latitude, longitude, and altitude shown.
  17. If you don’t see TIME on the base, you’re not sending RTCM correction messages to the rover. On the ArduSimple modules, the GPS > XBEE or XBEE > GPS LEDs should blink on both modules if the base reports TIME.
  18. To make sure corrections are being broadcast form the base and received by the rover, I went to View > Messages View and then click UBX > NAV > RELPOSNED. There should be a length in that window that should roughly match the distance between the antennas.

I also discovered that in order to set the survey in or fixed location of the base, you need to go to View > Generation 9 Configuration View and then select the Advanced Configuration option on the left of the screen. Under the CFG-TMODE option you can set the base behavior.

If you want to set fixed coordinates for the base you need to change CFG-TMODE-MODE to E1 – 2 – FIXED and then plug in either the north, east, down (NED) or latitude, longitude, and height (LLH) values for the base location. u-Center requires you do provide it with LLH in 1e-7 degrees, so 12.3456789° is 123456789 in the value field.

Mower Deck Installation

IMG_5459
The prototype lawn mower with the mower deck installed.

I got the mower deck installed this afternoon. I finally have a robot mower! I chose not to install the mower blades for the time being. I figure now is a really bad time to end up in a hospital, and I can still test the motor functionality without them.

I was worried that there wouldn’t be much clearance between the deck and the front swivel casters and that the front motor would interfere with the battery bay. The clearances in these areas were pretty tight in the CAD model and I was expecting some variance in the parts. Everything fit together pretty well though.

One thing didn’t though:

IMG_5450
The bushing that came with the cable gland I used to route the deck motor cables. Not even close to the right size.

I incorrectly sized the cable glands for the mower deck motor cables. I could barley cram both cables through the gland without the bushing. But after some finagling I was able to get it squeezed through there.

I picked the smaller size on purpose thinking it would be tough to get the bushing to seal around two cables. The two wires are 0.18in diameter with the insulation, which means I should have used a 0.375in ID bushing.

But plugging that size cable gland into the CAD model looked pretty ridiculous with lots of empty space in the bushing on both sides of the two cables. So I undersized it, and here we are. Lesson learned: your CAD model can be deceptive when dealing with flexible materials.

IMG_5452
One of the turnbuckles used to attach the rear of the mower deck to the robot.

The turnbuckles worked pretty slick for leveling the mower deck. You could pretty easily get your fingers in there to rotate them and adjust things. Getting the deck mounted though was a two person job. I had to ask Mrs. Mower for help. Once you have one of the rear turnbuckles attached the rest is pretty easy.

Unfortunately, the deck does still sway a little when driving the robot around. Nothing terrible, but not perfect either. I think I will try to make a custom turnbuckle for the front deck attach point. There’s a lot of motion at the joint between the turnbuckle and the linkage.

Now for the hard part: making it autonomous.

The Prototype Robot Lawn Mower

IMG_5418
The prototype robot lawn mower, without the mower deck.

I was able to take the prototype robot lawn mower out for a drive this week. Watching the design drive off the computer screen and into my backyard has been immensely satisfying. Below are my notes from a day spent becoming better acquainted with the robot mower.

Vehicle Handling

Initially I wired the RC receiver straight into the Sabertooth so I could take it out for a drive. I’d forgotten how much smoothing the Ardupilot software adds to the control output. The robot was almost too responsive without it.

But overall, it handled wonderfully. I was almost able to drive up the curb from my street into my yard, but there wasn’t enough traction to get the back wheels up the curb. So far, so good!

However…

IMG_5416
A scenario I hadn’t considered when I designed the robot mower.

After I got the Pixhawk wired up (more on that below) I ran a few autonomous missions and started tuning the steering and throttle PID values. At lower steering turn rates, I noticed the swivel caster wheels sometimes catch on the grass instead of swiveling, and the whole setup actually rotates about the center pin. The scenario in the picture above only occurred once, but I noticed the wheels getting hung up more than once.

When I was putting the robot together, I noticed the casters weren’t fabricated per my print. I had designed them with more offset between the wheel axle and the swivel axis. If this continues to be a problem, I’ll have them remade with a little extra offset so they swivel easier.

Wires

Getting the robot wired correctly was nerve wracking. I made a wiring diagram for the power enclosure and modeled up all the components and connections to make sure they fit, but I skipped this planning step for the Pixhawk enclosure. The amount of wires I had to route to the Pixhawk multiplied quickly:

  1. 5 wires from the drive wheel rotary encoders, a total of 10 for both motors.
  2. 4 Sabertooth control wires.
  3. 4 relay control wires.
  4. 6 wires for the Pixhawk power port.
  5. 2 emergency stop wires.
  6. 2 additional wires to power the servo rail on the Pixhawk.

I wasn’t expecting 23 wires needing to be routed to the Pixhawk enclosure, and making sure I didn’t get something wired incorrectly was nerve wracking.

And ultimately, I did wire something incorrectly. When I first powered the robot on, nothing happened, other than the Mauch BEC getting hot. And that’s never a good sign.

Turns out I had incorrectly wired the servo rail by swapping the + and – wires. Yikes. I eventually discovered the issue and fixed it, but not before learning a lot about the LM2576 voltage regulator I incorrectly thought was the issue.

Wheel Encoders

After I fixed the wiring, everything seemed to work, until I started running autonomous missions and had trouble getting the MAVLink Inspector within Mission Planner to show wheel encoder data. Initially I couldn’t even find the wheel encoder message. But after a few reboots it magically appeared. Not sure why it wasn’t visible from the start.

From the get-go, only the right wheel encoder was working. Below is WENC.Dist0 for the encoder on the left motor and WENC.Dist1 for the encoder on the right motor.

kind of bad encoder
Wheel encoder total distance traveled as measured from the right and left wheel encoders. Note that WENC.Dist1 is 0.

And below is what the graph for the right encoder by itself, WENC.Dist1 versus time, looks like.

bad left encoder
The right encoder odometry data. Having watched the robot move around my backyard, I know this can’t be correct.

So to troubleshoot, I swapped the encoders. The idea is that WENC.Dist0 should look like the graph above and WENC.Dist1 should look like more like the first graph, with values much greater than 10E-6 and gradually increasing. This would isolate the issue to the encoder and not a settings, wiring, or Pixhawk error.

As an aside, having posted that graph I’m now wondering if the negative value means I have the A and B wires swapped. I was driving the robot forward mostly, so I would expect the values to be increasing, not decreasing. Regardless, at least the left encoder is obviously outputting some kind of useful data.

After swapping the encoders…

bad encoder
The WENC.Dist0 and WENC.Dist1 values after swapping the encoders.

Great, now they’re both broken!

I decided to call it quits after this because the sun was going down. I took the robot back into the garage and got the Arduino out to see what it said about the encoder output. Unfortunately it confirmed that the left encoder at a minimum was broken. The Arduino sketch counted pulses and only got up to 1 or 2 regardless of how much the wheel was rotating.

I remembered I had some 900CPR encoders I had purchased a while back and decided to see if I could get them to work with the Pixhawk. So I swapped the 32 CPR encoder with the 900 CPR encoder, and lo and behold, it started to work again.

All I can gather is that I must have fried one or both of the encoders with my wiring shenanigans. But it concerns me that one of the encoders was working at the start of the day and stopped working by the end of the day.

More to come once I get the mower deck assembled and installed. You can find a brief video of the rover doing an autonomous mission in my backyard here.

Assembly

IMG_5301
The chassis of the robot mower with wheels and motors installed.

I finally have all the parts I need to start putting the robot mower together. And for better or worse, my company has furloughed us for the next four weeks. Here’s hoping I get to cut some grass over the next few weeks!

Finishing Touches

Drawing pictures in a CAD program is fun, but when the rubber meets the road and you start fabricating something, you quickly notice some areas that weren’t too well thought out. Lately I’ve been backfilling those issues as we discover them at the shop. Here are some things I’ve tweaked over the past few weeks. Hopefully we’ll have a finished robot lawn mower soon!

Mower Deck to Chassis Interface

When the deck is stationary in my CAD program, chains look like a great way to support it. I can flip the model upside down and they don’t even move! But when the robot lawn mower starts rolling in reality, what keeps the deck from swaying all over the place? Well, if it hangs from chains, the answer is nothing.

IMG_5142
The turnbuckle that will replace the chain used to attach the mower deck to the chassis.

Unfortunately, the chassis weldment and the mower deck weldments are pretty much complete. So whatever fix we come up with has to interface with those features like the chain did. The solution? Turnbuckles! Some really small turnbuckles, to be exact.

The eye on these little guys is 0.26in ID, perfect for the 1/4-20 screw I had planned on using. The length is adjustable from 3.375in to 4.625in long. They’re rated for 36lb, a strangely specific number, but with three of them they should work fine. The mower deck weighs just over 30lb.

Steel Mower Blades

Another issue the shop made me aware of was the mower blades. I don’t remember if I mentioned it or not, but the reason I designed the robot lawn mower out of aluminum was to avoid any compass interference issues. You may recall I ditched the compass a few months ago, but I never went back and changed the design to steel.

The shop thought that aluminum mower blades were a goofy idea. They’re not wrong, but at least I had a reason for making them that way. Kenny Trussell discovered that when the blades spool up to speed, they interact with the earth’s magnetic field in a way that skews your apparent compass heading.

Making them out of aluminum would avoid that issue, as they’d be non-ferrous. But since we’re not using the compass anymore, it seemed like a reasonable change to make. Besides, all the mower blades you see out in the wild are made from steel.

And if there’s one thing I’ve learned working with fabrication guys, if they make a suggestion that doesn’t impact your design significantly and doesn’t cost much, change it. It’s an easy way to show them you value their input, and they’ll do whatever it takes to get your design working now that their finger prints are on not just the physical parts, but the design, too.

A Legit GNSS Antenna Enclosure

On the wheelchair robot, I had the two GNSS modules velcroed to the top of the robot. That doesn’t seem befitting of a robot I’ve spent a year and a few thousand dollars making. So I designed a small 3D printed enclosure for the RTK GNSS antenna and the UBlox M8N module. It sits on top of a small ground plane disk, mounting to the lid of the electronics enclosure.

gnss enclosure
A 3D printed GNSS antenna enclosure. The larger GNSS antenna is for the Ardusimple RTK GNSS module. The smaller one is a UBlox M8N.

Everybody I talk to says you need a really good ground plane for your antennas. That’s what the circular disk is below the enclosure. The screws for the lid of the enclosure are plastic. Hopefully this doesn’t create any reception issues. I also hope that the antennas don’t have to be perfectly concentric with the ground plane. If anybody has experience with ground planes, I’ll take any advice or feedback you can give me!

Mower Deck Discharge Chute

For some reason I had it on the left side of the mower deck. The shop mentioned that most mowers have the discharge chute on the right side of the deck. I don’t want people latching on to minor quirks of my design, so changing it to the right side seemed like a good idea.

Mower Deck Progress

Here’s the progress on the mower deck last time I visited the shop. We’re a few roll formed parts short of a robot lawn mower!

mower deck
The mower deck weldment just before Christmas, 2019.

The Time Flies

Back when I was ordering hardware for the robot lawn mower, I came across a smoking deal on some 5/8-11 X 5.5in long socket head cap screws. I was browsing Grainger’s website and they had a deal for a box of five for $1.92. Hot dog! Those things are $4+ a pop at most other places. I placed an order without thinking twice.

I opened the box up today when I was putting the front caster assembly together and found this newspaper page stuffed inside the box. Talk about a blast from the past. I assume this means these screws sat in that box for almost 12 years before they sold. No wonder they were on sale!

IMG_5088
A newspaper page I found inside my box of five 5/8-11 X 5.5in long socket head cap screws. The reverse of this page was a full page ad for liquor store in New Jersey.

Looking at the picture of those girl scouts got me thinking about how short life is. There’s a good chance those girls are probably out of college by now. I wonder if any of them even remember the Girl Scout Sunday events on March 11, 2007. It was probably a big deal at the time, but 12 years later, I’m sure it’s but a distant memory to most of them.

Seeing this newspaper page was a good reminder to cherish what’s really important in life: family and friends. The Mower Project is a lot of fun, but without good friends and family to share my successes, failures, dreams, and goals, it’s all a very empty exercise.

And beyond that, it’s sobering to look forward and think about what will really matter 12 years from now. Who knows where the mower project will take me? The work I put in here could be a defunct blog 12 years from now. It could be something else, I’m not sure what. But if it comes at the expense of time spent with family and friends, it will surely not have been worth the effort.

This Christmas, I hope you all have a wonderful time with those closest to you, and I hope you make some beautiful memories with your loved ones, on which you’ll look back on 12 years from now and smile. That’s a project worth every minute.

Merry Christmas!

Sub-Assembly

I’ve received a few of the weldments back from the shop. While I wait for them to finish fabricating the mower deck weldment I’ve started to put some components together.

IMG_4701
How I initially had the wheel encoders installed. You can see a little rubber grommet in a hole I drilled in the motor dust cover near the bottom  of the picture.

Back when I installed the wheel encoders on the wheel chair motors, I stupidly drilled a hole through the dust cover on the back of the motor so I could run data wires to the encoder. In hindsight, I should have run them through the little sleeve that the power and brake wires were routed through.

I had to take the brake off to put the encoder on the motor anyway, so there was a perfect amount of space for the encoder wires once the brake wires were removed from the sleeve.

Because you can’t undrill a hole I purchased a pair of cheap gear motors off eBay for $80. I mostly wanted them for the motor dust cover, but it will be nice to have spare parts on hand in case I need them down the road.

I took the aluminum back piece off the motors and removed the two white wires you see in the picture. The hole you see them sticking through was where I routed the data cables for the encoder.

Pro tip for dealing with these motors: There are two Philips head M5x150 screws holding the aluminum back piece to the mounting plate. These screws have lock washers under them. The screws are ridiculously soft and easy to strip the heads on. If you want to remove them so they’re still reusable, it’s best to use an impact driver. It’s extremely easy to strip them using a screwdriver.

I managed to strip the screws on both motors before I drilled them out and discovered this, so heads up to anyone modifying the motors like I am here. I ordered replacements that were socket head cap screws instead, hoping to avoid this issue in the future.

Once you have the aluminum back piece off, you’ll see wires inside like this:

IMG_5002
The inside of the aluminum back piece.

The inside is going to be quite dusty with a lot of little brush particles inside. I blew it out with compressed air after taking this picture.

You can pull the white wires through pretty easily, but I had to bend the black wire terminal so I could get access to the hole to feed the encoder data cables to. I also ended up removing the brushes so I’d have more room to work.

Once you’ve got the white brake wires removed, you can pretty easily push the encoder wires through. The end result looked like this:

IMG_5005
How I should have routed the encoder data cables from the start.

One thing I realized doing this is that it would have been pretty easy to drill holes into the aluminum back piece for screwing the encoder base down. I selected an adhesive backed encoder because I didn’t want to mess with it. But going to the trouble to take it apart like this changes that calculus. If I find myself doing this again, I’ll order an encoder that has clearance holes for mounting screws.

IMG_5009
The completed motor assembly with the Harbor Freight tire.

After I had everything wired up, I tested the encoder to make sure it was working well. Nothing like having to tear down a motor after it’s already on the robot to fix a loose wire.

I also wanted to make sure that running the data cables next to the power supply cables wouldn’t cause any issues. I didn’t find any during the bench test. Fingers crossed none pop up in the field either.

IMG_5085
The front caster assembly. A little bigger than I expected!

I used 5/8-11 screws for all the connections in the front caster assembly. I wanted to standardize on one size so I could buy several of one type of lock nut. Unfortunately the width of a 5/8-11 lock nut is 0.9375in and I don’t have a wrench that size. I also don’t have a hex wrench for the socket head cap screws either. The picture above shows everything hand tightened. I’ll have to go pick up the right tools to get this all put together.

More to come soon!

Innovators in the Autonomous Lawn Mower Realm

As I’ve been working on the mower project, I find myself returning to a few blogs and websites to see how other people are trying to automate lawn mowers. It’s fun seeing different solutions to the problem, and I use their successes and failures to spur my own creativity.

This is a list of innovators that I’m aware of in the autonomous lawn mower realm. If you know of some folks that I haven’t found yet, post a comment and I’ll add them to this list!

MowBotix

These guys had automated a fully autonomous riding lawn mower back in 2017, so I think they win the prize for first large scale autonomous lawn mower. They went silent about a year ago and recently posted on their blog that they’re moving toward a more holistic terrestrial software solution that isn’t just for mowers.

Greenzie

Every once in a while I’ll do a Google search for “autonomous lawn mower” to see what I can find. That was how I found the folks out at Greenzie. They appear to be taking the same approach MowBotix did: start with a riding lawn mower and retrofit it with a suite of electronics and sensors. Their solution looks a lot more robust than MowBotix’s, but also quite a bit more expensive. Their Twitter account is a fun time, lots of cool demonstration videos.

Left Hand Robotics

As far as I can tell, the folks over at Left Hand Robotics started out trying to make an automated snow plow. Based in Longmont, Colorado, I’m sure that’s a very welcome solution. It appears they took their snow plow platform and put a mower deck on the front. Voila! Instant mowing platform.

The downside? It appears these bad boys cost an arm and a leg. Or perhaps just a left hand? I’ll show myself the door. This source says their snow plow solution costs $55,000 and has an annual subscription fee of $4,250. However, for that price I’m sure the system works very well. Their videos are quite impressive.

Deep South Robotics

Robo Robby over at Deep South Robotics has a full up riding mower automated with linear actuators to run the steering arms. With his software and hardware chops it appears to be a very robust solution. I admire his willingness to share his methods along with his successes and failures. The comments on his blog are quite informative. Every time he posts, I learn something new.

Evatech

Well, kind of. Evatech makes a series of radio controled lawn mowers, and BitDog from the ardupilot forums took one and added some special sauce to automate it. I admire the simplicity of this solution. It seems to be quite plug and play. But I’m left wondering why Evatech doesn’t take the leap and automate their platform themselves. Their machines are on the pricy side, but being gas powered are probably pretty reliable.

Kenny Trussell

Kenny was the first person I know of (other than possibly the folks at MowBotix) that used an RTK GPS system on a riding lawn mower. He continues to improve his mower, and I look forward to some updates of his progress soon! Kenny shared a very useful waypoint generation program for creating a mower mission in Mission Planner. If I ever get my mower finished, I will likely be trying it.

The Ardupilot Forum

There are quite a few folks on the Ardupilot forum that are working on their own solutions. I won’t post names here, but a cursory search will bring up several of them.

Mean Green Mowers

autonomous_mower_fmt
Mean Green Mower’s autonomous mower. Great minds think alike?

These guys have partnered with a company called Kobi to build an autonomous robot whose anatomy looks surprisingly familiar. I think the solar panel is a bit over the top though. When your deck motors pull multiple kW’s of power, a 200W solar panel isn’t going to be very helpful in my opinion. But it’s great marketing, especially when your company has “green” in the name.

One thing is for sure, it’s an exciting time to be working on autonomous lawn mowers!

Weldments

I had a chance to drop by the shop yesterday, and things are progressing nicely! The chassis weldment is complete except for a little grinding and cleanup, and the front caster weldment is almost finished. It is very exciting to finally see the autonomous lawn mower jumping off the screen and into reality.

IMG_4910
The tubes for the front caster wheels. All that remains is a little welding!

I spent a lot of time making detail drawings of each part, weldment, and assembly. You can never be too clear or explicit when making something complex. Unfortunately I think the pile of drawings scared off a lot of more than qualified welders and mom and pop fabrication shops.

I’m very thankful I found someone willing to take on the challenge. But even with very detailed drawings, things can still go wrong. For example, below is one of my drawings for the tube shown in the picture above.

Untitled
The miter angle is 55°. Or is it?

That 55° is geometrically correct. But when you’re using a miter saw to make an angle cut on the tube, what angle should you set the saw to? The correct answer is 35°. In this case, my drawing was actually a little misleading, while technically correct. Lesson learned: if you’re dimensioning a miter cut, it’s best to show the angle the should be set to avoid any ambiguity.

Another lesson learned is to always plan for 50% or more material than the design calls for. The tightwad in me ordered exactly what I thought the shop would need with an extra 0.5in on the ends. In hindsight, that’s a recipe for extra trips to the metal yard to get material for the inevitable mistakes caused by my own sloppy drawings.

One other good engineering practice: always collect your old drawings. We went through a few producibility changes over the past few weeks, and when I dropped by the shop yesterday, I noticed a few old drawings floating around. Round those suckers up! At a minimum, mark them void. The last thing I want to do is pay for parts that I can’t even use because I changed the design.

IMG_4913
A side view of the main chassis weldment.

If you spend a fair amount of time in a CAD program working on the same thing for more than a few weeks, you start losing a sense of the scale of things. On the computer screen, this weldment looked pretty substantial, but in real life, it’s actually pretty small. That battery bay is going to be very tight. I really hope I dimensioned it correctly.

IMG_E4912
The main chassis weldment.

Maybe this spring I’ll have something to actually cut grass with!