Raspberry Pi controlled Lego car part 2

Not many pictures this time, because unlike last time I’ll rant a bit this time about getting the software on the Pi working. To start off: I did something rather stupid: I updated Raspbian. It took ages to update the OS and all the packages. The Pi isn’t very fast for that. I should’ve just downloaded a new image. Here’s how I lost a lot of time.

After updating the OS my wifi stopped working. I’m using a small TP-link USB wifi, since my Raspberry Pi B+ doesn’t come with on-board wifi. I did a lot of searching on why this would suddenly stop working, and found that, only in some cases, the B+ is incapable of providing enough power to the USB ports to make my particular model of wifi adapter work. The wifi did in fact work for just a split second after booting, and I was able to ping the Pi from another PC, but it almost immediately disappeared again. This I thought was a good indication that it was indeed a power issue.

I bought a USB cable from Amazon that combines two USB plugs, one for data, one for power, into one output, for the wifi plug. I was fairly confident that this would solve my problem. First I plugged both inputs into the Pi’s USB ports, but no luck. Then I tried plugging the USB power input directly into my USB battery pack, but that didn’t work either. It did have a weird side effect, in that if I disconnect the Pi’s regular micro-USB power connector, it miraculously stays powered through the USB wifi plug. Weird, but not useful.

So I did some more digging and eventually found out that for every Pi kernel you need to manually (re)compile your wifi plug’s driver. Ugh. I got started on doing that but it took ages. I eventually managed to find a site that offered precompiled drivers and simple installation instructions. Not exactly open-source but I’m definitely not going to wait hours for the bloody thing to compile.

With the wifi fixed and the motors super-easy to control via the Python GPIO library, I got to work on getting the Pi’s camera feed to work. The Pi supposedly does full-HD video capture at decent framerates so I had high hopes of getting a nice stream going. Unrealistically high hopes, it turned out. Recording decent quality video is one thing, but streaming it in real-time with little enough delay to control a moving vehicle, that’s quite another. I had to turn down the resolution all the way back to 640×480 to get <500ms delay, but after that it’s quite usable. The uv4l raspicam package comes with a built-in server to stream video, which is actually pretty nice when playing around with it on the local network, but since my final goal is to open it up to the internet I’ll have to find something a lot more secure than that. I’ll likely set up a separate Python server to forward the video feed, or stream it from the device directly. I hope it won’t introduce too much extra delay..

On the hardware front I’m playing around with some of Sariel‘s gearboxes. I bought a set of various Lego gears on ebay since my aging Lego Technic did not have many useful parts. I built this three-speed gearbox and then figured I might as well buy the Lego Servo motor as well to play around with.

Turns out that controlling a servo motor from the Pi is a lot more difficult than controlling a regular motor. To get the servo motor to go to a pre-set position you need to use pulse width modulation with a very specific duty cycle for each position. If you get the duty cycle slightly wrong the servo will jitter around the position and move back and forth a bit. The same happens when using the Python GPIO default module, which comes PWM functionality built-in, but just can’t be real-time enough to generate a stable signal. There’s loads of jitter if you try it that way. I ended up going with RPIO, which uses Direct Memory Access to get the timings right. I played with it for hours but in the end still could only get about half out of the supposed 14 positions to select correctly. I think that’s more of a problem on my side though, and I’m probably using the wrong duty cycles or frequencies. That said, I’m totally indulging at this point because the gearbox only needed the off position and full negative and positive duty cycles, so I didn’t even need to use pulse width modulation at all. It was an interesting side track though.

Once I got the three-speed gearbox working with the servo I slapped an XL motor on to it and immediately realized that this gearbox design will never work for my tracked vehicle. As soon as I applied only a little pressure on the output wheel the servo axle would fail and start rotating. It really doesn’t stand up very well to any decent amount of torque. Time for another design. I ended with a super-simple custom design for a 2-speed gearbox that I got off the internet, but all the simple designs, the designs that I actually have the parts for to build, don’t seem to be meant to be controlled with the servo motor. I played around with this for quite some time last Sunday and eventually managed to rig up some kind of controlling arm to push and pull the middle axle of the gearbox so it can shift gears. I haven’t tested this with load, though, so I’m not sure if it’ll hold up very well in the final vehicle. But I’m a bit more confident about it than I was about the three-speed servo gearbox.

The next challenge will be to duplicate the gearbox and make a design that allows the servo to change gears in both gearboxes simultaneously. Since I’m making a vehicle with independently-controlled caterpillar tracks (but only have one servo motor) I’ll need to have one gearbox for each track.

Lastly, I got one more thing wrong in the last post, about getting power to the motors. I had bought a USB-to-9V cable, which I thought didn’t work in my USB battery pack because the battery pack was smart enough to disable the port if it detected that no power was being drawn. That assumption turned out to be completely wrong. Instead, what happened was that the cable had a very shitty USB connector and after I let go of the connector it would drop a bit and disconnect. I duct-taped it into place and it works perfectly, so I can get away with using just one USB battery pack (with two USB ports) for my vehicle. Yay!

Posted in Tech | Tagged , , , | 2 Comments

2 Responses to Raspberry Pi controlled Lego car part 2

  1. It erettile fattore prezzo disfunzione in rx farmacia italia alla consegna erboristeria miglior vardenafil naturale cialis al psicologico

  2. Reader says:

    UV4L is made for the IoT and uses WebRTC standard technologies where encryption is mandatory by default. I am not sure what you mean something “more secure than that”.

Leave a Reply

Your email address will not be published.