Crazyflie 2.0

The Crazyflie 2.0 is a second generation nano quadcopter created by Bitcraze as part of their open-source flying development platform. Available for $180 from Seeed Studio, this developer-friendly kit seemed like the perfect way to dip my toes into the increasingly popular world of hobbyist drones. I went for the developer combo package, which included the Crazyflie kit, Crazyradio, JTAG debugger, and a couple breakout/prototyping boards for $215. I also purchased a few spare batteries to extend my flight time, a decision I definitely haven’t regretted.

Crazyflie Packaging

When I received my Crazyflie 2.0, I was greatly impressed by the packaging. I guess I should have expected something nice given the amount I paid for it, but anything coming from China automatically starts with low expectations in my book. The pcb and parts were all organized and bagged separately and appeared to be of decent quality. Assembly was a breeze, with plenty of instructions and tips to be found on their web page, although no printed material was included in the box. After I assembled the copter, I noticed that the motor mounts (which also function as legs) felt a bit flimsy, and I was concerned that they would not withstand the abuse to which they could soon be subjected.

Getting the Crazyflie out of the box and into the air using the Android app over Bluetooth was a piece of cake. Keeping it in the air, however, wasn’t quite so easy. It took me a while to get used to the controls, and using touchscreen joysticks certainly didn’t help. Fortunately, hooking up a PS4 controller significantly improved the experience. The Android app has a number of limitations, and needs some more development work, so I quickly switched over to the PC client using the Crazyradio and PS4 controller. The PC client is more complete, and includes features such as sensor feedback, data logging, and hover mode. When placed in hover mode, the Crazyflie attempts to maintain a constant altitude using its built-in altimeter and IMU. This feature is still under development according to the Crazyflie wiki, and it shows, but it is usually better than trying to hold altitude manually. With an ever-expanding feature set, I’m sure the PC client will only get better with time.

Crazyflie PC Client

I was very impressed with the durability of the Crazyflie, especially considering my initial misgivings. I suppose the feather-light weight of the quadcopter helps to minimize damage, but I certainly did a good number of terrible things that could have easily destroyed it. I ended up breaking off several of the legs over the course of a few days, but since each mount has two legs, it can carry on just fine without a few of them. Thankfully, a few extra motor mount/legs are included in the kit.

Because the Crazyflie was designed with developers in mind, the creators have gone to great lengths to ensure that development is accessible to everyone. They have detailed instructions on the Crazyflie wiki page on how to set up development environments for each of the components, and have even created a virtual machine image with all of the development tools pre-loaded. Better yet, they added wireless flashing on the quadcopter, so new firmware can be uploaded on the fly. These features, paired with their development “decks” (add-on breakout/prototyping expansion boards), open up endless development possibilities. Anyone who has dabbled in coding should be able to dive in and add something new.

All-in-all, the Crazyflie is an entertaining toy to play with. It may not be capable of any real work, such as carrying a camera, but it is very fun to fly around and its small size makes it possible to fly indoors. Probably the most attractive aspect of this quadcopter, however, is the development opportunities it opens up. For example, it would be an ideal platform for a flying robot swarm. Or it could be programmed to autonomously navigate using distance sensors. Plus, if you add some cool features, I’m sure the community would appreciate contributions to the source code.

Background

If you have a working BOPM installation, you are trying to prevent abuses of your IRC network effected through anonymity services such as proxies. BOPM has built-in support for scanning for open proxies. It also has support for looking up clients in DNSBLs, which are used to publish lists of misbehaving or malign hosts. One such DNSBL, called TorDNSEL, provides a way to check users connecting through the Tor anonymity service.

As discussed at TorDNSEL’s information page, the purpose of this service is to provide finely-grained information about whether a client’s connection could be through a Tor exit node. Tor exit nodes can be configured with advanced exit policies which specify the sorts of direct outbound connections a Tor exit node is willing to make on behalf of its anonymous client. For example, a Tor exit node administrator could disallow his node to make connections to government sites and disable outgoing connections on common IRC ports. If a Tor exit node is run by an administrator who is interested in also connecting to an IRC network, that administrator would disallow outgoing IRC connections. Thus, any IRC connection made (on a common IRC port) through that node would be a legitimate connection made by a user on that host and not a connection from an anonymous client. The TorDNSEL DNSBL lets—and requires—networks which use it to take this into account.

Prerequisites

This short guide assumes that you have successfully configured BOPM to connect to your IRCd, parse oper notices informing it of client connections, and issue a G/Z:line or SHUN for some other event which identifies a client as using a particular anonymity service.

Configuring BOPM

