It’s time for a bit of blog attention I think. My multi-project-itis has really kicked in and I have been on tangents all over the place, unfortunately none of them were blogging. Right now there are 3 projects taking up workshop space:
The Impulse Portal:
The prototype is still chugging along as we delve into the next major engineering hurdle, moving the chair. Using the small scale prototype as the functional baseline, we have been looking for the most effective method of power transmission for this particular application. Without wanting to commit too much time and resources on a structure that is ultimately untested, we have decided another rig is order. A few ideas are involved; a pair of rails, a truck and wheels carriage, ball screws, and motors.
Rails: A similar system to roller coaster tracks, but using square section instead of round. We aren’t turning any corners or ramp up hills, just back and forth. This also lets us use standard flat wheels without the matching grooves needed for round rails.
Truck and wheels: Like above we need to hold the carriage in place during flips, heaves and sways. This means wheels on all sides to hold on tight.
Ball screws: To move the carriages at high speed (actually high acceleration but that’s harder to describe) we need a sturdy power transmission system. Chains and belts are an option but they require a lot more maintenance. In come ball screws, which have been used in the machining industry for years.
The style of ball screw can be fairly customised, such that it’s diameter and pitch can be selected to match the project criteria. Here we plan to use the pitch of the ball screw as the gearbox, in a way that a standard 3000 RPM motor can couple directly to the ball screw and produce a linear speed in the range that we need. Or at least that’s what the maths tells me, hence the need for another rig before we blow all our cash on an untested system.
The next problem of course is deciding how the information ultimately flows from the game to the motors and all the little interconnected systems that make it happen.
I have been playing around with a concept for a sort of DIY home automation for a while now. It was another one of my “how hard can it be?” moments, where we have been striping down our house one room at a time and trying to rewire a lot of the lights and switches. I realised that we have a quite a few rooms which have three entry ways. Normally this is wired with a a bunch of cables linking all the switching points together and using an expensive intermediate switch in the middle. A lot of work I wasn’t really looking forward too.
I thought if I have to run all those cables anyway, why don’t I just wire it up to a controller that can take those inputs and turn on a relay to drive the lights. That’s when it grew. I now have three cabinets full of electronics ready to switch lights, fans , LEDs and anything else, a multitude of push buttons ready to wire up, new software libraries that sling it all together and not very much time left at the end of the day.
It’s all still a work in progress, but I’ve made enough of a dent in it to warrant seeing it through. It is powered by an arduino mega, with the addition of 4 x 16 channel expanders (that’s another 64 I/O on top of the Megas 70 odd I/O). I have dimming channels, solid state relays, LEDs around my push buttons, and even a Wi-Fi chip for when I finally cave and start developing mobile applications too.
The best part of this is the software that I’ve built. Not only is it scaleable, but I have really refined my communication code in a way that can benefit other projects like The Impulse Portal. Plus I’ve learned a heap about libraries and object oriented coding. Win win!
Raspberry Pi Portable:
My youngest daughter and I were looking through some “Make” magazines when she spotted an article on a DIY ‘PiPad’. “Whoa can we make one of those!” she asked. How could I say no? Having played with Raspberry Pi as a home server (which has now been replaced by a more powerful Orange Pi +2e) we needed only to pick up a few more items to make it happen. She explained how she wanted to use it to “play lots of cool games”, and I knew what I had to do.
I got to work on the research right away, I couldn’t let this flame of hers flicker out. It needed to be portable so batteries were essential. I tried our existing USB battery packs, and they were OK but the pi couldn’t be used and charged at the same time. There were some USB battery pack available on the net that could do this, but I ended up picking a UPS (Uninterruptible Power Supply) hat which ticked all the right boxes. Next I found a small screen that could plug directly into the GPIO header of the pi itself, saving the HDMI slot for later. I had a case printed already but adding all this gear sort of made it full, so it is a little naked for now.
So we learned a few things about the pi as we went. Configuration is a major pain, getting the components to all work together is very tricky. The screen in particular was the worst. It’s not a bad screen, but the pi doesn’t like talking to screens over SPI without a lot of coaxing. Even then trying to use Retropie was even harder as it would only display on an HDMI screen. We tried to use a frame buffer routine which copies the frames from the HDMI output to the SPI display, and that did work, but then we were battling slow refresh rates. Now it’s time to look for another screen that uses HDMI natively, oh well, back to eBay.
Then there was the controller. We’ve got a cheap USB gamepad which works fine, but this thing has got to be portable, so I started hacking to fit things inside. First I tried an old Xbox 360 wireless controller which no longer plays nicely with wireless connections. I found a pinout of a possible USB header on the PCB, wired it up and gave it a try. Windows recognised it, but only as “play and charge device”, no data was transmitted via the USB cable. Next came the old Wii Classic controller. Pulling that apart I found the driver chip which read the inputs from all the buttons. All I needed to do was solder onto each of these pins and feed that into a small microcontroller, tight nasty looking work.
On the plus side, the shoulder buttons and trigger button mechanisms look easy enough to relocate into a better location, considering this is going to be a handheld device.
Some googling later and I learn that the Wii accessories (Nunchuck, Classic and Wii fit boards) communicate via i2c, something I have playing with on the home automation project (I love how all these hobbies tie together at some point!). I found a sketch on the Arduino playground website that plays nice with the communication protocols of the Wii accessories, including the encryption that Nintendo implemented, plugged in the appropriate wires to my Arduino Uno and away we went.
Success, everyone is talking! Next step was to turn the Arduino into a HID complaint gamepad, so that everything is plug and play. This is where it gets heavy, I got sidetracked and end up learning the ins and outs of the USB.org protocols on HID devices and the way they interact with operating systems…. waaaay too far off track. It was difficult reading and I still don’t get a lot of it, but I have a new found respect for people who make USB devices that just plug in and work. Luckily many others have followed this path before me and have lit the way. I found a couple of dirty methods of convincing the Arduino to behave like a HID gamepad and all works well. The method called UnoJoy was a bit old but it worked.
But I couldn’t stop there could I? Back into the research to try and find a way to have the Raspberry Pis own i2c interface with the controller directly (no need for a third party microcontroller as the translator). All I have to do is learn the basics of writing a driver in Linux, learn to code in Python and interpret the encryption required to talk to the classic controller. How hard can it be?