Guy comes by Perlmonks wondering why his Perl program is so slow to start on a Raspberry Pi. Muses that Perl may be inappropriate for small platforms like this, and that perhaps the program should be rewritten in C. Monks get salty at the thought.
So great, now that guy probably won’t be back.
Now, the program in question was I/O bound, particularly on the Astro::Sunrise module. The initial thought of many Monks was that rewriting in C would not help, but that’s not obvious. Loading the modules involved here is a big task that would be built into a single binary for a C program, plus maybe some shared libraries that will likely be loaded up anyway at boot time.
Even so, there are better ways of helping here. The program uses threads and Switch, which are both probably unnecessary. Using threads in particular is a big performance suck.
I also double-checked, and the default perl on Raspbian actually is compiled with threads. I’m sure that’s because the base Debian distro has to be compatible with any Perl script you throw at, but that’s a big, unnecessary performance suck for a little Rpi. I’ll have to check, but Hiveberry might have a more sensible compile of perl. It’s a more up-to-date 5.20, as well (Raspbian comes with 5.14). That could make for a nice performance boost.
My AeroQuad kit came yesterday. It’s a Cyclone frame with an AeroQuad32 control board. Spent most of the day at The Bodgery building it, and got most of the way through the frame build:
The plan is to put a Raspberry Pi on board that can be used for control over WiFi using UAV::Pilot, and also 1080p video.
Along those lines, I’m going back to the old WumpusRover code and getting the video streaming up to snuff. It’s ported to GStreamer1 now (instead of the original GStreamer CPAN module, which compiled against the old gst 0.10). One major item is that on a new client connection, wait for an h.264 keyframe to come down the wire before sending the client anything. There’s flags on the GstBuffer object that can do that, but they’re implemented via C macros that cause some trouble to the Glib introspection-based bindings. I’ll have to write some xs code into GStreamer1 to help support it.
(I feel like a bit of an idiot having my name on the GStreamer1 module on CPAN. With the Glib introspection bindings doing a whole lot of magic, I really have no idea how it works. I was just the one who stepped up to the plate to get it done. If someone came to me directly asking for help, I’d probably have no clue.)
I just got a Turnigy 9XR radio for a new quadcopter. I had been thinking about the Parrot Beebop, but I decided that I wanted a grown-up quad, so I got the AeroQuad Cyclone kit instead.
Now, the reason I bought the Turnigy 9XR is that it has an ATmega on board with fully customizable firmware. It even has the standard Atmel ISP port for programming.
I setup my laptop to build one of the major FOSS firmwares out there, OpenTX. Building the firmware itself went fine. The tricky part was building Companion, which is basically a big GUI wrapper around avrdude for burning the firmware. I hit an error that I couldn’t quite figure out:
$ make
[ 1%] Generating /path/to/opentx/companion/src/../../radio/src/lua_exports.inc
Generating a list of Lua exported constants in lua_exports.txt
Parsing and generating C Lua exports in lua_exports.cpp
File "../util/luaexport.py", line 28
print "WARNING: Duplicate name %s found for constant %s" % (name, CONSTANT_VALUE)
^
SyntaxError: invalid syntax
This turned out to be because my Gentoo system was setup with python3.3 to be hit by default, and the code above is still on python2.7. I still had a build of 2.7 available, though, so it was an easy matter of switching:
$ eselect python list
Available Python interpreters:
[1] python2.7
[2] python3.2
[3] python3.3 *
$ sudo eselect python set python2.7
Then follow the rest of the Companion build instructions, and switch it back to python3.3 when you’re done.
Article I wrote for PerlTricks.com:
https://perltricks.com/article/140/2014/12/15/A-Hackerspace-Webcam
In a discussion on /r/coding, people once again debated the merits of the old 80 character per line rule. My usual argument is that we want to put several code windows next to each other, so yes, we do want to limit things to 80 characters. The author of the linked piece mentions this, but I don’t think he makes a persuasive counterargument.
I might have changed my mind as 4K monitors become standard, but then someone in the discussion linked this:
http://www.pearsonified.com/2012/01/characters-per-line.php
This suggests that you should limit things to 50-100 characters per line for typographical reasons. Now, they’re mostly talking about prose writing there rather than code, but lacking studies otherwise, setting the limit to 80-100 seems sensible no matter how big monitors get.
Previous versions of Device::WebIO::RaspberryPi grabbed still images from the camera by calling out to raspistill. Given the limitations of the Rpi, this meant it had to load a program off the SD card into main memory and execute.
Meanwhile, the GStreamer framework has a plugin to read from the Rpi camera on its own. Problem was, the existing GStreamer module on CPAN was compiled against the deprecated 0.10 API, and rpicamsrc wouldn’t work against it.
I ended up asking around about 1.0 API bindings on the gtk2-perl list, and they were very patient in walking me through how to create them using Glib::Object::Introspection. Creating the bindings themselves was easy; hard part was figuring out all the magic it did behind the scenes to link to the C libraries and build Perl classes out of them.
After getting all that worked out, I released GStreamer1 on CPAN (the version number in the module name follows convention from Gtk2). Short on its heels, Device::WebIO::RaspberryPi 0.006 was released, which uses GStreamer1 to grab camera data for still images.
This greatly improves the wait time for grabbing an image in Device::WebIO::RaspberryPi. It also neatly solves a problem I’ve been struggling with since building the WumpusRover, which is that it was hard to reliably get images off the Rpi camera via Perl. With better Gst bindings, I think this is finally nailed down.
So solving my connection problems to a Pi by turning off power savings didn’t work. I’m now using a crude but effective method where the Pi pings the gateway every 2 minutes.
Start by adding this script to /etc/keepalive.sh:
#!/bin/bash
PING_HOST="10.0.0.1"
SECONDS_BETWEEN_PINGS=120
while :
do
ping -c 1 ${PING_HOST} > /dev/null
sleep ${SECONDS_BETWEEN_PINGS}
done
This script works in an infinite loop, sending a single ping every 120 seconds. Call chmod 755 /etc/keepalive.sh to make it executable. Next, call it from /etc/rc.local:
/etc/keepalive.sh &
Which will run the script on the next reboot. Call /etc/keepalive.sh & in a shell to start it running, and you’re done.
So far, this seems to make ssh connections start immediately every time. I’d like to figure out what the actual problem is, but this will do.
After letting a Raspberry Pi server sit for a while, I would often try to login over ssh and get a “Read from socket failed: Connection reset by peer” message. Pinging it would also fail, until about 20 seconds later. Then everything was fine.
(If this happens to you, the first thing you should check is your power adapter. If you grabbed an old cellphone charger, it might not be good enough. I like using the CanaKit 1A chargers.)
I suspect this is due to the power saving mode on USB (it’s a USB WiFi adapter, and I believe the Pi’s built-in ethernet is also handled over USB). Sure enough:
power/control . . . The default for all devices is “auto”, which means that they may be subject to automatic power management, depending on their drivers.
I set this to /etc/udev/rules.d/50-usb_power_save.rules: ``` ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="on" ``` Which will stop the kernel from signalling the device to go into powersaving mode. If power is a concern, then you might want to add parameters to filter the specific USB vender ID for your USB device. Or just leave it on auto mode and put up with the delay. Not 100% sure this is the real problem, but I'm hopeful. Update: nope, that didn't do it.
Copyright © 2024 Timm Murray
CC BY-NC
Opinions expressed are solely my own and do not express the views or opinions of my employer.