As TorDNSEL’s information page documents, performing a TorDNSEL lookup requires the IRC client’s IP A.B.C.D, the port of the service being accessed P, and the public IP of the IRCd E.F.G.H. With these parameters, a query would be an A record lookup of the domain name D.C.B.A.P.H.G.F.E.ip-port.exitlist.torproject.org. If the response was NXDOMAIN, then either there is no Tor exit node at A.B.C.D or, if that IP identifies an exit node, that node is unwilling to connect to E.F.G.H on port P because its exit policy forbids such a connection. If the response is 127.0.0.2, then there is a Tor exit node at A.B.C.D which would willying connect to E.F.G.H on port P. From this information, we can produce a BOPM blacklist block:

OPM {
    # …
    blacklist {
        name = "P.H.G.F.E.ip-port.exitlist.torproject.org";
        type = "A record reply";
        reply {
            2 = "Tor exit server";
        };
        ban_unknown = yes;
        # GZLINE issuing a 7-day network-wide zline with UnrealIRCd-compatible syntax
        kline = "GZLINE *@%i 7d :You are connecting from a Tor exit node willing to connect to E.F.G.H:P";
    };
    # …
};

The above blacklist should be copy-pastable into your bopm.conf‘s OPM section. But, remember to replace E, F, G, and H with the respective components of your IRCd’s IP address. In the name line, it is intended that the components of the IP are in reverse order. This is because the right end of a domain is more general and the left end is more specific whereas in the first component of an IP address is most general and the rightmost component is more specific.

Also, note that you shouldn’t copy the … into your bopm.conf; each of these is just a placeholder indicating that you probably already have other blacklist blocks which should be preserved defined inside the OPM block.

One last note about this blacklist entry. If your IRC network, like many networks, allows connections to multiple ports, you must specify a blacklist entry for each port. For example, 6667 is the port an IRC client will try, by default, to use when connecting to an IRCd. But if a client wants to use SSL (without STARTTLS), you might have instructed your IRCd to listen for SSL connections on port 6697. A side effect of TorDNSEL’s specific entries is that a tor exit node may be instructed to deny outbound connections on port 6667 yet allow them on 6697. Since BOPM cannot (AFAIK) be configured to automatically choose a value for P, you must create a blacklist block for each IRCd public IP and port combination.

Breakdown

OPM {
    # …
    blacklist {
        name = "P.H.G.F.E.ip-port.exitlist.torproject.org";

Here you specify your server’s public IP, E.F.G.H, in reverse as H.G.F.E as well as the port your IRCd is listening on, P. BOPM will prepend the IP of the IRC client which connects, A.B.C.D, in reverse order as D.C.B.A when it checks if the client is in this TorDNSEL.

        type = "A record reply";

This specifies that BOMP should take the IP address the DNSBL returns and interpret that as a response. DNSBLs generally use IPs in the reserved localhost range, 127.0.0.0/8, to avoid pointing to IPs owned by third parties.

        reply {
            2 = "Tor exit server";
        };

This is the list of potential DNSBL responses which you anticipate from TorDNSEL. If the DNSBL returns NXDOMAIN (which means, “I don’t know about this doain”), BOPM will ignore the answer and assume the client is not in the DNSBL. However, if the server responds with an IP such as 127.0.0.2, BOPM will subtract 127.0.0.0 from the IP and then look for the result 2 in this reply list. If it finds an entry, it performs the action in kline discussed below.

TorDNSEL currently only defines two possible responses. NXDOMAIN indicates that the node would not connect to E.F.G.H:P on behalf of a Tor client. 127.0.0.2 or, as BOPM interprets it, 2 indicates that there is a Tor exit node at A.B.C.D which is willing to connect to your IRCd.

        ban_unknown = yes;

This line states that, if the DNSBL responds with an IP other than those handled in the reply block, it should assume that the client still should be banned. The TorDNSEL guide states Other A records inside net 127/8, except 127.0.0.1, are reserved for future use and should be interpreted by clients as indicating an exit node. This means that the TorDNSEL project reserves the right to add a new response, such as 127.0.0.3, which would indicate a subtly different sort of tor exit node. Until this new response is defined, all we know is that the IRC client probably should be banned by BOPM.

        # GZLINE issuing a 7-day network-wide zline with UnrealIRCd-compatible syntax
        kline = "GZLINE *@%i 7d :You are connecting from a Tor exit node willing to connect to E.F.G.H:P";

This is the IRC command which BOPM will issue when a client is listed in TorDNSEL. The above command will set a network-wide ban on the user’s IP which will last for 7 days using UnrealIRCd‘s syntax. A Global Z:Line is an efficient ban as the client’s connection can be closed by the IRCd before the IRCd looks up the client’s hostname. The reason listed with the GZ:Line is formulated so that the IRC user will understand exactly why he was banned.

    };
    # …
}; 

