Phoebe TurtleBot

Once the Roboclaw ROS Node‘s wheel parameters were updated to match the new faster motors, Phoebe went on a mapping run. And the results were terrible! This is not a complete surprise. Based on previous experimentation with this LIDAR module, I’ve seen its output data distorted by motion. It doesn’t take a lot of motion: even a normal human walking pace is enough to cause visible distortion. So now that Phoebe’s motors are ten times faster than before, that extra speed also adds extra distortion.

While this is a problem, it might not be the only problem behind the poor map. I decided to dig into an anomaly I noticed while using RViz to calibrate wheel data against LIDAR data: there’s some movement that can’t be entirely explained by a LIDAR spinning at 240 RPM.

The idea behind this odometry vs. LIDAR plot on RViz is to see if wheel odometry data agrees with LIDAR data. My favorite calibration surface is a door – it is a nice flat surface for LIDAR signal return, and I could swing the door at various angles for testing. In theory, when everything lines up, movement in the calculated odometry would match LIDAR observed behavior, and everything that is static in the real world (like the door) would be static in the plot as well.

In order to tune the base_width parameter, I looked at the position of the door before turning, and position after turning. Adjusting base_width until they line up, indicating odometry matches LIDAR. But during the turn, the door moved relative to the robot.

When Phoebe started turning (represented by red arrow) the door jumped out of position. After Phoebe stopped turning, the door snapped back to position. This means non-moving objects appear to the robot as moving objects, which would confuse any mapping algorithm.

I chased down a few dead ends before realizing the problem is a timing issue: the timestamp on the LIDAR data messages don’t line up with the timestamp on odometry messages. At the moment I don’t have enough data to tell who is at fault, the LIDAR node or the Roboclaw node, just that there is a time difference. Experimentation indicated the timing error is roughly on the order of 100 milliseconds.

Continuing the experiment, I hard-coded a 100ms timestamp delta. This is only a hack which does not address the underlying problem. With this modification, the door still moves around but at least it doesn’t jump out of place as much.

This timing error went unnoticed when Phoebe was crawling extremely slowly. But at Phoebe’s higher speed this timing error could not longer be ignored. Ideally all of the objects on the RViz plot would stay still, but we clearly see nonuniform distortion during motion. There may be room for further improvement, but I don’t expect I’ll ever get to ideal performance with such an inexpensive LIDAR unit. Phoebe may end up just having to go slowly while mapping.

(Cross-posted to NewScrewdriver.com)

The Roboclaw ROS node is responsible for calculating odometry information based on encoder values read from each wheel. In order to translate them into standard ROS units, it needs two parameters:

• ticks_per_meter : To calculate physical distance traversed by each wheel, the code needs to know how many encoder counts it takes for the wheels to travel one meter.
• base_width : To calculate how much the robot has turned, the code needs to know how far apart the two drive wheels are placed.

Both of these values needed updating after upgrading Phoebe to the second chassis. I got impatient with the slow speed of the first draft, so the motor gearboxes were changed out with ones that deliver less torque and precision but much faster top speed. This change of gearing would need a new ticks_per_meter value. And the second chassis is slightly wider than the first, which obviously changes the base_width value. Both of these could be calculated on paper, but that is only a starting point. Real world is always a little different from the theoretical and needs a little adjustment.

The easiest place to start is ticks_per_meter. Phoebe is placed on a flat surface, next to a ruler, and commanded to drive straight forward for a short distance. During this activity, the odometry data is monitored with rostopic echo /odom to see how far Phoebe thinks it has actually gone. If the ruler said Phoebe didn’t go as far as it thought it did, increase ticks_per_meter. If Phoebe overshot, reduce that value.

Once wheel travel was verified with a ruler, LIDAR is added to the picture. RViz is commanded to plot odometry data and LIDAR data together, and Phoebe is placed facing a door serving as a large flat surface for reference. The red arrow represents where Phoebe thinks it is, facing the horizontal line representing its LIDAR’s view of the door.

