Sux0rz

August 6, 2016

Note: I’m going to try something different with this post and update it as the project progresses. We’ll see how that goes…)

Sux0rz is a robotics collaboration between Jamie and myself. The name (which may change) was inspired by the fact that it started it’s life as a vacuum cleaner.

For my part of the project the starting place is making it move. It came on wheels, which is a good start. The rear wheels look like old lawnmower wheels and are mounted on a solid axle, here’s the basic measurements:

Axle 9.53mm
Wheel ~7in
6 spokes

The front wheels are pivoting casters, so a tank-style two-motor setup should prove adequate for drive and steering.

After mulling over the drivetrain options I settled on attempting to design & print it myself. This lets me recycle a pair of motors left over from the Power Wheels autonomous truck/hovercraft project instead of having to buy off- the-shelf gearmotors, which are kind of expensive and take awhile to get here.

This might not pan out since I’m still learning about designing gears, ratios, power requirements, etc. and also working with undocumented motors, but this is more fun than just spending money.

Turns out the gear’s center hole should be 10mm ID (post-print) to fit over the axle.

The custom gear has been designed to work with the pinion that came with the motors. I’d prefer twice the gear ratio (currently 15:1) but that would require more gears, so we’ll try this for now.

Turned out that the motor nestles in almost perfectly between the deck and one of the existing axle clamps (?). Gear engagement seems satisfactory, so all that’s necessary is something to hold the motor in place.

After considering a few options, I remembered I had a bar of aluminum stock that was close to the width of the motor. With a few well-placed holes, the motor could be mounted through a piece of this bar and the whole things could be bolted to the side of the deck.

For whatever reason I seem get spacing like this wrong often (perhaps a “stack-up” problem. Regardless it seems to hold, so I’m planning to use this as a template to cut a pair of more accurate mounts later.

I wanted to have some adjustment in the mount, so that the engagement could be experimented with, but for the first pass I decided against it. I wasn’t sure how everything was going to come together and I didn’t want to spend a lot of time working the mount if it was going to have some fatal design flaw.

After fitting things together it looks like that’s not the case, so I might put some adjustment ability into the next version, but for now there’s enough slack in the way the assembly is mounted to the deck that there some adjustment available.

Once things were together I did a test-run using a 9v battery and everything seemed to work, but I wanted to see how it looked driving the actual wheel. My long-term plan is to modify the gear model so that it can engage a standard lawn mower wheel directly, but in the meantime zip ties suffice.

Coincidentally, this setup creates a sort of ghetto “cush-drive”. This might be advantageous, so I’m considering running with it and printing another gear like the first.

After adding the gear, and spacing it enough to avoid interfering with the motor mount screws, a longer axle is necessary. A piece of ³⁄₈” x 22” smooth rod should do it.

New axel being sized, second motor mount and gear can be seen on the right.

Both motors mounted, preparing for drive test.

Final step for the new axel, drilling holes and placing pins to keep the wheels on.

Motors

For now we’re recycling the motors from the Power Wheels truck. They seem to be some RS540 variant, 16k RPM and 12vdc I guess.

Current (har har har) thought on driving the motors is to use a simple MOSFET + Arduino PWM setup for variable speed drive in one direction. This is largely based on the fact that I have all the parts for this on-hand, so it’s cheaper and faster than buying/building something more sophisticated. Additionally, I’m just guessing at the max power requirements for these motors (40 amps?) so I’d rather burn-up a couple dollars worth of MOSFETS than an expensive (both in dollars and time) controller while I figure things out.

First pass at motor driver (controller is kind of an overstatement)

Setup a test rig on the bench and it worked end-to-end with one channel, so hopefully the second one works just as well.

Next step is to hook the whole mess up to the real drivetrain and see what happens…

First live test with the actual drivetrain:

Found out that heatsinks are necessary on the MOSFETS, and there’s suddenly more friction on the wheel than before.

Todo:

Heat sinks

File-down wheel to reduce friction

Drill-out gear hub

Mount electronics

Find cotterpins

Solder other diode

Heatsinks, hmm…

The heatsinks appeared to help, but unfortunately I noticed a problem with the solder joints on one of the MOSFETs. I thought I could repair it, but the traces on the board were actually lifted and broken, so it looks like this board it toast.

I might be able to make another one but I’m going to need some parts. Since I’m ordering parts anyway, I decided to pick up a couple of cheap RC motor controllers as well. I really wanted to build my own drivers for the robot because I wanted to work with parts-on-hand and learn about motor control in the process, but the clock is ticking for Milwaukee Makerfaire and using off-the-shelf controllers is one less variable at this point.

I guess I still did build my own driver, even if only half of it worked, and I’ve learned enough that I might take a swing at making a more advanced driver/controller in the future for another project.

Now I need to find out if I can use the existing pyfirmata - > standardfirmata setup to drive servos instead of just PWM.

Motor control V2

The new motor controllers basically work, and with that it was possible to assemble the entire robot (temporarily in some areas) and test the system end- to-end. Functionally everything worked, but there were some control problems. Here’s what we know now:

The drivetrain is capable of moving the entire system at a high enough speed
The control system works as expected
All of the parts can be assembled in a form that can move about

Here’s what we need to look into:

The robot does not always respond immediately to commands
Braking and reverse
The robot can “fail deadly” in that the drive can become engaged and doesn’t disengage when control signals are lost
There is significant lag (seconds) in the video feed

I have a few things to try in order to address these issues:

Network disconnects may be to blame. Configure the robot to use an on-board wifi access point so distance to a stationary AP isn’t a factor
Add a iterator thread to the Python code to avoid overflowing the serial port
Use a queue to send commands from Python to the arduino to throttle command rate
Use a timeout on commands received at the arduino so motors stop if no additional commands are received within a specific window of time
The motor controllers supposedly support braking and reverse, but they came with no documentation so I need to find that and configure them, as well as add support for reverse to the controller software
Use a more sophisticated video streaming method and protocol
Consider switching to WebRTC to kill latency, etc. (https://janus.conf.meetecho.com/docs/index.html)

Software

At the moment it looks like a combination of Python modules will be providing remote control via WiFi (flask - > pyfirmata). A REST API will provide endpoints for motor control input that will come from a simple client-side javascript remote control (that can run on any device).

Screenshot of current (working!) controller:

**Next Steps
**

Get the Raspberry Pi mounted securely in the brainpan

Configure the motor controllers & add “arm” control to UI

Configure Raspberry Pi for mobile hotspot WiFi network

Update UI to include reverse, and configure for forward, braking and reverse signals

Notes

Could the gear include a 608 bearing (or two)? Would that fit on these axles?
Could ssh tunnels be used to expose the control interface (and associated API) to the public Internet via a gateway server?
Consider picamera to handle video stream via python instead of mjpg_streamer

Reference