Be careful when editing your bopm.conf. Don’t forget any semicolons; even the ones after closing curly braces (}) are ncessary. If you’re reading this guide, you hopefully don’t need this advice ;-).

Testing

Once you have added the necessary configuration directives to your bopm.conf, you should test and check that BOPM catches the Tor exit nodes which are willing to connect to your IRCd. If BOPM was already running, do not forget to rehash it (BOPM’s readme suggests that /KILL BOPM (rehashing) is a convenient way to force BOPM to reread its configuration and reconnect). The following uses BOPM’s in-channel command interface to ask BOPM to scan an IP and check if it would be banned if a client connected from that IP. This requires that you have properly configured BOPM to join a channel with an IRC::channel block. An alternative test would be to just connect to your network through Tor, but that is probably more involved.

To check if your BOPM would detect a Tor IP, first find a Tor exit node (if using list list, ensure to choose an IP for which the “Exit Node?” column has “YES”). Then join the channel where BOPM is and issue the command BOPM check IP, where you replace BOPM with the nickname your BOPM bot is using and replace IP with the Tor exit node IP you looked up. A successful detection will look something like the following:

-!- BOPM2 [~bopm@Clk-NNNNNNNN] has joined #opers
<&binki> BOPM2 check A.B.C.D
< BOPM2> CHECK -> Checking 'A.B.C.D' for open proxies on all scanners
< BOPM2> CHECK -> DNSBL -> A.B.C.D appears in BL zone 6667.H.G.F.E.ip-port.exitlist.torproject.org (Tor exit server)
< BOPM2> CHECK -> DNSBL -> A.B.C.D appears in BL zone 6697.H.G.F.E.ip-port.exitlist.torproject.org (Tor exit server)
< BOPM2> CHECK -> DNSBL -> A.B.C.D does not appear in BL zone 6900.H.G.F.E.ip-port.exitlist.torproject.org
< BOPM2> CHECK -> DNSBL -> A.B.C.D appears in BL zone 7000.H.G.F.E.ip-port.exitlist.torproject.org (Tor exit server)
< BOPM2> CHECK -> All tests on A.B.C.D completed.

In this scenario, the port 6900 was inside of a reject range policy on the Tor exit node I selected. For some odd reason, it seems that this port is part of a range which is commonly disabled in Tor exit nodes. Yet, the Tor exit node I chose admits that it is willing to connect to my IRCd still and will be banned because of one of the other OPM::blacklist blocks I have defined, such as the one for port 6667.

In your own tests, you might encounter Tor exit nodes which BOPM does not flag as needing to be banned. There are multiple reasons for this. First of all, you may have selected a Tor exit node with policies which disallow Tor clients to access IRC through it. Thus, you must try with multiple exit nodes randomly selected from some listing of Tor exit nodes before despairing. If you have checked multiple hosts and your BOPM refuses to recognize them, you may have misconfigured your BOPM’s blacklist entry. Double-check that you have put your correct server’s public IP in reverse order properly along with the correct port in the blacklist::name entry. Test that BOPM’s DNS is working by looking up D.C.B.A.P.H.G.F.E.ip-port.exitlist.torproject.org, perhaps using the getent hosts or dig tools. Remember to rehash BOPM (by /killing it with your /oper powers perhaps) after editing bopm.conf.

I was introduced to the bash builtin /dev/tcp by warg the other day on x-tab#chat. He explained a basic use of this device by demonstrating how to download wget’s compressed tarball. The download process itself can be done with pure bash, but some post-processing of the downloaded file must be done to remove HTTP headers. I document warg’s application of /dev/tcp here because I found the idea fascinating and want this documentation for myself ;-).

Connecting and Downloading

To read about the /dev/tcp builtin for yourself, check out the following:

$ info '(bash) Redirections'

With the exec line we initiate the connection, allocating a file descriptor and storing the numeic file descriptor into the HTTP_FD variable. Then, with the echo line, we send an HTTP request through the descriptor to the server. After sending the request, we process the server’s response with the sed line which skips over the HTTP headers sent by the server and stows the results into wget-latest.tar.gz. Note that this last command will sit around for a while. It is with this command that the builk of the data transfer is performed. And, since you’re using shell redirections to download the file, you cannot see the download progress. Instead, wait for the command to complete. This also involves waiting for the server to time out your connection since it supports pipelining. After this process is completed, the wget-latest.tar.gz file is as your disposal.

