Arm design concept
So we are trying to make this thing as cheap as possible while still being quite capable. Therefore, no fancy gearboxes, just a single belt transmission for each axis. Also, to increase the payload capacity, we will be adding counterweights to the reverse side.
The original design inspiration for this was a counterweight balanced floor lamp that I saw at my cousins house. I can’t find a picture of that, so this is the most appropriate design I could find. It is a loading arm for connecting the pipe used to load tankers, so feel free to disregard the nautical terms on the labels.
The above design is fully balanced when there is no payload. We can also change the counterweight mass, or move the pivot points, to fully balance the arm with a specific static payload. If we are going to be picking up and dropping things, i.e. if we have a dynamic payload, we can borrow a trick that is very commonly used in elevators, and that is to over-counterweight the arm (elevator). That is, when the arm is empty, it actually has to work to keep the arm down rather than lift up: this larger counter-weight means we get a higher max capacity.
Very conveniently, a belt drive transmission and the hoverboard motor being quite heavy, means we can neatly let the wheel itself be the counterweight; and we can always add more weight if we need to. This concept so far only shows one axis, but we will be stacking the other axis just like in the marine loading arm concept above.
Unlike the marine loading arm, we wont use cables to connect the outer limb, instead we will use a solid rod like the above ABB IRB-760 palliating robot. This robot has another linkage mechanism (the sets of slightly thinner linkage rods). This is used to maintain the end of the robot in the horizontal plane without any additional active axes. I think I will try to do this also for my design, but I don’t really have a plan of how it will be done just yet. Feel free to provide suggestions.
Getting the torque out of the wheel
Okay so this is the main disadvantage to these hoverboard motors: they are designed to spin a rubber tire on the ground, not coerced into powering robot arms. Nevertheless, here is my plan to try to convince them to do so anyway:
The first thing we need to think about is how to get useful torque out. Lucky for us, on the rotor side we can use the 6 screws that hold the cover plate onto the wheel.
Light blue: main rotor shell, light gray: rotor cover plate, yellow: bearing, dark gray: stator.
On the stator side, as you can see the only thing we have available to hold on to is that shaft with the flat on it. That’s gonna be much more tricky without using machined metal parts. Maybe it won’t work, but we are here to find out.
This is the pulley starfish, it is intended to be 3D printed. Substituting the original screws for the rotor cover with longer ones we can attach it in the 6 locations. The pulley is a for a GT2 profile 5mm pitch 15mm wide belt. The gray ring is for the encoder, which I will talk about at the end of this post.
I think there should be enough material, at least when using solid PETg, to handle a fair bit of belt tension. The underside of the starfish has to be flat to allow sitting on the print bed, otherwise I would have made it fill the original countersinks of the cover plate. We can make some separate filler rings for that I guess.
So here is the part that I am the most worried about, the one that will hold onto the shaft.
It will be made out of printed solid PETg plastic.
It will hold two pieces of 2020 aluminium extrusion that are clamped together with two screws.
The top extrusion will be located against the flat of the shaft to transfer the torque. The belt tension will be pulling the pulley “down” in this view, so the interface to the orange extrusion should be under compression. So there are two things I’m worried about: will the small area to the orange extrusion be enough to handle all the torque, and will the light blue plastic part be strong enough to hold the tension of the belt cantilevered so far out?
Feel free to look around in the Onshape document and let me know what you think. This is the live document that I will be working in, so it things may change by the time you look.
Encoder
These motors have hall sensors, but we need more accuracy than that for this. So we need to install an encoder. A shafted or shaft-fitted encoder is mostly ruled out, since it will be quite annoying and awkward to bolt a flange-and-shaft part to the “outside” face of the motor. Two feasable options are on-axis and off-axis magnetic encoders, since you only have to glue a magnet to the rotor, which is fairly easy.
With an on-axis encoder, we would glue a diametrically magnetized magnet to the only on-axis location that is available, namely the location shown above in bright green. The other option is to use a off-axis encoder in a location ext to a rotating face, such as the location shown in red.
These off-axis encoder magnets are often multi-pole, meaning they show multiple “magnetic” rotations per mechanical turn. The drawback of this is that you don’t get any useful homing functionality from the encoder index pulse. The upshot, however, is that you can make the pole count really high, and get a very high resolution encoder.
Free samples are the best. We will be trying out the AS5311 encoder with a 128 pole magnet ring. The encoder outputs 10 usable bits per pole-pair, so that means we have a 65,536 count/rev encoder. Yes I also didn’t quite believe that number when I first saw it. Incredibly, the cost of these parts are like $10-$15 in single quantity! Crazy. Let’s hope it lives up to the specs.
Not only were the samples free, but they got here from Austria in 3 days. These guys know how to impress a customer.
They cant get the hole spacing right in the specs, and the pictures vary within the same product… Most gimbals motors I’ve bought from them didn’t match either the pictures or the specs. Luckily, I was 3D printing/Laser cutting the mounts and the hole size and spacing was arbitrary.