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 640x480 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 , , ,

Raspberry Pi controlled Lego car part 1

So, I have a fair bit of Lego lying around from my childhood days. Not a lot of technical parts, but enough to have some fun with. I also have a Raspberry Pi lying around after a failed experiment where I tried to use it as a security camera. Why not combine the two? I figured I could build a Lego car that I can control remotely via a little server on the Raspberry Pi, which would also stream its camera feed. It seemed easy enough, especially after discovering a page that explained exactly how to make the hardware part of it work. Never did I imagine it would take this much work to get it up and running..

This post will detail the hardware iterations and setbacks I faced. The next post will go into detail about the software side of things.

So, before starting on this project, here is the list of things I thought I'd need to make this work:

  • Bunch of Lego: wheels, gears, other technic parts and some generic bricks to connect it all up. (already owned)
  • Raspberry Pi plus camera module. (already owned)
  • A USB battery pack (already owned)
  • Two Lego power functions motors.
  • A 9 volt battery.
  • A motor controller.
  • Some Dupont wires to connect it all up.

Version 1

I bought the M motor starter kit and a separate M motor for my first iteration. I built a very nifty motor assembly and a very strong shell structure to house the components. Here's how it looked like:

v1.0

It is thus that I found out that I should never overengineer before testing. While building the thing I discovered that I didn't have the parts required to drive all six wheels, so I chose to just drive the middle wheels instead. I figured that by gearing down a bit it should be fine. Much nope. The M motors were way too weak to power the construction, which was already quite heavy from the USB battery pack, but weighed down even more because of its overengineered sturdiness. Having just the center wheels powered was also a terrible decision. Fail.

Version 2

v2.0

I built this is a test version to experiment with gear ratios and to see if in a lighter version the M motors would have enough power to drive the car. Answer: not really. I got it to go forward and backward pretty decently, but I still didn't have the parts required to power all the wheels, so the motors were not strong enough to turn the whole thing without a steering assembly. Fail again.

So I had two options at this point. Option one was to build a rack-and-pinion steering assembly, for which I had the parts available and did end up experiment with, but in the end I wasn't happy with its turning radius and how I'd either have to buy a servo motor or have an 'unclean' solution with a clutch gear to handle the stopping at the end of the wheel turning axis.

Instead, I went with option two: throw more money at it. I bought two XL motors and a crapload of caterpillar tracks. That'll give me the power and the grip I need to build something really nice.

Version 3

..or not. It does look impressive though. Here's a test build with the power functions battery box instead of the external 9 volt battery.

v3.0-test

At this point I was still powering the motors via a separate 9 volt battery. I figured that, since my USB battery had two USB connectors, I could use it to power the motors as well, so I ordered a USB-to-9-volt cable from Amazon. That should help me save some weight by not having to put in two batteries. Sadly, this did not go well.

USB batteries are pretty smart. So smart in fact, that they only output power if they think something's plugged in. The USB-to-9-volt cable worked fine on a powered usb hub, but every time I'd try to hook it up between the battery and the motor controller it would simply not turn on. Crap.

I found another USB battery, which is actually a battery used for starting cars that happens to have a USB port on it. This one did always keep the power on if I plugged in the USB-to-9V cable. Good! Except it only had one USB port, so I couldn't also power the Raspberry Pi from it. So I ended up with two USB batteries and over double the original weight..

v3.0-final

The big green thing is the car-charging battery. Even without the second battery the 3:1 gearing wasn't quite powerful enough to rotate this monstrosity when on certain surfaces, such as medium-thick carpet. Once again, fail. And once again, I spent way too much time overengineering the construction without testing it first with its full weight.

Version 3.5

I figured I'd try to keep the next version as small and light as possible and worry about motor powering and recharging issues later. I managed to build a pretty small prototype.

v3.5-test

Now, I had one option left to avoid the use of two batteries. The big green car charger battery did, in addition to its one USB port, come with a 12V output. It's not the 9 volts that the Lego motors need, but I did find at least one link claiming that the motors should run fine on 12 volts as well. I had previously done this as a child when connecting an old technic 9V motor to my 12V Lego train controller, which gave it quite a nice speed boost as well. I figured this would be an acceptable trick. I butchered an old power supply, cut off it's circular connector and used it to connect up the green battery's 12V port up to the motor connector.

To avoid any more gearing issues I added another axis, bringing the final ratio down to 9:1. The build ended up much larger than I had intended, but still smaller than v3.0. With better gear ratios and a higher voltage to the motors.

v3.5-final

You may notice the second battery sticking out at the end of this bulky thing, despite the fact that the green battery has a free USB port thanks to the makeshift 12V connector. This is because the stupid battery doesn't let you use both outputs at once. It just turns off one or the other. Not ideal!