$ WGET_HOSTNAME='ftp.gnu.org'
$ exec {HTTP_FD}<>/dev/tcp/${WGET_HOSTNAME}/80
$ echo -ne 'GET /gnu/wget/wget-latest.tar.gz HTTP/1.1\r\nHost: '\
    ${WGET_HOSTNAME}'\r\nUser-Agent: '\
    'bash/'${BASH_VERSION}'\r\n\r\n'  >&${HTTP_FD}
$ sed -e '1,/^.$/d' <&${HTTP_FD} >wget-latest.tar.gz

Now you have a wget source tarball on your machine. As long as you have tar and a compiler on the machine, you are well on your way to downloading stuff using a self-compiled wget. In the commands above, you may replace “gz” with “bz2” or “lzma” for smaller downloads if the machine you’re using has bzip2 or xz-utils installed. And, of course, it should not be too hard to repurpose the above code to download a particular version of wget or even a completely unrelated software package.

Please feel free to point out problems with this approach or give pointers on porting this to other environments :-).

There are numerous guides about setting up Google Voice and an incoming sip number for free outgoing calling. Sadly, all of the guides I found were written for FreePBX or some other Asterisk bundle, and also used a shell script to do much of the work (scary!). I have compiled the minimal amount that you need to put in your asterisk conf files to make things work, GUI-free and variant-independent.

Prerequisites

First off, you need a sip number. I recommend sipgate or ipkall (I use sipgate, it’s much more user-friendly). If you google around, you’ll find out how to set up your sipgate/ipkall number as an incoming number in asterisk, I won’t waste time covering it here.

Secondly, you need a google voice number. Once you get said number, turn off call presentation. Also, assign the account a password that you don’t mind having plaintext in a conf file. In addition, you must add your incoming sip number as a phone in google voice. I’d recommend connecting a softphone to your sip number to set this up with google’s verification call, or redirect all incoming calls in Asterisk to your extension.

Thirdly, you need pygooglevoice. Download and install it, or use python’s easy_install command.

The outgoing rule

Now for the actual configuration. First you need to set up an outgoing call rule, so all calls to the outside world (in this case, 10-digit numbers preceded with a “9”) are directed though google voice.

[CallingRule_LocalCalls]
exten = _9XXXXXXXXXX,1,Goto(custom-gv,${EXTEN:-10},1)

Explanation: Any outgoing 10-digit number prefixed with a 9 will match this rule and go to the custom-gv section which we will set up later. The number that was dialed is passed (the “-10” excludes the 9 prefix from this) at the first dialplan rule.

The GV dialer

Now we need to set up the custom-gv section:

[custom-gv]
exten => _X.,1,Verbose(0, Custom-GV Preparing to call and park call at number ${EXTEN})
exten => _X.,n,Wait(1)
exten => _X.,n,Playback(pls-wait-connect-call)
exten => _X.,n,System(gvoice -e me@me.com -p GVPassword call ${EXTEN} IncomingNum &)
exten => _X.,n,Set(PARKINGEXTEN=701)
exten => _X.,n,Park()

Explanation: After you dial an outgoing number, you’ll be dropped in here. The Verbose() function tosses some output in debug level 0 and up (see the console for this output). The System() command dials the number with google voice. Make sure you change the items in strikethrough to your own personal information. The call is then parked on extension 701 (70X extensions for parking are default. Switch to your parking extension range if you are using non-default options).

Routing GV callbacks

Now you need to set up an incoming call rule. Direct all incoming calls from your sip number at this rule.

[incoming-call-sifter]
exten = s,1,NoOp(CIDredirect)
exten = s,2,Verbose(0, Got incoming CID ${CALLERID(num)}, redirecting…)
exten = s,3,GotoIf($[“${CALLERID(num)}” == “GVNumber“]?custom-park,s,1)
exten = s,4,Goto(section-to-route-normal-incoming-calls,s,1)

Explanation: If your google voice number rings your PBX, you know that it’s connecting you to the call you just dialed, so we need to reconnect it to the extension you dialed from. We’ll handle linking of the incoming GV call and your outgoing call (which is now parked) in the next section (custom-park).

Bringing it all together

The custom-park section links a google voice incoming call (which is actually ringing the person you originally dialed) with your original outgoing call (which is parked).

[custom-park]
exten => s,1,Verbose(0, Got incoming GV Callback! Connecting to your original outgoing call…)
exten => s,2,ParkedCall(701)

Explanation: After you dialed your external number, your call was parked as google voice started dialing the other number. This section joins your outgoing call with google voice’s incoming call, so you are connected to the party you originally dialed.

You’re done!

[pullquote]Have comments, questions, or need clarification? Leave a comment![/pullquote]

