Electronics

As I was putting together the Rover v2, there were quite a few lessons along the way, mostly about hardware. I’ll capture them here for posterity. Handling Power Since I have two motors for driving and another for the LIDAR, I had to use two L298N modules, with different input voltages. I already had a voltage booster for the drive motors, getting 7.4v from the LiPo and boosting it to 14v (12v for motors + 2v for the module). I thought I could simply plug in a direct line from the LiPo for the other module, since the LIDAR motor is 6v. In practice this proved to be unreliable. Without a booster, there was a lot of variability in the current and it caused stalling issues with the motor. Once I added a secondary boost to 8v, it started humming along as expected. ...

Now that the Rover v2 base is working and driving well, I am turning my attention to the new LIDAR module. After reconsidering the previous GT2 pulley based design, I decided to redesign it completely on the new Rover base, using a gear based approach. Reasoning behind using a geared drive is fairly simple: Pulley and timing belt approach didn’t necessarily create a smooth drive mechanism like I had imagined. It also takes up a lot of space and it’s a nightmare to calculate for. Finally, printing GT2 pulleys doesn’t generate very clean results on the 3D printer, which in turn contributes to lack of smoothness. ...

Before jumping to the PID implementation and eventually autonomous driving, I wanted to make sure that the Rover v2 could drive and turn with stability. I could have done a simple keyboard implementation but I really wanted to integrate an old Xbox controller I had lying around. What I have seems to be an Xbox One controller and it connected to my Mac over Bluetooth with no issues. After some research, I found out that pygame is actually the best way to work with these game pads. ...

I spent a bit of time today improving the data delivery protocol I have been using with the XBees. I noticed during various tests that it wasn’t very robust, and it also required the devices to be powered on in a specific order. So I have been meaning to improve this for a while. Core problem was that the whole setup depended on reading a specific length of bytes with every iteration. If things got out of sync (either due to data corruption, or because the Rover came online before the controller node), then it simply didn’t work and started ignoring messages (since the first control byte could not match). ...

I made some solid progress on the v2 design of the rover during last week and finally assembled an initial test version last night. The difference is incredible. Even with no PID implementation, it drives in an almost perfect straight line. I believe the added weight of the motors and bearings help, but the real star are the new encoded motors. I found a couple of cheap 12V brushed motors with magnetic encoders on Amazon and designed a custom chassis around them in Fusion 360. Now that I understand the concepts behind Fusion better, I was able to make very quick progress on the design. I kept it as large as possible, within the limitations of the printer bed. ...