Retropie table writeup
A co-worker of mine asked me to do a writeup of my retropie table build and yes, I guess I should. I rarely write anything about what I do anymore đ .
So, I got kids, and I thought it would be fun for them to play some of the old stuff I used to play and found the https://www.raspberrypi.org/blog/raspberry-pi-ikea-arcade-table-make-yourself/ quite interesting and so set out to do something similar. I winded up going to Ikea with the kids and told them to choose colors, we winded up with a pink IKEA Lack table … ;).
I also got a bunch of old screens at home, I picked a very heavy 17″ monitor and removed all the casings etc greatly reducing the weight. My choice was slightly bad though for two reasons, the connectors are standing at a 90 degree angle to the screen so it winded up not fitting inside the table and it’s pointing out on the underside as it is now… secondly, the viewing angles are so so, I winded up rotating the screen 180 degrees as the viewing angles where much better from that direction and the /boot/config.txt in raspbian systems have options to hardware rotate the output. I also bought a set of 2 joysticks + 20 buttons with built in backlight and a xin mo based usb controller from ebay, a small speaker from a local shop and the power adapters I had at home, and a connector to fit for power input to the table. I decided to pick up a powered USB hub as well to fit so it was reachable from the outside. I also had a sheet of plexiglass lying around for many years which winded up useful. I also had a USB wifi dongle lying around so I reused that for connectivity.
We started out with measuring out and sawing up the holes needed and then removing the innards that are in the way. I used some paint masking tape to protect the table, more on this later. This work was very easy to do with a dremel with a circular saw addon. The underside wasn’t so important how it looked but I tried to make the cuts decent looking at least.
Once this was done, I test fitted and probed a bit on how to get the raspberry pi, monitor and power system fitted inside the the table before moving on to sawing the plexiglass sheet into the same size as the table, and then drilling and countersinking the screw holes, temporarily fit the plexiglass while drilling the holes for the joystick + buttons. Some sanding and fixing of edges followed. I removed the plexiglass sheet and drilled and countersunk holes for screwing the joysticks to  the topside of the table underneath the plexiglass.
Moving on, I screwed in the joysticks and fitted the power adapters for the monitor, USB hub and raspberry pi in the screen. I made 6 foam inserts to rest the monitor on and glued in place inside the table, wired up the monitor and put the monitor in. Removing the paint masking tape I realized that I used some shitty tape with much too hard tacking adhesive, meaning that I managed to pull away a bunch of the foil/tape (the “paint” on the table, it’s not painted, but rather foiled with a layer of colored plastic). When I realized this I started rethinking a paint scheme I had already planned and decided to do some modifications to hide the errors and to possibly heighten the feeling of the table.
I did the paintjob, made some simple paint masks etc and airbrushed the table with black borders, softish blue and red and green colors further softened with a few drops of white.
After this had dried for a few days I put the plexiglass on, screwed in all the buttons, joystick heads etc and installed the raspberry pi + other final electronics and tested the system. This is when I realized the problems with the screen viewing angle so I had to back everything up, remove the buttons, joysticks, plexiglass screen, and monitor. I winded up lifting some of the paint I had used to paint the table (the paint was really sticking badly to the surface). This lead me to question the surface of the plexiglass and figured I’d polish the plexiglass. I originally made the bad choice of trying to apply an old plastic modelling technique on the plexiglass, washing it with a layer of future floor polish. This looked absolutely horrible on this big surface so I winded up spending 1,5-2 hours removing the stuff again and then using some proper polishing compounds on both sides of the table making the plexiglass sheet incredibly nice looking (in my humble opinion). I Repainted the parts where the paint was removed, took out the screen, rotated it 180 degrees, re-fitted all the power adapters etc so it wouldn’t be in the way of the monitor and had to saw up a second hole for the DVI connector… I then reinstalled plexiglass, buttons, joysticks, etc… and now, a much nicer viewing angle of the monitor and a nicer looking plexiglass sheet, but paint job not as nice anymore. Shit happens. Oh, I also pulled a cable through from the screen to the front panel button so I can turn on/off the monitor from one of the buttons. The USB hub was glued into a hole made in the skirting so it sticks out underneath the table with two accessible USB ports.
After everything was fitted and tested to work I started to look at the backside what could be done about it… I had to make a raised area to increase the depth of the table as the buttons I got wont fit properly otherwise. I used a 1 cm floor skirting around the hole and then took the sheet from the monitor hole and sawed into two pieces which fits over the hole, drilled a lot of holes in it to at least create some air ventilation into the table.
At this point I’ve installed some games, used it for a bit, let the kids play around and I’m absolutely happy with it. The software side I didn’t need to do anything about, it worked more or less out of the box. I had to make a usb quirks hack to split the controller into two halves, I had to rotate the screen in the config.txt and that’s it, then just follow the installation howtos. Retropie was a really happy surprise, I wasn’t expecting things to be that smooth to install. I do wish the Amiga emulator was better integrate, it would be nice to be able to do the same thing as with the NES images, just drop them in and they work… but I understand that each game needs its own “fixes” to get up and running… I will have a look and see if it’s possible to improve the situation somehow, at least so I can start games with just the joysticks and buttons.
Using AWS EC2 instances for large builds
Filed under: Configuration Management, Debian, Development, General, Hardware, Linux, Ubuntu
I experimented a few years ago with using EC2 spot instances (virtual server on the internet, but using unused server capacity). It was fairly successful, being able to run large calculations that should have taken weeks in a matter of days.
Since I started at my current job I’ve been running into building increasingly complex yocto images which keeps growing in size, at this point most images I build can take up to 6-7 hours to build on my laptop. This is an i7-4558U 2.8GHz cpu and 8 gigs of RAM so it’s not bad really, just not enough for these types of builds.
Again I started experimenting and I am really happy and impressed. So far all experiments are for open source projects etc, so nothing that has any non-disclosure agreements or corporate etc etc, I’d like to but this isn’t up to me really. I’ve setup an AMI on EC2 which I can instantiate and have up and running in 2-3 minutes, and then mount a 100 gig EBS volume where I store the sources and build data.
The same build that generally takes up to 6 hours on my laptop takes approximately 30-40 minutes on an EC2 c4.4xlarge machine (16 cores and 32 gigs ram).
My key findings so far is:
- Keep an AMI with all the build tools necessary/or script the setup.
- Keep an EBS volume with the long term stored data, gits etc for building and mount somewhere suitable in the AMI.
- Keep a micro instance (these are free/very cheap) around for mounting the EBS volume when you just want to check stuff out, mess around etc but not make builds.
ABS plastic with plastic modelling accessories
Filed under: 3D printing, Development, Hardware, Plastic modelling
I’ve been building plastic models on and off since I was a kid, and very much so as of late, meaning that I have a lot of modelling accessories available at home.
I accidentally broke off one of the screw holes for the BabyNES Raspberry PI case (http://www.thingiverse.com/thing:449877) almost instantly due to the bad print quality. Reading around I didn’t find any obvious glues to use except acetone. In fact, I found a whole heap of warnings that the fat plastic would probably be hard to glue etc. Hence, I decided to test Revell Contacta Professional glue (http://www.amazon.co.uk/Revell-39604-Contacta-Professional-Glue/dp/B000KJPUL0) and it worked like a charm from what it looks like!
Since this worked so well, I tried some Italeri putty for plastic models (http://www.model-making.eu/products/Italeri-putty-for-plastic-models-28-ml.html) to cover up the sides which shows a lot of layers and some defects. Except the putty smelling really bad, it tacked on really hard and dried enough in just a few minutes to be sanded down.
Since the above went so well, I went ahead and did some more tests by printing a set of battered barrels (http://www.thingiverse.com/thing:535261) which turned out fairly crappy due to the print quality (mind you, much better than the first BabyNES case). Either way, perfect chance to test what could be done using those modelling tools/supplies. Here’s some before through after shots:
I think a lot of the plastic modeller materials could be used with ABS and possibly PLA plastics as well, especially where you want to make a structure, and then want to improve the details. There are much better printers out there with much better calibration of course, but these materials combined shows some great promise IMHO.
3D printing
Filed under: 3D printing, Development, Hardware, Personal
I started working at a new company a while back if I failed to mention it called Pelagicore, doing automotive in vehicle infotainment systems the right way with open source, working in the community etc. They have a 3D printer (Makerbot thing-o-matic) that’s been standing around for a while really grabbing my attention and I’ve wanted to find the time to use it since I started there. I finally took the time and am happy as a clam.
I made my first 3D print at work two days ago, first of three pieces for a BabyNES Raspberry Pi 2 case (http://www.thingiverse.com/thing:449877), a small hatch. When I went on and tried building the two larger pieces I ran into troubles. Running out of time that day, I got around to try and fix it today. Disassembled the extruder stepper motor and realized a screw had dislocated from the vibrations. Re-screw it and assemble everything again, and this time, it worked! Got top and bottom parts done before leaving for home today and am fairly happy. They will do.
The print quality is pretty shoddy, a lot of settings needs to be tuned I guess, and the print speed was probably too high for the unit. Judging by the software installed, I should probably install newer software and redo the calibrations using those instead. Still, awesome to work with this đ
DIY OSD update
Filed under: Development, FPV, Hardware, Robots, Video
Late update, but video is working as expected, GPS is working to some extent, but because of local weather I havent really tested it outdoors… I’m considering changing video transmitter and power system however. I’m currently running on 1S 160mAh batteries with a stepup regulator to 5v to a 10mw transmitter, which gives a really lousy battery time for the video system, also I’ve got too many batteries flying around at the moment I think.. Limiting to a bit fewer might be a good idea. Currently, there’s a battery for the video link/osd, one built into the camera, one for motor/rc receiver/servos, and one in the rc transmitter, 4 batteries in total of various sizes etc… a pain to charge them all. Hooking up the videolink and OSD to ESC/BEC is a trivial change and would remove a lot of cruft (stepup module etc), but will also add the EMC from motor/ESC to handle for the videolink etc as it’s a completely separate system today.
I’ve also upgraded so I’m using a mobius actioncam. Everything all in all means the system will draw more power and weigh more as well. Removing some batteries and running from the mains system would be really nice.
Saleae16 Logic16 100M 16 Channel Logic Analyzer
Filed under: Development, Hardware, Linux, Robots, Ubuntu
I got a clone of the Saleae16 Logic16 100M 16 Channel Logic Analyzer a few days ago to test some of the arduino stuff I’ve been working on for the last few months.
I was at first really annoyed because the software simply refused to work, I tried it on 4 different computers, ubuntu 13.10 64bit, Windows 7 32bit and 64 bit and same error for all of them, logic too slow for speed, try reducing blah something. My searches came up with very little info.
So in the end I found the sigrok package and compiled myself (old version in Ubuntu lacked saleae support) and was pleasantly surprised! It works and actually seemed to be an OK package! There are a few things to do before that which wasn’t obvious, you need to extract firmware from the Saleae software suite and so on for example. Also there are a few bugs in the graphical interface that I found so far. I’ll try to get them reported ASAP and possibly do some work on them. I’ll get back to this topic a bit later as it wasn’t completely obvious how to get it running at all points, for now however, it works;).
Raspberry Pi + 2x Arduino Nano V3.0
Filed under: Development, General, Hardware, Linux, Robots
Quick update, during my evenings I’ve been working with one of the Raspberry Pi’s I won on a local contest a few months ago, and it’s generally derailed into some kind of “let’s put as much stuff on it as possible”, meaning that I currently got my Raspberry Pi hooked up with:
- Slice of Pi
- Adafruit PWM driver
- Raspicam on a simple pitch/yaw servo gimbal that me and my 1,5 year old put together in 10 minutes. Controlled via PWM.
- MPU9150 sparkfun breakout board
- 2 Arduino Nano V3.0
The two Arduino Nanos have split functionality, where one will provide me with data that needs to be gathered frequently, and the other is used for slow processes such as reading out 1-wire temp sensors etc.
The first nano will have the following functions hooked up to it:
- 3x HC-SR04 ultrasound distance sensors
- Voltage measurement 0-20V circuit
- Control of 2 relays
- 3x line tracking sensors
- Reed switch
- 2x motor controls via L298P chip
The second nano has the following hooked up to it:
- MPX2200GP pressure sensor (will use something else soon’ish)
- 2x 1-wire DS18B20 temperature sensors.
- Others?
The general idea was to move timing critical stuff off the raspberry to the Nano and let the first one deal with quick sensor readouts, while the second Nano is dropped off with relatively slow sensors (DS18B20 takes very long time to read out for example). The two nanos will talk to the Raspberry via SPI I think, or possibly serial ports, but this is less likely as it would either require me to use one USB serial driver and the raspberry UART or get a 2 port USB hub of some kind and talk via USB UART’s.
I’ve meanwhile also played around with Eagle CAD for the first time in my life, making some electrical drawings of the hookups. I’m considering making a PCB layout of everything when I get there, not sure if there is any interest in this out there except for “the lols”. The image is still very raw and missing a lot of stuff that I know needs to be added at some point.
During christmas I spent some time making opencv haar cascade training on clementine detection and generally fooling around with it. I think I’m leaning towards making a robot (chassi on the way) which will travel around in the room looking for objects… I guess some of the sensors are a little overboard for this, but it’s all fun and games while it’s not work… đ
Raspicam and OpenCV instructions
Filed under: Development, Hardware, Linux, Robots
I have previously gotten the opencv and python bindings to work via the 2.3 opencv system and facial recognition did work, but the system is bugged out and I could only get 64x64px image size.
I followed these instructions to get the raspicam to work with opencv and simplecv
http://tothinkornottothink.com/post/59305587476/raspberry-pi-simplecv-opencv-raspicam-csi-camera
However, there where some minor details wrong with it so here is a short list of the updates to the installation instructions on that page.
I noticed a few problems as I saw it with the above instructions, or possibly I didn’t read the instructions well enough. That said, very good info! Thank you!
Here are the issues I had:
The opencv_2.4.5.sh script pulls in libopencv-dev which in turn pulls in the entire libopencv2.3 from raspbian repositories, which in turn meant that simplecv was still using libopencv2.3.
apt-get remove libopencv-core2.3
Once that is removed, python-opencv is also removed and simplecv will not even run anymore. Adding the following will add the path to where the python cv bindings are.
export PYTHONPATH=/usr/local/lib/python2.7/site-packages/
And finally, the LD_PRELOAD to actually use the correct uv4l libraries.
export LD_PRELOAD=/usr/lib/uv4l/uv4lext/armv6l/libuv4lext.so
Once this is done, you should no longer get the munmap errors etc, and large resolution should work:
SimpleCV:1> cam = Camera(0, {“width”:640, “height”:480})
SimpleCV:2> cam.live()
etc.
Reflashing GlobalScale Mirabox filesystem
I just worked my way through reflashing the mirabox and figured I’d post some instructions on how to do it. I’ve used the descriptions from this http://www.newit.co.uk/forum/index.php?topic=3880.0 post but found it to be lacking a few steps that could be construed as obvious… perhaps. Especially the use of ubifs is quite new to me, even though the commands are quite straight forward I got snagged up a bit in understanding how it works.
I’ve used the following rescue disk image:
https://docs.google.com/file/d/0B0imSF-34b8dZEc0SFo3N1Fzb0E/edit
And this rootfs image:
http://code.google.com/p/mirabox/downloads/list
Download and install the rescue disk on a microSD card:
- fdisk the microSD, create on FAT16 partition of 100mb size, the rest of the device as EXT3.
- Unpack the rescue disk
- Copy the mirabox file to the FAT16 partition
- Extract the rootfs.tgz file to the EXT3 partition.
- sync and umount the microSD card
- Connect a USB flash device to the computer
- Extract the rootfs image downloaded above
- Copy the rootfs to the USB flash device.
- Disconnect USB device.
- Connect micro-sd with mirabox kernel and rootfs to mirabox
- Plug in the mirabox to a computer via USB.
- Start the mirabox
- Hit a key at uboot
- >> set bootcmd ‘usb start; fatload usb 1 0x6400000 mirabox; bootm 0x6400000’
- >> set bootargs ‘console=ttyS0,115200 root=/dev/sdb2 rootwait’
- >> boot
- login as root password nosoup4u
- connect USB disk with rootfs on it to mirabox
- # cd /media/usbX where the rootfs img is located
- # ubiformat /dev/mtd2 –flash-image=rootfs-debian6.0-gti-mirabox-v5-0-1-120924.img
- # sync
- # reboot
- disconnect USB disk and remove devices.
- login to your hopefully working new filesystem using root/nosoup4u credentials.
Ubuntu 12.10 on Dell Precision M4600 APIC issues
I’ve recently installed Ubuntu 12.10 on a Dell Precision M4600 and had some APIC issues when trying to reboot, the same as everyone else seems to have pretty much. After upgrading the BIOS from A08 to A13 the issues seems to have gone away (not extensively tested, but so far so good).
Before the update, the computer got stuck on the last step of shutting down for restart, but after upgrading to A13 the computer is no longer stuck at that point anymore.