Then Phoebe was commanded to move backwards 0.5m. If odometry data agrees with LIDAR data, the movement away from door and the door’s distance from robot would match, canceling each other out so the line representing the door would not move on the RViz plot. It looks like the ruler calibration worked out well, as we’re only a tiny bit off.

Once distance was verified, we move on to rotation. Command Phoebe to make a 90 degree turn clockwise and see if LIDAR plot agrees. Again, ideally the turn calculated from odometry would agree with the LIDAR plot, leaving the door in roughly the same place on the RViz plot. Ideally.

In this case, however, the door shows a minor clockwise rotation. This change of position in LIDAR data indicates Phoebe didn’t turn as far as it thought it did. To adjust parameters so Phoebe’s calculations better align with actual motion, we can increase the base_widthparameter. And if the door had rotated the other way (Phoebe turned further than it thought it did) the parameter should be decreased.

(Cross-posted to NewScrewdriver.com)

Phoebe was built to roam my house, but the first draft chassis was unable to do so effectively due to a few problems that the second chassis aimed to solve. The first one was ground clearance, which was solved by raising the main chassis and sloping the bottom of the electronics tray. Sloping that leading edge gives Phoebe a better approach angle for smoothly transitioning between floor surfaces.

The second major problem was the LIDAR scanner’s height: it was too high to see the legs of an office chair. Hence the other major goal of the second chassis was to lower the LIDAR mounting point and hopefully bring an office chair’s legs into plane of view.

Placing the newly rebuilt Phoebe next to the chair looks promising at first glance. Unlike the taller first chassis, the LIDAR’s horizontal plane of sight is now low enough it should be able to see the legs.

The proof is in the occupancy grid, and the RViz plot shows that Phoebe can now see the legs of the chair blocking its way.

It’s not a very solid detection, though. Something about the surface texture and/or angle of the plastic results in a weak laser return.  And there’s the risk of a leg going undetected when if approached from the end, as the dark sloped rounded end of the chair leg is nearly invisible to LIDAR.

But it’s a huge improvement from before, where the LIDAR was too high to see any part of the starfish pattern. It’s good enough for us to proceed with the next task: integrate Phoebe’s new faster wheel drive motors into the system.

(Cross-posted to NewScrewdriver.com)

Phoebe’s first chassis stacked vertically: motors and wheels on the bottom, electronics in the middle, and LIDAR up top. That had to change for chassis 2 due to the desire to lower height of LIDAR for better obstacle visibility. The electronics were squeezed to the front where they now occupy a tray dedicated to all electronics components. This tray was originally separated because the chassis would otherwise be too big to print on my printer. But as it turns out the separation also made it more convenient to iterate through ways to install electronics without having to reprint everything.

The unpredictability came from wiring: I didn’t want to cut wires attached to components (the LIDAR, the motor+encoder, and battery) to length, so there needs to be room to coil extra wire. I also needed to run power wires to voltage regulators. One producing 3 Volts for LIDAR spin motor, a second one adjusted to 5 volts for Raspberry Pi. The Roboclaw handles battery power directly to the motors, and has its own voltage regulator to drive its internal logic circuits plus motor encoders.

It took two iterations to get everything to fit nicely, but once I started driving Phoebe chassis 2 around I found a new problem: approach angle. Chassis 2 has a higher ground clearance relative to its predecessor, and I held the same ground clearance for the electronics tray. However, because the tray is hanging out in front, having the same clearance is not enough when transitioning between different floor heights. When going from linoleum to carpet, thick carpet can get caught on the tray’s front lip preventing further forward progress. And when transition from carpet to linoleum, the front lip contacts the linoleum as the rear caster is still sitting on carpet. They lift the two drive wheels off the ground and Phoebe is stuck, helplessly spinning drive wheels.

