RAMPS + DRV8825

I have ordered this Arduino Mega 2560 + RAMPS + 5 * DRV8825 + LCD 12864 set, loaded it with Repetier firmware and found out that it works nicely, hooray!

Things to keep in mind: DRV8825 boards were configured for Vref = 1.6-1.7 V, which is way too high. This translates into output current of 3.2-3.4 A, as the formula for DRV8825 is

    I_TripMax = Vref / (5 * Rs)

Or, as Rs is 0.1 Ohm (resistors are labeled as "R100") -

    I_TripMax = Vref / 0.5

which is the same as

    I_TripMax = 2 * Vref

See these links - 
http://reprap.org/wiki/A4988_vs_DRV8825_Chinese_Stepper_Driver_Boards
https://www.pololu.com/product/2133

This current can damage your motors, so before connecting the motors to RAMPS you must adjust Vref. Thankfully it's not that hard: plug in 12 V power supply into RAMPS (Arduino is powered from RAMPS board), and measure Vref between the ground pin of DRV8825 board and top of adjustment potentiometer, as shown:

I have soldered a wire to the ground pin and wound it onto the ground probe of my multimeter because I only have two hands. With the red probe touching my screwdriver that I used to turn the potentiometer I was able to adjust Vref and check its value on the multimeter.

The first link recommends setting Vref to 0.5 V (which translates into 1 A current) and using that as the starting point to further tweak Vref. However when using puny CD / DVD stepper motors, I think 1 A is waay too high, so I started with ~0.1 V, and went up to 0.16 V. With this Vref my motor works just fine and doesn't seem to overheat. I may end up increasing Vref when I add mechanical load to the motor though.

Supervisor program groups

"Supervisor is a client/server system that allows its users to monitor and control a number of processes on UNIX-like operating systems."
Simply put, it's a program that can run other programs for you. It does its job, it is mature and straightforward - just define your programs in a plain Windows-INI-style configuration file (although Supervisor doesn't run on Windows) and you're set.

But what if you've got a whole bunch of programs to run, isn't starting/restarting/stopping them one-by-one using supervisorctl going to be a major hassle? Yes, but Supervisor offers a solution: program groups! Define your programs as usual, but add a group entry to the conf file:

[program:a-program]
command=command-to-run-a-program
; etc.

[program:another-program]
command=command-to-run-another-program
; etc.

[program:yet-another-program]
command=command-to-run-yet-another-program
; etc.

[group:my-group]
programs=a-program,another-program,yet-another-program

Now, instead of issuing commands for each program like so:

supervisorctl start a-program
supervisorctl start another-program
supervisorctl start yet-another-program

or

supervisorctl restart a-program
supervisorctl restart another-program
supervisorctl restart yet-another-program

or

supervisorctl stop a-program
supervisorctl stop another-program
supervisorctl stop yet-another-program

you can just do

supervisorctl start my-group:*

or

supervisorctl restart my-group:*

or

supervisorctl stop my-group:*

And just imagine having 10 or 20 or even more programs to control!

Contrary to what I considered possible, LDAP server

somehow notifies connected clients when being shut down.
So when you have an open connection to said server, you don't receive ldap.TIMEOUT exception as I expected. You get ldap.SERVER_DOWN.

Something to watch out for when you're working with LDAP.
Like so:

try:
    data = conn.search_s(base_dn, scope, search_filter, retrieve_attributes)
    log.debug("Searched for attribute(s) of LDAP base DN {0}, filter {1}".format(base_dn, search_filter))
    return data
except (ldap.TIMEOUT, ldap.SERVER_DOWN) as ex:  # catching just ldap.TIMEOUT is not enough!
    log.error("Exception: {0}".format(ex))

Vortex Ring State

happens when a helicopter (even a small quadcopter!) descends too quickly and its own downwash (turbulent air beneath the rotor(s)) envelopes the rotor(s). The machine basically runs into its own downwash. This may happen for instance due to a piloting error and leads to severe loss of lift.

Simply put, you go down too quickly and find that you start falling down and can't pull up! And Going full throttle doesn't help! The most straightforward way of getting out of VRS is to move horizontally to get out of the turbulent air as quick as possible.

Wikipedia article.
Quadcopter demonstration: