The base plate, the top plate, and the wheels were made using the lowrider. Because the power distribution takes up so much space, I plan to create another level, maybe out of 1/4-inch or thinner stock, that sits between these two plates and move all the power parts to that. Less likely someone will touch something they shouldn’t.
@jeffeb3, It’s running ROS kinetic on an RPI4 (found a prebuilt image for it). The RPI connects to the arduino which is running rosserial and using an adafruit motor controller for the two motors. I repurposed motors that run at 20 rpm so I had to make the wheels large. The motors have encoders to produce the odom, but I haven’t calibrated it yet. I have ros running on a linux VM that does all the heavy processing for SLAM. The RPI basically just processes the odom messages from the arduino and transmits the laser depth scan from the Kinect to the linux VM.
I based it all off of this:
He used different motor/wheels so I need to modify the arduino code accordingly to get the odom correct… as well all the other stuff for rviz. I’m literally learning all of this as I go so if I sound knowledgeable about it, trust me, I’m not
Haha. That is awesome. ROS has a steep learning curve, but it sounds like you are making good progress. I work with all these tools at my day job. It would be great to have a platform at home I could use to map my house. If you have questions, let me know. I may not know the answer, ROS is a huge ecosystem.
It does seem that way, but I’m not sure there is any real alternative that I could reasonably use. The fact that I can get SLAM done in a matter of minutes alone makes worthwhile any investment in time learning it. The possibility of me developing my own SLAM routine is zero… its not where I want to spend my time and energy. That and if my twins want to get into robotics, it seems that ROS is what they will be dealing with in school.
So right now I’m stuck with a robot that moves forward and backwards but left and right are reversed in rviz. I used an android app to do the twist commands and when I push the joystick to the left, it turns right (when looking from behind) and vice versa. I suspect that’s not correct, but there isn’t any real documentation I can find on what it is supposed to do. I think I need to swap my motor connections and change their power polarities to get it sorted. I had rewired a lot of things trying to troubleshoot what turned out to be a bad wiring diagram on the author’s github repo and maybe I have them wired in reverse.
That’s what I plan to do… swap the motor cables and swap +/- (so forward is still forward, etc.). For some reason, I can’t get teleop twist to run properly and am stuck using the joystick app. So I hope pushing left on joystick in the app sends a twist command instructing the robot to turn counter-clockwise. I think I can use rostopic to verify what is being sent. If I understand it correctly (and based on what you said), I should see a positive z value in the angular section of the command when I tell it to turn left.
I think if I can get the robot to move in accordance with the twist commands, then the encoders should be easy to sort out.
Switching the motors and swapping the polarities got everything moving the in the proper direction. Then switching the a/b channels of the encoders fixed rviz. I had lots of problems with getting the change in rotation in rvis to match that of what was happening in reality, but I then discovered the source code I was changing to update the wheelbase was not in the catkin_ws directory, but elsewhere… so once I updated the correct copy, things matched better (not perfect by any stretch, but much better).
Unfortunately, I think I have to come up with a solution for different wheels. Though I didn’t expect the odom to be perfect, I noticed that one wheel likes to slip. My home-made wheels are really thin with a rubber bungie cord material as a tread… it picks up dirt and then doesn’t get much traction. I might be able to play with the acceleration but in the long term, I think new wheels will be needed. It’s just not easy to find 10-inch wheels that I can mate to a motor with a 8 mm shaft. I use a flange to adapt to the flat surface of the plywood wheel… but I haven’t yet found a good cheap wheel with a flat mating surface.
HF has pneumatic wheels that might work, but I was hoping for something lighter and solid vs air-filled. They are cheap enough to give a try though ($7 each). I’ll have to cut out a hub that adapts the bolt pattern of the wheel to that of the motor flange and modify my base plate since the wheels are much wider, but its doable. One of my goals will be to eventually belt drive the wheel to remove all the weight off the motor.
In the meantime, I’m going to try to calibrate the odom better with the current wheel setup. If I understand the process correctly, I should send a /cmd_vel for some amount and monitor the /odom response from the robot. I then determine how much the robot actually moved, compare it to the odom, and then make adjustments as needed to get things correct. The author used +2.5% fudge for linear motion and a 7.8% fudge for angular. I need to reset those to 0% and then do the test.
I was thinking just take the tire part off of a kids bike wheel, and put it on the outside of the existing (or new) wooden wheels. The tire part, not the tube. I was thinking that even a road tire would have enough texture to hold up against some dirt, and still be sticky enough.
Got it. The bungie cord material is pretty sticky as it is… it’s rubber strap type, not the woven material. It’s just too sticky because it picks up the dirt… two dogs and two kids… I think I’ll try mopping the floor and cleaning the wheels to see how it goes But it wouldn’t be hard to try a treaded bicycle wheel material if that doesn’t work out.
Lol… I’m already paranoid I’m going to burn down the house from something going wrong while the batteries are being charged… then throw water from mopping into the mix???
I got most everything sorted out when it came to calibrating the movement… so a success!.. but I think the whole thing is too “shaky”. I just used some 1/4-inch bolts and couplers I had on hand from another project but I can’t get it to remain tight enough to really steady the top plate. Therefore, the kinect wobbles around some and it throws off the mapping… especially when the wheel slips some. The square shape is a bit of a problem as well since I’ve snagged on a few things driving it around.
So my plan is to rebuild it using a 18-inch round base with wheels I got from harbor freight, supported by bearings so I can remove the weight off the motor’s bearings/gears. I’m thinking of using segments of 2-inch PVC pipe and threaded couplers to connect the various levels together as I think it will be more rigid than the 1/4-inch bolts. I want to be be able to disassembly things, so I don’t want to just brace and glue everything together.
I’m looking at alternatives to gmapping as well… looks like rtab-map might be something to consider.
Yeah, was trying to avoid the round look, but it actually works better for my ultimate goal. I always dreamed of making a robot named Oscar with an outer shell that’s just a galvanized trash-can. Now I can.
Yes, and yes