The solution is to angle the tray upwards so the bottom of the tray becomes a skid plate. This helps transitioning from linoleum to carpet, and does not pull the drive wheels off the ground when going from carpet to linoleum.

And thus we inadvertently find the third benefit of printing the electronics tray as a separate piece: we can print it at a different angle, with its flat bottom on the print bed, avoiding the need for print supports to generate the sloped surface.

With these changes, Phoebe can now roam through my entire house, freely traversing across the various terrains of a normal household.

(Cross-posted to NewScrewdriver.com)

Once I aborted plans to split Phoebe's second chassis design into top and bottom decks, most of the workload was concentrated into a main backbone structure that will support all three wheels - two motorized driven wheels and one caster wheel. It will also support the battery, which is the heaviest single component, and the scanning LIDAR unit salvaged from a Neato robot vacuum.

Aside from their size and weight, the common thread with these components is that I don't expect them to change very much in Phoebe's future. They are all of the core components of a TurtleBot: differential-drive for mobility and a LIDAR to sense its surroundings. If either of those primary items change, it's really an entirely different robot and no longer an iteration of Phoebe.

What I do expect to evolve at a much higher rate are the electronics that will control the motors and read the sensors (both motor encoder and LIDAR.) They will be mounted on a separate electronics equipment tray which will be mounted to the front end of chassis 2 backbone. More detail on that later.

For rigidity I had planned to make everything a single piece, but I wasn't able to figure out a good way to make a 3D-printable structure that can support the LIDAR module above the motors and still leave enough space for those motors to be installed. So the LIDAR front support became a separate C-shaped piece that is clipped onto the backbone after motors are installed.

Other than that concession to practicality, Phoebe's new backbone is a single rigid structure that links all wheels together and supports everything except the electronics. Once I had all the major connection points sketched out, I put effort into aesthetics design and making the backbone look more like one smoothly blended and integrated unit. The arch connecting all three wheels reminded me of a similar arch aboard Star Trek: The Next Generation's Enterprise-D bridge. (It held computer displays for the officers on duty standing behind Captain Picard.)

Printing this design requires support structures for that arch, and took over 8 hours to print. (Plus another half hour for the separate C-shaped clip.) I'm pleased with the results and, as expected, it has held up well through multiple iterations of the electronics tray.

(Cross-posted to NewScrewdriver.com)

With help of Onshape in-context modeling, I started creating a chassis for Phoebe to support an arrangement that fit every component compactly like a 3D puzzle.

It was immediately obvious that I would not be able to print the entire chassis in one piece, as the footprint is greater than my 3D printer’s 200mm x 200mm print area. As I typically design parts to be printed without supports, I started with an approach that would split the chassis into top/bottom pieces. The top deck would support Phoebe’s caster wheel and Neato LIDAR. The bottom deck would support all the electronics. Then the battery compartment and motors would be bolted in between the top and bottom decks.

Here’s one of the drafts of the low deck, with a representative sample motor, battery, and Pi. I was not terribly confident about placement of the electronics. I could model the individual parts in CAD but there will be a lot of wires going between them. Wires take up space, and they are flexible with spring that push against each other, making them difficult to model accurately in CAD.

I looked at the electronics tray here and foresaw printing several iterations as I worked through wiring challenges. The bottom deck also includes part of the battery tray and motor mounts. Since these two things aren’t expected to change, printing each iteration would waste a lot of time going over the same thing. This was the first strike against a top/bottom split.

The second strike is physical strength: since top deck would house the caster wheel sticking out the back, it has leverage to put a lot of stress on however the top and bottom decks will be joined together. No matter if I used glue, or bolts, or something else. Foreseeing the structural loads, I decided it made more sense to have a single strong backbone connecting both motorized wheels and caster wheel.

This will require printing with supports, but the resulting strength should be worth the effort, and it isn’t likely to change as I evolve through the electronics. So I abandoned the top/bottom split and changed to a front-back split, with the strong single piece supporting all mechanical parts in the back.