Well that turned out to be a bit longer than I expected, but if you know what you’re doing, you can just ignore the italicized text.

It looks like getting free data access on iDen handsets is going to end, likely on or before 6/20/10 according to this Sprint document (credit Engadget). Coincidentally, this is the same day that the Motorola i1 is released, the first Android phone on the iDen network. With this phone, Sprint would needed to lock down iDen data access a bit harder than blocking the phone’s built-in browser (the status quo), so the change will affect all phones on the iDen network (Boost and Nextel).

This also means that getting mobile connectivity for your Arduino will no longer be free. Boost mobile’s data rates run at $.35/day.

Update: 6/20 has passed, and I still have data access.

Rubber rafts were used for tube maintenance and installation

The Super-Kamiokande consists of a 41m tall by 39m wide stainless-steel tank filled with purified water. The walls of the tank are lined with 13,000 photomultiplier tubes (think night vision goggles for cosmic rays). The photomultipliers amplify the cosmic rays and measure them, sending data back to a central computer system. Very accurate information regarding the ring direction and type of neutrino sensed can be derived from the time and magnitude measurements of the photomultiplier tube.

Worker with Photomultiplier Tube

In 2001, one of the photomultiplier tubes imploded, setting off a chain reaction of imploding tubes in the detector tank. The detector was restored by removing the damaged detectors and evenly distributing the remaining detectors. Full reconstruction did not take place until 2006, when over 6,000 detector tubes were replaced and covered with acrylic shields to prevent future implosion.

Installing the final PMT panel

Over many years, the Super-Kamiokande and predecessors have detected many solar phenomena, detected data from exploding stars, and could possibly help us understand more about the formation of matter in the future.

For more information about the Super-Kamiokande and for high-resolution photos (albeit a slow server), check out the official site. Wikipedia also has a concise article regarding the Super-Kamiokande and neutrino detectors in general.

Photos graciously provided by Kamioka Observatory at the University of Tokyo.

Popularized with the ever-present  iPhone and expanding into the tablet and desktop sector by companies such as Dell and HP, multitouch is becoming an interesting addition to today’s user interfaces. Overseas companies, such as Asus, are also taking advantage of the technology in new inexpensive tablets; even Gateway is offering a mulititouch tablet these days. Despite the popularity of multitouch, especially on the mobile platform, it seems like a technology with stunted growth and limited applications.

Key points (if you’re too lazy to read the article)

• Today’s interfaces are not designed for multitouch
• Multitouch would require redesigning and rethinking of most GUIs
  • Multitouch often wastes screen real estate
  • With multitouch, one often can’t see what’s under one’s finger
  • Multitouch requires larger on-screen items for finger interaction
• Do we need multitouch? What advantages does it pose?
  • Multitouch provides a more organic interface between human and computer
  • Multitouch allows simultaneous on-screen manipulation of multiple objects

No GUI Support

Most modern GUIs have little to no support for multi-touch technology. One prime example of this is Windows 7, which came with multitouch built-in, but the software updates have little impact on end-user experience. Multitouch is still limited to a specific audience in Windows 7, as navigating through the “All Programs” in the start menu, clicking on links in web pages, and using system tray icons are all quite challenging using one’s fingers. Also, multitouch gestures are not well-implemented into the operating system. To be extremely effective, Windows should have bindings for custom gestures, or at least include more default gestures for the base operating system itself.

Current applications are also severely limited with multitouch interactions, as most applications available today have small hard-to-tap virtual buttons. Including larger buttons wastes screen real-estate and can be a bit unsightly. Many applications also require keyboard input to accomplish a variety of functions. It would be extremely challenging to implement numerous keyboard-based functions into on-screen gestures and buttons. One other prominent issue with touchscreens in general is that one’s finger obscures the item that is being clicked, which makes clicking small objects extremely challenging.

No Need

Next comes the big question: do we really need multitouch? Many people have the opinion that navigation is much faster with a keyboard and mouse than a touchscreen. This is true for most applications, such as web browsing that involves a good deal of typing and link-clicking.

Advantages

Despite the downsides stated, multitouch does provide some advantages to human-computer interaction. For instance, multitouch allows manipulation of multiple objects, or multiple characteristics of objects, at the same time. One simple example of multi-object interaction would be a digital soundboard, where sliders and dials must often be adjusted simultaneously. This would be impossible using a single mouse pointer, and would not allow precise control of speed with a keyboard.

Multitouch also provides for more organic interaction with computers, allowing the manipulation of digital data in a more physical manner. This interaction could be flipping through photos, organizing files, or moving windows around the desktop.

Image courtesy of RobotSkirt