RC Servos are popular among modelling and robotics enthusiasts because of their simplicity. They take a pulsewidth-encoded input, and turn accordingly with relatively high torque. They have their disadvantages, for example one cannot tell if the servo was able to get where it was sent, but their low price and the fact that driver and gear box are integrated make up for that. Also, Conrad sells them for 3 € a piece, so I bought some.

My first idea was to control them with firmware-usb, however, the high load imposed on the controller by usb makes software-pwm erratic, and also, implementing the usb communicating device class is not possible for low-speed devices.

The servo controller prototype together with one regular sized RC servo, and one miniservo

The path I followed that resulted in the servo controller pictured above was, to use an FT232R usb-to-uart converter and an Attiny 2313a microcontroller to provide the software pwm. There are some other possibilities, like taking an at90usb or another microcontroller with usb, but FTDI has nice chips, good support, and one can get usb pids from them, and remans flexible. If 12 servos are not enough, the software should easily be portable to a bigger avr, the chips are widely avalable and low in cost: I got the attiny for about 1 € and the FT232RL for about 2.5 € at CSD.

The full schematic is available as pdf and in the kicad format, and so is the pcb layout. Feel free to rebuild it.

This was my first project using kicad and my first project using surface mounted technology, and surprisingly both made few problems. Even soldering the tqfp-sized FT232RL without solder resist worked well, though i needed lots of light and a good magnifying glass.

The copper side of the assembled pcb, showing the results of my subpar soldering skills

Hardware

You will need:

• One FT232RL USB-to-UART convertor
• One Attiny 2313a (or the older, nrfnd, attiny2313) avr microprocessor.
• An USB B-type connector
• A 6-pin connector for your AVR-ISP programmer.
• Connectors for the servos. I used simple multi-pin connectors and some colored insulating tape to mark plus, minus and signal.
• A connector for your power supply.
• An optional jumper to power the servos from usb. Since the device does not ask the usb host for more power, this is outside the usb specifications. however, with small miniservos it is convenient, as you do not need an extra power supply.
• One 4.7 µF electrolyte capacitor
• Three SMD 100 nF ceramic capacitors and two 10 kOhm resistors. The plan calls for size 0603, but the resistors I used were actually 0805, and fitted also well.
• A printed circuit board. With the right equipment, you can make this yourself. Or you can have one made for you at various companies

All the parts together cost about 5 € (with a self-made pcb).

Software

The software provides a rather minimalistic interface. To send commands, open the serial port at 9600 baud, using your favorite terminal program, I used gtkterm.

The available commands are:

• Typing v shows the device name, a link here, and the software version.
• Typing l lists the servo numbers and the corresponding pwm settings. The pwm settings are the number of cpu cycles the servo should get a high signal level.
• Typing d shows the softpwm table, a list of when which signals should go from high to low. This list is calculated from the pwm settings, it’s mainly there for debugging purposes.
• Typing s (servonumber) (new value) sets the pwm value for the selected servo. Be sure to send a newline character or other whitespace to execute the command.

Since RC servos typically want a 1 ms pulse (at 8 MHz this are 8000 cpu cycles) for one end, and a 2 ms pulse (similarly, at 8 MHz this are 16000 cpu cycles) for the other end, you would in linux do something like

stty -F /dev/ttyUSB0 9600
echo "s 11 8000 " > /dev/ttyUSB0
echo "s 10 16000 " > /dev/ttyUSB0

to send servo 11 to one end and servo 10 to the other. If you have other serial devices, the device might not be /dev/ttyUSB0, but /dev/ttyUSB1 or so. Should this be a problem, you can create a udev rule to create a symlink. Note that the actual pulse lengths required to go to the mechanical end of the servo differ widely between servo types, I do not know if there is some standard, if you do, please tell me.

A QT frontend to turn servos by turning dials

For some cases, like finding the end positions of the rc servos, it is convenient to have a graphical user interface, which is also available.

Usage with embedded linux devices