(Cross-posted to NewScrewdriver.com)

Digitally laying out major components of a project in 3D space is something I’ve done for many projects, from my FreeNAS Box, to Luggable PC, to Sawppy the Rover. Doing it again for to figure out a more compact layout for Phoebe’s second chassis wasn’t a big deal in itself. However, this time the exercise will have a much more direct impact, thanks to a relatively new feature in Onshape.

For my past exercises, once I had decided upon a layout I would take measurements of relative position and dimensions of spaces between them. I would then copy those numbers to new drawings and build parts from those drawings. This workflow is functional but feels silly. The layout information is in the computer, why can’t I use them back in the drawings for components?

I’m not sure what the answer is, but whatever they may be, they are no longer relevant: modern CAD software now offer the ability to take assemblies of parts and use information from the assembly in drawings. They go by various names. SolidWorks documentation refers to this as top-down design. Onshape calls their version in-context modeling. Whatever the name, it’s a system that allowed me to reverse my design process. In the first chassis, I built a simple plate and bolt parts on it as I went. Now with the help of in-context modeling, I’ve arranged all the components in a game of 3D puzzle before creating a chassis to deliver that arrangement.

Using in-context modeling, I don’t have to copy & paste dimensions and risk introducing errors in the process. I also have the option to move parts around my layout and have all design dimensions update automatically. That last part doesn’t work quite as well as advertised, though I’m not sure what’s fundamental problem and what are just minor bugs they’ll fix later. But it works well enough today for me to believe in-context modeling will have a role in all my future projects.

(Cross-posted to NewScrewdriver.com)

Phoebe’s first chassis was just a rough draft to get first hand exposure trying to get all the parts my TurtleBot variant needed to talk and work with each other. What that exposure taught me is I need to improve packaging space efficiency and create a much more compact robot. Only then could I satisfy the competing requirements of increasing ground clearance and lowering LIDAR sensor height.

To work on this puzzle in three dimensions, I started by holding parts up against each other. But I quickly ran out of hands to track all their related positions so I moved on to do it digitally. First I created 3D representations of the major parts. They didn’t have to be very detailed, just enough for me to block out the space they’ll need. Then they were all imported into a single Onshape assembly so I could explore how to fit them together.

I turned the caster forward, as if the robot was travelling backwards, because that position represents the maximum amount of space it needs. My battery is the heaviest single component, so for best balance it needs to be mounted somewhere between the drive wheels and the caster. Relative to the first draft chassis, the battery was rotated to allow more ground clearance, but that also pushed the caster a little further back than before.

In the first chassis, electronic components like the Roboclaw motor controller and Raspberry Pi 3 were sandwiched above the motors and below the LIDAR. They’ve been moved to the front in order to lower LIDAR height. The lowest point of the LIDAR module – its spinning motor – was dropped in between wheel drive motors. This required turning the LIDAR 180 degrees – what used to be “front” is now “back” – but we should be able to describe that frame of reference by updating its corresponding ROS component transform.

(Cross-posted to NewScrewdriver.com)

The first rough draft chassis for Phoebe worked well enough for me to understand some pretty serious problems with that design. Now that I have a better idea what I’m doing, it’s time to start working on a new chassis incorporating lessons learned. And since all the components will be taken apart anyway, it would be a good time to address another problem: Phoebe’s speed. More precisely, the lack thereof.

Phoebe’s motor + encoder + gearbox unit was borrowed from the retired parts bin for SGVHAK Rover. Since they were originally purchased to handle steering, priority was on precision and torque rather than speed. It worked well enough for Phoebe to move around, but their slow speed meant it took quite some time to map a room.

The motor mounts used for Phoebe’s first draft chassis were repurposed from a self-balancing robot toy, which had a similar motor coupled with a different ratio gearbox. That motor was not suitable for ROS work because there was no encoder on the motor, but perhaps we could swap its gearbox with the motor that does have an encoder.