I'm still annoyed at this but don't have an immediate solution. The reason I spent so much effort trying to get everything onto one battery was because I intended to build a little wall charging station, so I can drive the robot into the charging station, which will connect the charging port of the USB battery onto a USB wall socket. I gave this a try with the double-ported battery while the Raspberry Pi was connected, and sadly it resets the Pi as soon as the charging connector is plugged in. Crap times two. I haven't tried this trick with the green battery, but that's pointless anyway since it only lets you use one device at a time. Looks like I won't be able to charge the thing remotely while it's running.

V3.5 still has a whole bunch of issues. It works great in terms of motor and track performance though. It moves and turns fantastically. even loaded with two bulky batteries. The motor placement isn't great though; they're way too close to the ground. I need to fix that in the next version. It's also longer and wider than it needs to be. Once I get a solution to the two-batteries issue I'll decide on how large the next version will be. I'm also thinking about buying the servo motor and using it to power a small gearbox, but I'd also need to buy more technic gears and axles for that, and I've kind of already spent way more on this project than I thought I would spend..

For now though, I'll stick with this hardware design and focus on getting the software up and running. More on that next time.

 

Posted in Tech | Tagged ,

New hobby project

Turns out it's really easy to control Lego power functions motors via a Raspberry Pi. I found myself a new hobby project :)

2017-01-08 20.24.33

Posted in Tech | Tagged ,

London Overground's biggest problem

Nearly every working day I take the London Overground to work. I am quite lucky: my working hours are flexible so I can avoid rush hour. The stations I get on and off are near the first stop and the very last stop on the line, so I am pretty much guaranteed a seat every time. The trains are airconditioned in summer and nicely heated in winter, which is a fantastic improvement on the Bakerloo line, whose trains may be the draftiest place in the UK. There's just one thing that bothers me a lot about the overground, and it's not even the delays. But I can't talk about my gripe with the overground without talking about the delays.

There's always been delays on the overground, ever since I came here 3-4 years ago. Sometimes there's this sign in the carriage telling you that x% of the overground trains ran on time in the last quarter. I've occasionally snapped pictures of those signs because I never once got the impression that things were getting better. TFL is pretty good in providing statistics on their website about their service, and I've done the math once to check if it actually was getting worse. Turns out I was wrong on that one. But things aren't getting much better either, and I can see those numbers just as easily go down again in the near future. There's nothing that inspired confidence in me to believe that there's an ever-decreasing amount of delays.

This leads me to the reason I hate the overground: the utter lack of accurate real-time reporting. The most common occurrence is a delay of under ten minutes. TFL's strategy of dealing with this is by not dealing with this. Every TFL employee just stays absolutely silent and hopes nobody notices. They certainly won't be updating the arrival times on the signs until well after it's too late. This is not a hard problem! Unless the staff are utterly and disastrously incompetent they would be immediately aware of the delay. They've got a website that everyone in London uses to check the delays which they could update immediately, but TFL deliberately chooses to take no action whatsoever whenever this happens, I guess in the hopes that the problem will magically go away?

Small delays don't always stay small delays, though. Sometimes a train needs to be taken out of service, or is delayed even further to even out gaps in the service, or any other reason really. That's perfectly fine. Once something's bad happened it of course make sense to return to normal service by whatever means necessary. But you need to report that to your customers, dammit! If I'm standing there at the bloody station for a train that's already ten minutes delayed without receiving any information at all about the state of the service, of course I am going to be even more annoyed if I suddenly hear that the next train is cancelled and I have to wait the better part of an hour for my next service. Whereas if TFL had reported immediately on the initial delay I would have stayed home just a little longer, checked the situation from their website and would have been much better off in the end. I wouldn't even have thought worse on TFL in that case, but if they make me walk to the station and make me wait in the winter cold when they could have told me already that there were delays, that's what really pisses me off. The problem is not the delays, it's TFL's lack of reporting on it which causes annoyance.

I realize that this is not a world-ending issue. No one will die from this problem, nor does it seriously affect the days of anyone involved. I can work from home, others may take taxis or busses, and in the end everything ends up just fine. But what really bothers me about this is that it's completely preventable. There is absolutely zero need for me or any other passengers to get annoyed at TFL for the delays if they just improved their reporting. There's staff at every station on my overground line, which is great, but they're all doing fuck-all whenever there's a delay when in fact they could be reporting the delay immediately so the TFL site can update. Not reporting on a delay until X minutes have passed is a terrible idea because it's not at all uncommon for smaller delays to snowball and become something worse.

Rant over. I am working from home today.

Posted in Daily Life , UK | Tagged , , ,

Kata Tjuta

img_1713ps

 

img_1756ps

Uluru was beautiful, but Kata Tjuta truly amazed me.

Posted in Photography , Travel | Tagged ,