In most households, many devices run linux and have an usbport. however, without a modified firmware most cannot connect to serial usb devices. I tested a fritzbox 7270 (possible with alternative firmware freetz, not with the original firmware), a dreambox dm 7000(no success, and alternative firmwares are lost in the mists of time), and an Asus oplay hdp-r1(also no success, and alternative firmwares seem to be not yet available). So, unless you have a device that runs openwrt by default, chances are this won’t work without some work.

List of things still to do

• As seen on the pictures, the avr isp connector is slightly too large, so either a smaller one has to be used, or only 8 servo connectors have place. For testing purposes, this was enough, but a new hardware revsion is necessary.

usbservo_hardware.tar.gz

usbservo_software.tar.bz2

qusbservoc.tar.gz

usbservo_schematic.pdf

usbservo_pcb.pdf

ytplay wraps around youtube-dl.py, it searches for a video, orders youtube-dl to get it, and starts playing it in vlc.

Usage is simple:
> ytplay foobar
will search youtube for videos about foobar and play the first one found.

The code is still quite dirty, especially the subprocess part. However, it should work, have fun!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

#!/usr/bin/python
# -*- coding: utf-8 -*-
#		parser.add_option('-P', '--play', action='store_true',
#				dest='play', help='play in vlc', default=False)
 
from optparse import OptionParser
from subprocess import Popen, PIPE
from urllib2 import urlopen 
from urllib import quote_plus
from re import search, match
from os import system
 
parser = OptionParser(version='2010.02.13')
 
parser.add_option('-p', '--player',
dest='player', metavar='PROGRAM', help='media player to use', default='vlc')
 
(opts, args) = parser.parse_args()
 
if match("http://",args[0]):
	videopageurl = args[0]
else:
	searchargs = '+'.join(args)
	searchurl = "http://www.youtube.com/results?search_type=&aq=f&oq=&search_query=" + quote_plus(searchargs)
	searchresult = urlopen(searchurl).read()
	p=search(r'(watch\?[^"]*)',searchresult)
	if p==None:
		print "No Videos found"
		exit()
	videopageurl="http://www.youtube.com/" + p.group(1)
 
 
print "Starting youtube-dl for " + videopageurl
ytdl = Popen("youtube-dl.py -t -b " + videopageurl,shell=True,stdout=PIPE)
 
while not ytdl.stdout.closed:
	line = ytdl.stdout.readline()
	print line,
	if line == '': exit()
	p = search(r'\[download\] Destination: (\S*)',line)
	if p != None:
		print "Starting player: " + opts.player + " " + p.group(1)
		system(opts.player + " " + p.group(1) + " &")

ytplay

And that is basically everything to say, enjoy the little applet.

Installation

Make sure gpsd is installed and set up properly. Also make sure the python bindings are installed.
In Ubuntu you would need to:

sudo apt-get install gpsd python-gps
sudo dpkg-reconfigure gpsd
sudo apt-get install python-plasma python-dev

After those are installed, you can proceed to install the plasmoid with plasmapkg -i.

Problems and TODOs

This is all rather dirty and bloated. The correct way to do it would probably be to write a data engine for plasma, which would provide the positional data. Maybe someone will do it, especially if Marble will one day be able to support overlays integrate GeoClue or something similar.

Right now the data travels from the GPS device to the PC in the form of NMEA sentences, gets then converted into gpsd’s own format, python-gps connects to gpsd over TCP port 2947, interprets the gpsd output, hands it over to the applet, which reformats the data yet again. For something so useless that just wastes too many CPU cycles. Interpreting GPS data entirely in python is not hard, but still a bit harder than with gpsd, especially if one wants to cover a lot of GPS devices. Don’t get me wrong, gpsd does its job quite well, it is just a bit overkill for this task.

Another improvement would be readable coordinates. Something like “10 km northwest of Zürich” or even “200 meters south of Sternen Oerlikon, Zürich” would really be much more useful.

Update February 2010: Version 0.16 now uses KDE’s geolocation data engine. This drops the (direct) dependency on gpsd, and allows for ip-based location – unfortnately i now can no longer get my gps to work with it, hoping for kubuntu lucid.