Here’s the “Before” picture: Self-balancing robot motor + gearbox on the left, former SGVHAK rover steering encoder + motor + gearbox on the right. The reason I was able to use the self balancing robot’s motor mount and wheel is because they both had the same output shaft diameter and mount points. While they have identical diameter, the steering gearbox is noticeably longer than the balancing robot gearbox.

Both of these motors conform to a generic commodity form factor called “370”. A search for “370 motor” on Alibaba will find many companies making different motors with different options of voltage, speed, etc. All are physically similar in size. Maybe even identical? As for what “370” means… best guess is that it originally referred to overall length of the motor at 370 millimeters. It doesn’t specifically mean anything for remaining motor dimensions, but “370 motor” has probably become a de-facto standard. (Like 608 bearings.)

After a few screws were removed, both gearboxes were easily disassembled. We can see a few neat things: the plate mounting the gearbox to the motor had multiple holes to accommodate three different patterns. Either these gearboxes were designed to fit on multiple different motors, or some 370 motors are made with different bolt patterns than others.

Fortunately, both motors (one with encoder, one without) seem to have the same bolt pattern. And more importantly – the gear mounted on the motor output shaft seems to be identical as well! I don’t have to pull the gear off one shaft and mount it on another, which is great because that process tends to leave the gear weaker. With identical gears already mounted on the motor output shaft, I can literally bolt on the other gearbox and complete the swap.

Voila! The motor with encoder now has a different gear ratio that should allow Phoebe to run a lot faster. The slow one was advertised to be 227:1 ratio. I don’t have specification sheet for the fast gearbox, but turning one shaft and counting revolutions of the other indicates a roughly 20:1 ratio. So theoretically Phoebe’s top speed has been increased ten-fold. Would that be too fast and cause Phoebe to run out of control? Would it be unable to slow to a sufficiently low crawl speed for Phoebe to cautiously explore new worlds? We won’t know until we try!

(Cross-posted to NewScrewdriver.com)

A little real-world experience with Phoebe has revealed several problems with my first rough draft chassis design. The second problem on the list is Phoebe’s LIDAR height: It sits too high to detect certain obstacles like an office chair. In the picture below, Phoebe has entered a perilous situation without realizing it. The LIDAR’s height meant Phoebe only sees the chair’s center post, thinking it is a safe distance away, blissfully ignorant of chair legs that have completely blocked its path.

Here is the RViz plot of the situation, representing Phoebe’s perspective. A red arrow indicates Phoebe’s position and direction. Light gray represents cells in the map occupancy grid thought to be open space, and black are cells that are occupied by an obstacle. Office chair’s center post is represented by two black squares at the tip of the red arrow, and the chair’s legs are absent because Phoebe never saw them with LIDAR.

This presents obvious problems in collision avoidance as Phoebe can’t avoid chair legs that it can’t see. Mounting height for Phoebe’s LIDAR has to be lowered in order to detect office chair legs.

Now that I’ve seen this problem firsthand, I realize it would also be an issue for TurtleBot 3 Burger. It has a compact footprint, and its parts are built upwards. This meant it couldn’t see office chair legs, either. But that’s OK as long as the robot is constrained to environments where walls are vertical and tall, like the maze seen in TurtleBot 3 Navigation demo. Phoebe would work well in such constrained environments too, but I’m not interested in constrained environments. I want Phoebe to roam my house.

Which leads us to Waffle Pi, the other TurtleBot 3 model. it has a larger footprint than the Burger, but it is a squat shape allowing LIDAR to be mounted lower and still have a clear view all around the top of the robot.

So I need to raise the bottom of Phoebe for ground clearance, and also lower the top for LIDAR mount. If the LIDAR can be low enough to look just over the top of the wheels, that should be good enough to see an office chair’s legs. Will I find a way to fit all of Phoebe’s components into this reduced height range? That’s the challenge at hand.

(Cross-posted to NewScrewdriver.com)