gps-plasmoid_0.16.plasmoid

gps-plasmoid_0.15.plasmoid

gps-plasmoid012.png

One solution, if you don’t have enough IO ports to spare, is to use another Display, like serial cellphone displays, which are cheap and color is a great thing to show off. Or you can expand the number of IO lines by using a shift register or TWI device. This is one such implementation using a 74hc164 shift register. It is based on an implementation by Peter Dannegger. If you prefer to use a 4094 cmos shift register, there are also schematics floating around the net.

 

The demo software will print a hello world message onto the display, it is written for AVR microcontrollers, it should work – after modifying the ports and pin numbers – on almost any AVR. Peter Daneggers original software is written for 8051 µCs, I don’t know of any code for PICs.

lcd.tar.bz2

lcdshift.pdf

lcdshift.sch

lcdshift.brd

For companies in road transport that means, although in theory they get nice data about their drivers and vehicles, in practice they have to pay a lot of money for the digital tachograph and the associated equipment, which is then used against them – the old fraud schemes no longer work, the machine cruelly gives every police officer the driving times of the last 28 days (and could give much more).

The usability of the devices I’m familiar with is also abysmal. It just takes forever to read out the data (9600 baud per default, 115000 baud maximal, but i guess the company’s software does just the former), and the drivers have to keep track of their times manually – just not up to par with 2009 technology.

The company also had just a very bad software for analyzing the data recorded by the card and the digital tachograph, so I was asked to write a simple visualization program.

Compiling

You can get the program files from this page, or from the development page at Sourceforge.
Since so far there is no binary distribution for the program, you will have to compile it yourself.
To do that, you need a c++ compiler, parts of the boost library (specifically program_options and shared_ptr) and the Gnu MP library, wich is used to check the various RSA signatures. Once all those are installed, typing make/make install should work fine. On Ubuntu systems, you will need to do something like:

svn co https://readesm.svn.sourceforge.net/svnroot/readesm readesm
sudo apt-get install libboost-program-options-dev libgmpxx4ldbl  libgmp3-dev
make
sudo make install

You can of course also use checkinstall instead of make install, or type make package, which invokes checkinstall.

Running the program

In most circumstances, you will run the program from the commandline like this:

readesm --infile foo.esm --outfile bar.html --format=html

Alternatively, if no output file is specified, stdout is used. For KDE users, i wrote a little wrapper script named readesm-wrap-kde.sh. It will get installed my typing make install

Security

It is a really pleasant surprise to see a nice security model in the digital tachographs, considering the rules for the security implementations were made by politicians. Both cards and vehicle units work with 1024-bit RSA keys, and each vehicle unit has its own key, with an certificate signed by the member state, which in turn is signed by an European master key. Data is hashed with SHA-1, subsequently padded and signed by the vehicle unit, and that signature appended to the readouts. The law even states that the companies have to store the data in this signed form, so there is little chance to tamper with the data, once recorded.

Since the most likely attacker – the evil manager who wants to exploit the drivers – has physical access to the card and vehicle unit, which contain the private keys, even 1024-bit RSA provides no absolute security. The manager could try a timing attack, or take a really close look at the storage, both times avoiding having to solve the RSA problem.

The connection from tachograph to sensor is also secured, using Triple-DES. The week point here is the sensor – a successful attack against the sensors some DAF trucks are equipped with is to disturb it using strong permanent magnets, thereby preventing it from recognizing the changing magnetic fields.

All possible attacks against the security system however face the problem of being unveiled by police checkpoints or a cross-correlation of the faked data with data from other sources, for example the toll systems recording every few highway kilometers in Germany.

So, although I could sell manipulation programs for quite some money, all I can offer is a program that can detect such attacks

 

readesm.tar.bz2

What does it do? Nothing useful. You plug it in, and the various LEDs blink wildly, one letter at a time, two letters at a time, all on, all off.

I’m not particularly proud of this board. The matrix design is just painful to route on an one-sided PCB, so please don’t do it, especially if you plan on doing something similar with more than three letters. I’d like to use something like the AS 1110 for something similar, but there are just no distributors for those chips.

Nevertheless, if you know someone named Eva who likes to solder a bit or who just likes blinking things, this might be a nice present.

Things to take care of:

• Energy source: I used some old wall wart for this. The used 7805 is quite robust, but not very efficient. Use something between around 8 V to 15 V, and check the polarity, which is unfortunately not standardized.
• Since the LEDs are driven only 1/4th of the time, you can in theory use higher currents than if driven all the time.

 

blinking-eva/eagle-files.tar.bz2

blinking-eva/firmware.tar.bz2

blinking-eva/blinking-eva-board.pdf

blinking-eva/manual-german.pdf

Usage

• Start the Program, add a parameter for the port your nmea device is attached to (/dev/ttyUSB0 is the default
• Start google earth or something, load the generated kml file (/tmp/posdate by default)
• Exit the program by pressing ctrl-c, track data will be written to /tmp/track-some time.gpx

Guess I should code something with extra geek value now.
It might be comfortable to have google earth automatically reload the file, so instead open sth. like

1
2
3
4
5
6
7
8
9
10
11
12

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<NetworkLink>
	<name>GPS</name>
	<flyToView>1</flyToView>
	<Url>
		<href>/tmp/posdata.kml</href>
		<refreshMode>onInterval</refreshMode>
		<refreshInterval>10</refreshInterval>
	</Url>
</NetworkLink>
</kml>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133

#!/usr/bin/python
"""
Script to read nmea data from a GPS mouse
Copyright (C) 2008  Andreas Goelzer
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.
 
You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
This program reads data from a nmea device (uses the GGA sentence),
and creates a google kml file with the current position and the path
leading there. Additionally, a gpx file is generated containing the
track data with time information.
"""
 
from serial import Serial;
from time import strftime, gmtime;
from optparse import OptionParser;
 
 
hist = "";
gpx = "";
 
kmlmask="""<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.0">
<Document>
	<Placemark>
		<name>Your Position</name>
		<Point>
			<coordinates>%s</coordinates>
		</Point>
	</Placemark>
	<Placemark>
		<name>Previous positions</name>
		<description>Path that lead you here</description>
		<LineString>
			<coordinates>%s</coordinates>
		</LineString>
	</Placemark>
</Document>
</kml>"""
#			<altitudeMode>absolute</altitudeMode>
 
gpxmask = """<?xml version="1.0" encoding="UTF-8" standalone="no" ?><gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3" xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtension/v1" creator="Colorado 300" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.garmin.com/xmlschemas/GpxExtensions/v3 http://www.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd http://www.garmin.com/xmlschemas/TrackPointExtension/v1 http://www.garmin.com/xmlschemas/TrackPointExtension/v1/TrackPointExtensionv1.xsd">
<trk><name>%s</name><trkseg>%s</trkseg></trk></gpx>"""
 
def gpstime():
	return strftime("%Y-%m-%dT%H:%M:%SZ",gmtime());
 
def readlatlon(value,inverse):
	lat = float(value);
	lat2 = int(lat) / 100;
	lat = lat2 + (lat - 100 * lat2)/ 60; 
	if inverse:
		lat = -lat;
	return lat;
 
def calcchecksum(checkstr):
	cs = ord(checkstr[0]);
	for i in range(1,len(checkstr)):
		cs ^= ord(checkstr[i])
	return cs;
 
 
class sentencevalidator:
	"Check checksum and other stuff and split to fields"
	def __init__(self,line):
		if(line[0] == '$' and line[-5] == '*' and calcchecksum(line[1:-5]) ==  int(line[-4:-2],16)):
			self.valid = True;
			self.sentence = line[3:6];
			self.data = line[7:-5].split(',');
		else :
			self.valid = False;
 
parser = OptionParser(version="%prog 0.1");
parser.add_option("-s", "--serial", dest="serial",
                  help="serial terminal of the gps unit", default='/dev/ttyUSB0', metavar="FILE");
parser.add_option("-g", "--gpxfile", dest="gpxfile",
                  help="GPX output file", default="/tmp/track" + gpstime() + ".gpx", metavar="FILE");
parser.add_option("-k", "--kmlfile", dest="kmlfile",
                  help="KML output file", default="/tmp/posdata.kml", metavar="FILE");
parser.add_option("-v", "--verbose",
                  action="store_true", dest="verbose", default=False,
                  help="print debug messages");
 
(options, args) = parser.parse_args();
 
gps = Serial(options.serial, 4800, timeout=1);
 
 
#on sirf chips, activate all sentences
for i in range(1,5):
	cmd = "PSRF103,0%d,00,05,01" % i;
	realcmd="$%s*%x\r\n" % (cmd,calcchecksum(cmd));
	print realcmd;
	gps.write(realcmd)
 
try:
	while 1:
		line = gps.readline()
		if(options.verbose): print line,
		s = sentencevalidator(line);
		if(s.valid and s.sentence == "GGA" and int(s.data[5]) != 0):
			lat = readlatlon(s.data[1],s.data[2]=='S');
			lon = readlatlon(s.data[3],s.data[4]=='W');
			alt = float(s.data[8]);
 
			gpx += "\n" + '<trkpt lat="%f" lon="%f"><ele>%f</ele><time>%s</time></trkpt>' % (lon,lat,alt,gpstime())
 
			position =  "%f, %f, %f" % (lon,lat,alt);
			print position
			hist += "\n" + position;
			f=open("/tmp/posdata.kml",'w');
			f.write(kmlmask % (position,hist));
			f.close();
 
except:
	0
 
f=open(options.gpxfile,'w');
f.write(gpxmask % (gpstime(),gpx));
f.close();
 
gps.close()

readgps.py

Device description

The usbmot device controls up to two small motors, 600 mA current each, 1.2 A peak each, with an atmel atmega microcontroller connected to some host device via USB. The speed of the motors can be controlled with PWM.

Compiling

Both firmware and host software are in the software package at the end of this page. In order to recompile the firmware, you will need an avr build chain (for example avr-gcc and avrdude), which you probably have if you found this page. To compile the host software, you will need a c++-compiler and the qt development package.

To compile the firmware, change into the firmware folder. Then edit the makefile and adjust device type and programmer. In order to remake the hex file, type “make hex”, and to transfer it to the device, type “make flash” (jumper 1-1 needs to be set).

To compile the host software, change into the qusbmot folder. You will need qt and libusb with their respective tools and header files to successfully compile. If both are properly installed, typing “qmake && make” should compile the program, which can then be executed by typing “./qusbmot”.

Usable AVR Microcontrollers

So far I’ve used this board only with an atmega 168. Due to pin compatibility, it should work with at least an atmega 8, 48, 88, 168. Since 12 MHz speed are needed, the low-voltage versions will not work. The firmware size is about 2 kiB, so all are a bit oversized, but in low quantities this is no problem.

USBAsp roots

The PCB is based on the USBAsp Layout. It can still be used as a programmer, however the USBAsp Firmware has to be modified since I changed the USB port and pins to use the output compare pins for PWM.

Jumper description

• JP 1-1: Self programming: Needs to be set in order to program the device, and must not be set if the device is operating. Sorry, this is a bit inconvenient, a residue of the usbasp roots.
• JP 1-2: Programmer Power: Powers the device logic from the Programmers power source.
• JP 5: coupled power: Connects the motor and logic voltages. Might work for really small motors(take care that the current of the motor is much higher when under heavy load) or strong USB power sources.

Two red LEDs hack

When all that separated my board from completion were the two 3V6 Z-diodes, I asked for help in the mikrocontroller.net – chat, and Loetmichel told me the 3.6 V Zener diodes can be replaced by 2 red LEDs each. If incorporated into the PCB, this might even look really nice, and add some information.

Free pins

in the pcb, some of the atmega’s pins are connected to pinheads, so the board can be extended. I’ve tested a rather crude servo control for PC2…PC5, but unfortunately, if there is activity on the usb bus, the timing will get disturbed and the servos will move without being told so. I guess one could use the two 8-bit timers with their pwm pins to avoid being disturbed by the high-level usb interrupt, maybe in the next version. If however you can live with a bad servo control, try the “trunk” package.

Board problems

• JP 5 is too close to the power connector.
• The L293D is a bit old and can only power rather small motors. There are some nice automotive ICs, but unfortunately, those chips aren’t that easily available. Another Problem of the L293D is the low allowed pwm frequency – with 5 kHz in a region that is acoustically displeasing.
• The holes for screws are placed randomly.
• Setting the jumpers for programming is not that comfortable. I guess I will use a USB bootloader for the next version, saves some wires, too
• Probably a lot more.

License and warnings

The software for both the microcontroller and the host is available under the terms of the GPL, in the hope that it might be useful for someone out there. In Addition to the terms of the GPL, obdev, who provide the firmware-only usb driver, kindly ask and require additional terms that especially apply as long as the shared obdev vid/pid pair is used.

The atmega, especially if powered by 5 Volts as in this device, cannot comply to the electrical part of the USB standard. Nevertheless, it works well with a large range of computers. However, there is no guarantee that it will not destroy your USB controller or your entire computer, so keep in mind the last sentence of the GPL: This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

 

usbmot_software.tar.bz2

usbmot_trunk.tar.bz2

usbmot_schematic.pdf

usbmot_pcb.pdf

usbmot_eagle_pcb.tar.bz2

So i wrote a python variant, that takes an input config(for example your distributions config) and changes the reply to “y” for all config options if the respective module is loaded(ie. if ext3 is loaded, CONFIG_EXT3_FS=y will be set).

In almost all cases you still want to tweak the resulting config file with make menuconfig. Also keep in mind that some things don’t work that easily if compiled in, for example if firmware has to be loaded from a file, the disk should be accessible.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92

#!/usr/bin/python
# -*- coding: utf-8 -*-
"""
Script to modify kernel config based on lsmod output
Copyright (C) 2008  Andreas Goelzer
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.
 
You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 
Based on a previous config and the output of lsmod, this script determines
which modules could be compiled in and generates a new config.
See http://andreas.goelzer.de/kernel-config-based-on-lsmod-output for updates
"""
 
import re;
from optparse import OptionParser;
from os import popen;
from sys import stderr, stdout, stdin;
 
parser = OptionParser(version="%prog 0.31");
parser.add_option("-i", "--infile", dest="cfgfile",
                  help="input config file", default=".config", metavar="FILE");
parser.add_option("-o", "--outfile", dest="outfile",
                  help="output config file", default="-", metavar="FILE");
parser.add_option("-l", "--logfile", dest="logfile",
                  help="file to log errors to", default="-", metavar="FILE");
parser.add_option("-s", "--sourcedir", dest="sourcedir",
                  help="kernel source tree", default=".", metavar="DIR");
#parser.add_option("-v", "--verbose",
                  #action="store_true", dest="verbose", default=False,
                  #help="print debug messages");
 
(options, args) = parser.parse_args();
if(options.outfile == '-'): of = stdout;
else: of = open(options.outfile, 'w');
if(options.logfile != '-'): stderr = open(options.logfile, 'w');
 
 
loadedmods=popen('lsmod | tail -n+2').readlines();
getmodname=re.compile(r"^(?P<modname>\w*)");
 
#prob. need to replace kernel with sth. like (kernel|ubuntu) for an ubuntu kernel source
parsepath=re.compile(r"/kernel(?P<path>/.*/)(?P<file>.*).ko")
 
wantin=[];
for module in loadedmods:
	modname = re.search(getmodname,module).group('modname');
	moduleprops=re.search(parsepath,popen('modinfo -n ' + modname).read());
	if(moduleprops):
		#search the makefile for the module name
		try:
			f=open(options.sourcedir + moduleprops.group('path') + 'Makefile' , 'r');
		except IOError:
			stderr.write('Could not find Makefile for ' + modname + '\n');
			continue
		cont=f.read();
		f.close();
		m=re.search(r"obj-\$\((?P<cfgname>[A-Z0-9_]*)\)\W*\+=\W*"+moduleprops.group('file')+r"\.o",cont);
		if(m):wantin.append(m.group('cfgname'));
		else:stderr.write('Could not determine config name for ' + modname + '\n');
	else:
		stderr.write('Could not parse modinfo for ' + modname + '\n');
 
 
 
if(options.cfgfile != '-'): 
	f=open(options.cfgfile, 'r');
	lines=f.readlines();
	f.close();
else:
	lines=stdin.readlines();
 
confparse = re.compile(r"\W*(?P<iscomment>#?)\W*(?P<cfgname>CONFIG_[A-Z0-9_]*)\W*=?\W*(?P<answer>[nmy]?)");
 
for line in lines:
	matches = re.search(confparse,line);
	if(matches and matches.group('cfgname') in wantin): 
		of.write(matches.group('cfgname')+'=y\n');
	else: 
		#if(matches and matches.group('answer') == 'm'):of.write(matches.group('cfgname')+'=n\n');
		of.write(line);

customconfig.py

That is one hell of a potential for saving goods and energy. The question is just, how would one realize it? Treehuggers would like you to not use a car, and instead use a train or a bike. But it’s cold out there, waiting for the bus. Some German politician wants people to heat to only 16 degrees Celsius, to save some money. But, even with a warm coat, that’s still chilly. Does it have to get cold out there?

Surely not. We have all those technology at hand, fulfilling our basic needs should still be possible without sacrificing too much comfort, perhaps even with gaining a little. Lets just start from the cold, and solve things from there.
Think of an, for lack of a better word, encountersuit – close that create a nice environment directly above your skin. Since several thousand years clothing hasn’t improved much. Today’s clothes might be lighter, and better tailored than the pelts the first humans wore, but, and that is something I find truly amazing, they don’t fulfill their function better if we limit our discussion to everyday clothes and exclude things like neoprene suit, body armor and arctic expedition clothing. Although temperature sensors are a couple of cents, small motors and microcontrollers are available for around 2 euro, and batteries are a bit more expensive, but still far cheaper than a designer suit – we do not use them in our clothing. At material costs less than 100 euro it should be possible to build a simple temperature-controlled suit, that would actively warm you in those cold places out there. It could also cool you down just the right amount to prevent you from sweating. On hot summer days it’ll get a bit more difficult, but perhaps with a lighter suit with some more built-in fans could solve that. And washing the suit would also be a problem.

So suppose we could build such a suit. Now we could ride a bike, the fans would prevent us from sweating, and the heater wires would keep our fingers warm. Maybe it could even heat up the air we breathe. But still, biking is not to everybodys liking. How about an electric skateboard instead? Controls could be easily integrated into the encountersuit, and it fits much better into a go to community center, take train from there scenario; it neatly fits into a backpack.

At home, we also wouldn’t have to worry that much about the temperature. we’d just have to heat enough to prevent mold, and heat the bathroom and the bedroom on those occasions where we’d slip out of the suit.

The technical component is but one part of the solution. At some occasions, you need more than an electrical skateboard. But that doesn’t mean everybody has to have 1.5 tons of steel in some garage, several people could share a car. You wouldn’t neccessarily lose comfort, you could even gain some – on some occasions you’d need a caravan, on some an offroader. Car pools and car renting services can solve that quite well, especially if people wouldn’t need a car every day at seven.

In Germany there are 55 million vehicles. for 80 million people. Suppose every car is driven on average one hour per day. That means, in theory 23 of 24 cars are not needed. Even if the sharing would be quite horribly inefficient and most people would still not go for a bus/skateboard combination, if every second car could be saved, and we evaluate every car at 10 k€, we could save 275 G€, more than the german government manages to waste spend for the greater good every year. That would be roughly 3.5 k€ per citizen, more than enough for some high-tech warm clothes.

The problem with both using devices that just can do the necessary, like the skateboard, and sharing stuff seems to be the human mind. We do not evaluate our wealth by the things we actually use, or could rent and use, but archaically by the things we do own.

And that is the world of overkill.