Wednesday, November 11, 2015

Installing mitmproxy on a Raspberry Pi / Raspbian Jessie

This post is a quick list of the steps it took to install mitmproxy on a vanilla Raspbian Jessie install on a Raspberry Pi.  The compile steps take quite a while, which made the trial-and-error method of figuring out which libraries were missing to be a painful process.  Hopefully this post will make it easier for anyone else trying to do the same thing.

Naturally, do
$ sudo apt-get update && sudo apt-get upgrade 
first to bring everything up to date.

Missing libraries:

  • python-dev
  • libxslt1-dev
  • libxml2-dev
  • libffi-dev
  • libssl-dev

Fairly simple, just do:

$ sudo apt-get install python-dev libxslt1-dev libxml2-dev libffi-dev libssl-dev 

Out-of-date library:

mitmproxy requires pyasn library >= 0.1.8.  
(As of this writing, the latest in the repo is 0.1.7)

Check your installed version:

$ dpkg -l | grep pyasn                                    
ii  python-pyasn1                         0.1.7-1   (...) 

If the version is >= 0.1.8 you're fine.  If, like above, it's version 0.1.7 then you'll need to replace it with a newer version.  The pip repo contains 0.1.9, so I used that.

$ sudo apt-get remove python-pyasn1              
(...)                                            
$ sudo pip install pyasn1                        

If all the above went well, you should now be able to download, compile, and install mitmproxy (and its included dependencies) using pip.  (Note:  This will take 30+ minutes on a standard RaspPi B)

$ sudo pip install mitmproxy                           

If all goes well, you should now be able to run mitmproxy.

Have fun!

Sunday, September 20, 2015

Rebuilding the Jada Toys 2006 Camaro



We've had this cool inexpensive Jada Toys "2006 Camaro" R/C car for several years now. The batteries are worn out, the controller doesn't work well anymore and it had been relegated to just being a regular "toy car" for my four year old.

I was cleaning my electronics bench yesterday and realized I probably had enough spare parts from my other R/C ventures to gut and rebuild the Camaro with more modern parts.  Sure, the parts probably cost more than the car did, but I already had them so why not?

The first order of business was assessing whether the existing mechanisms in the car are serviceable at all.  After removing the 13 required screws to get the body off the chassis, we get a good view of the inside:



The brushed motor / gear-differential assembly (right) are probably either usable as-is or not usable at all, so I decide to keep them intact and try just driving them with a brushed motor speed controller.

The receiver / control combination circuitboard in the center looks surprisingly antique for something from the mid-2000s. (close-up) It's a totally analog 27 MHz radio receiver circuit, apparently made by the toy division of Huawei.  It's all thru-hole components and a couple of relays.  Honestly, it's shockingly reminiscent of the circuitboards that were in my childhood toys in the 1980s.  It was probably designed in that era.  Yeah. That has to go.

But what of that "steering" mechanism?  This car was fast and fun as it was originally built, but one thing I always hated about it was that the controls weren't proportional.  It had about two speeds, and the steering had three positions:  Hard left, center, hard right.

Taking apart the steering mechanism we see why:



So the steering mechanism is a geared brushed motor connected to a set of contactors that close when the steering is in the "R" or "L" position.  It's like a motorized switch for selecting between "L" and "R".

The underside of the mechanism mates with the steering crossbar with a 5mm peg:


I momentarily consider removing and re-using that disc, but decide that just putting a similar sized plastic peg on the end of a standard servo arm is probably easier.

Here's the resulting chassis steering mechanism minus the legacy control parts:


It looks thankfully simple and straightforward.  I need to fabricate a mount to hold a standard servo in a position where the arm can actuate that steering crossbar.  So, I measure and design a similar shaped peg for a servo arm and then a mounting bracket it suspend it from those two "towers" where the old, bulkier system used to be.  (Part designs are here:  http://www.thingiverse.com/thing:1025747)

Servo with servo arm & fabricated peg and 3D-printed mounting adapter:



New steering mechanism mounted in the chassis:



Here's a video of a function test.  It works surprisingly well for a first attempt!!


I used the receiver from a Hobbyking GT-2 TX/RX combo, and a Hobbyking X-Car 45A Brushed Motor ESC as the motor driver.  They were straightforward to install.  I replaced the battery connector with an XT-60 since I have lots of XT-60 equipped LiPo batteries already.

Here's a chassis / electronics "before/after" combo:


The original system ran on a 9.6V NiCad battery.  So we decide that either a 2S Lipo battery for "medium speed" or a 3S Lipo battery for "Turbo Speed" will probably work.

Sure enough, with 3S it's fast as lightening and can drift, spin-out, and do donuts.  I don't have any great videos of it driving yet, as Miles isn't terribly skilled at either driving or videography, and I can't do both at the same time.   I'll make a video with my GoPro and post it soon.  In the mean time, here's a basic video (with a 3S 1300 mAh battery) to show that the conversion worked.  (Yes, he stopped just prior to the wall.  Whew!)




It works great, and it's fun to drive!   Here's a complete parts list:

"Donor Car":  Jada Toys 2006 Camaro Radio Control Car

Fabricated Parts:
Steering knuckle & Micro Servo Mounting Adapter

Purchased Parts:
HobbyKing X-Car 45A Brushed ESC
HobbyKing HK-GT2 TX/RX combo
Turnigy TGY-50090M Analog Metal Gear Servo

That's it!

Sunday, August 16, 2015

Programming a generic STM32F103C board in Arduino


A while back I purchased some generic STM32F103C8T6 development boards on eBay for about $4 each.  I initially had some limited success programming them using the GCC ARM Embedded (eabi) toolchain and a generic STM32 loader program.  Since then I've discovered a project to get them working with the Arduino 1.5+ toolchain.

There's a lot of different information about the various STM32 boards out there.  I'm documenting my notes here mostly for my own sanity since I don't play with these boards often.  Maybe you'll find it useful too.

Arduino hardware library for these boards:
https://github.com/rogerclarkmelbourne/Arduino_STM32

"Support" forum: http://www.stm32duino.com/

The USB port
The generic boards do not have a meaningful USB bootloader.  The USB port is only useful for power.  (TODO: Flash the "Maple Mini" bootloader onto them for future ease of use?)


Arduino Board Selection & options
Tools -> Board -> Generic STM32F103C
Tools -> Variant -> "STM32F103C8 (20k RAM. 64k Flash)"
Tools -> Upload method -> "Serial"


FTDI / Serial connection
Connect 3.3V FTDI USB -> Serial programmer as follows:

  • STM32 UART0 TX pin A9 -> FTDI RX
  • STM32 UART0 RX pin A10 -> FTDI TX

I use the GND and 3.3 pins on the 4-pin header for power, but the ones on the IO pads work fine too.


Program / Run Jumper
  • Run mode:  Both jumpers at "0"
  • Program Mode: Jumper 0 (top) at "1"

With J0 set to "1", press "reset" just before hitting "upload" in Arduino to flash firmware.  Program will run immediately after flashing, but won't run after power-cycle until you set Jumper 0 back to "0".  (??)
I have no idea what the bottom jumper is for.

PC13 LED seems to be wired from +3.3V to the PC13 pin.  So setting the pin low lights the LED, and setting it high extinguishes it.

That's it!  With any luck, after loading the above library and following these notes you can push Arduino sketches to your super-cheap, 72MHz STM32 ARM board.

Cheers!

Sunday, July 26, 2015

Arduino-based barometric altimeter / altitude deviation alerter

While working on my instrument training, it occurred to me that I had everything I needed in my parts bin to build a device to help alert me to deviations in altitude. So, I built MonkeyAltimeter.

It started off on a breadboard while I worked on the code:



Then, I took it for a flight test (primarily to see how accurate it was in the cabin and see if my VSI routine worked):





Finally, I designed and printed a simple case for it:




The details,  parts list, operation manual, &etc are here:
http://www.thingiverse.com/thing:942832

The source code is here:
https://github.com/phreakmonkey/MonkeyAltimeter


Enjoy!

Thursday, April 9, 2015

My comments on FAA NPRM for "Operation and Certification of Small Unmanned Aircraft Systems"

have finally submitted my comments to the FAA's NPRM for model aircraft. After reading the proposed regulations, reading the responses from various advocacy groups, and considering both sides I have submitted the following. If you would like to comment to the FAA as well, the link is here:

http://www.regulations.gov/#!docketDetail;D=FAA-2015-0150
The deadline for comments is April 24th, 2015.

----------

I am a computer engineer, r/c model enthusiast, private pilot, and aircraft owner. I am writing in response to the FAA's proposal to regulate small unmanned aircraft systems, including model aircraft.


I support the exemption of recreational model aircraft from the regulation of unmanned aircraft systems.


I understand the critical need to maintain separation of the increasing proliferation of radio control and hobbyist unmanned aircraft ("model aircraft") from other aircraft in the national airspace system. I do not agree that trying to interpret model aircraft as being subject to the existing aircraft regulations is a productive way to accomplish this. Model aircraft have more in common with the existing (exempt) classes of amateur rockets, balloons, and even ultralight human-occupied aircraft than they do with the aircraft regulated under 14 CFR.


I agree with the Academy of Model Aeronautics points about the proposed regulations regarding model aircraft. Specifically, with my concerns added after each one:


AMA point:
• Rigidly defining a requirement to operate within visual line of sight and that calls into question the use of a specific technology or equipment, namely first-person view (FPV) goggles. The language of the 2012 statute concerning "within visual line of sight" indicates how far away a person should fly the model aircraft, not what method of control may be used for the recreational experience. The proposal for commercial unmanned aircraft acknowledges that an observer (spotter) can be used to ensure airspace safety, just as the AMA's community-based safety guidelines do.


My comments:
Many operations of "FPV" flying and equipment are done in close proximity to the ground, and in places where incursion with other aircraft in the national airspace system are impossible. The FAA should not preclude this fast growing activity, as it poses no threat to the nation's airspace or aircraft.


AMA point:
• Narrowly interpreting the words "hobby or recreational use." You should not regulate people who are flying model aircraft in connection with the hobby just because they receive payments. For decades, enthusiasts have participated in contests and competitions that have cash prizes, have been paid to instruct others on how to safely fly models, and have received compensation for aerobatic displays. These payments incidental to the hobby do not change the underlying recreational purpose of the activity or make the hobby any less safe, and regulating these activities would be highly disruptive to the hobby without any benefit.

My comments:
The adoption of advertisement driven technology has also blurred the line between "for compensation" and not. Hobbyists naturally want to share their love and enthusiasm for their activities, and in doing so will use "free" computer platforms like online blogs, YouTube, social networks, and other "cloud" based services. Many of these services are supported by "monetizing" the content, that is to say- selling advertisement space capitalizing on the popularity of the user-driven content. The FAA's guidelines for what constitutes "commercial" or "for hire" operations does not take into account this corner-case, and as such has been interpreted multiple (inconsistent) ways.

I recommend that the FAA more broadly accept model aircraft operation by hobbyists as "non-commercial."


AMA point:
• Making model aircraft subject to airspace requirements such as air traffic control clearance, that have never been applicable in the past and with which it is impossible or impractical to comply. Congress indicated the maximum obligation, which is actually stricter than what the FAA's guidance has been for the past 34 years: notifying the airport when operating within five miles. That is the most that model aircraft hobbyists should have to do.


My comments:
I support the FAA's efforts to keep the national airspace system safe for all operations within it. We need a clear, concise definition for what is and isn't allowed for hobby model aircraft. This may (by necessity) include airspace restrictions, airport proximity restrictions, and altitude restrictions. I encourage the administration to consider both sides carefully, and avoid blanket restrictions (on either side) that are difficult to interpret or comply with.


It's easy (and possibly convenient) to say "no operations within Class Bravo airspace." 
Consider that most model aircraft are operated within a few hundred feet of the ground, though, and much of the Class Bravo "Surface Area" actually becomes safely usable by the model aircraft community. I think there is a middle ground between what the AMA recommends and what the FAA has proposed, and I hope we are able to find it for the sake of both communities.

Thank you for providing us the opportunity for comment.


Respectfully,
Kenneth C. Budd
AOPA Member # 03890068
EAA Member # 1132133
AMA Member # 1050433

Sunday, February 15, 2015

Initial reaction to NPRM 2015.02.15: Operation and Certification of Small Unmanned Aircraft Systems

The FAA's NPRM for operation of unmanned aerial systems has been published as of today.

Most of the commentary online is about the commercial use of UASs, which is, by far, the most interesting aspect. However, many are dismissing the entire NPRM as "having nothing about recreational flying."

This isn't exactly the case.  This post will address my reaction for recreational / hobbyist use.

The NPRM has an important distinction for recreational use- it adds Subpart E to "PART 101—MOORED BALLOONS, KITES, AMATEUR ROCKETS AND UNMANNED FREE BALLOONS", establishing the definition and rules for recreational flying.  By and large, it just codifies into law the existing requirements of the previous advisory circular. It is largely very reasonable.

That said, so far I have two comments on this I will be submitting to the FAA.  This is my initial reaction, so my specific comments and wording may change as I have more time to read and consider this document in the context of the larger framework of regulations.  But I wanted to get my thoughts out there while they were still fresh in my mind.

[...] denotes cuts by me for brevity: 

---- one: ----
§ 101.1 Applicability.(a) [...]
[...]
(ii) Flown within visual line of sight of the person operating the aircraft; and[...]


My comment: Does "within visual line of sight" assert that the operator must be looking at the aircraft at all times, or that it merely must be within range of visual sight at all times? If it's the former, does this preclude any operation using "First Person View" (FPV) video equipment on-board the aircraft, in all circumstances?
I understand the very important need to keep these aircraft separated from other aircraft in the NAS. An outright ban of FPV flying in all circumstances is not a good approach though, as it is one of the fastest growing areas of recreational flying and will likely be undertaken by many whether or not it is permitted.
If the intention is to ban FPV flying for fear of NAS separation issues, I would highly recommend instead that the administrator consider circumstances where NAS separation isn't an issue and exclude the "visual line of sight" requirement from those circumstances. (E.g. limited altitude & range, private property, &etc.)
---- two: ----
§ 101.41 Applicability[...]
(b) The aircraft is operated in accordance with a community-based set of safety guidelines and within the programming of a nationwide community-based organization;[...]


My comment: If I were the NTSB, I would question the validity of applying "law by proxy" to a set of community safety guidelines that have not been vetted via the NPRM rulemaking process. I'm not a lawyer, so I don't know the ramifications or enforcement capability of such a statement.

And finally, a note of caution to UAS pilots. Don't overlook or underestimate this little piece of wording right here:
§ 101.43 Endangering the safety of the National Airspace System.
No person may operate model aircraft so as to endanger the safety of the national airspace system.

The FAA is famous for "catch-all" regulations. In my opinion, you're staring at the one you will be charged with in every circumstance that the FAA wants to take an enforcement action against you and doesn't have a specific codified law for. It's the UAS equivalent of 14 CFR 91.13.

Don't think you're in the clear just because something you want to do wasn't specifically mentioned here.

Saturday, January 24, 2015

UAS Excelsior Alpha - Vectored Thrust Tricopter

I was doing some fast, straight line FPV flying with one of my quadcopters and a few things struck me about how multicopters fly in a straight (horizontal) line;

  • The more you pitch forward (to go faster) the less aerodynamic you are
  • The angle of the pitch actually serves to reduce lift, effectively fighting the motors
  • Finding the maximum forward speed is a risky, manual process.

So what if you wanted to build a multicopter optimized for forward flight?  I've seen some 250mm FPV racers that actually had the front two motors angled forward to increase the forward speed at a lower pitch angle.  I found myself asking - what if you could dynamically actuate the front motors forward instead of pitching the whole aircraft?  (Similar to the motors on an Osprey, but sans wings.)

Vectored thrust on multirotors is uncommon, but not new.  Still, this idea has a singular purpose which makes working out the details and controls a bit easier.

So, I decided to build one.  I give you Excelsior Alpha - my proof of concept Vectored Thrust Tricopter:

And here it is in flight:

I settled on a tricopter design because I liked the idea of yaw (rotation around the Z axis) control being completely independent of the individual motor speeds.  Otherwise, vectoring the front motors forward is going to have some weird roll/yaw side effects.  Tricopters don't alter the motor speeds for yaw. Instead, they vector the tail motor on the Y axis to rotate the aircraft around the Z axis.

For the thrust vectoring, I decided the simplest design would be to mount the front motors on a single shaft running along the X axis at the front, and then couple that shaft to the airframe in a way that allowed a servo to rotate it - effectively pitching the front motors fore and aft.

Here's a video of the drive actuator mechanism: (Note the frame plates have changed a bit since this was taken.)


Build One Yourself!

DISCLAIMER I:  This is a largely unproven design.  It needs some improvement. I hacked it together in a couple of weeks as a proof-of-concept.  I'm only sharing it because in spite of these facts it worked better than I expected, and I've had lots of people ask me for the build details.

DISCLAIMER II:  This is not a beginner project.  I do not recommend undertaking this if you aren't already familiar with RC TX/RX hardware, flight controllers, ESCs, and the like.   I'll list the parts, but I unfortunately I don't have time to write a walkthrough or answer questions about the basics of multirotor construction / configuration / flight / &etc.


Purchased parts: 

(Links go to items I used from hobbyking.com, feel free to substitute / experiment!)

Main components
498x12mm Carbon Fiber Tube (drive motor arm, cut to ~290mm length)
OrangeRX R100 DSM Satellite Receiver (or use a traditional R/C receiver)
ZIPPY Compact 1800mAh 3S 25C Lipo  (3S 1300mAh - 2200mAh seem to work well.)
2 x 7x4.5 3-blade counter rotating props

Misc assembly hardware  (May be incomplete!)
M3 screws (~14mm?) & nuts
heat shrink tubing (for solder-on bullet connectors)
4" zip ties
velcro strap (hold the battery)

3D Printed Parts 

(main frame plates and various mounts)
I've uploaded all the parts to Thingiverse:

I printed them from PLA at .2mm layer height on my Printrbot Simple Metal.  (~25% infill I think)

You'll need to print:
1 x excelsior_top_plate
1 x excelsior_bottom_plate
2 x 12mm_collar (used to hold the motor arm in position)
1 x 12mm_sleeve_servo_arm 
1 x servo_arm
1 x 12mm-to-14mm-tube-adapter (to mount the Talon Tricopter Tail Mount to the 12mm tube)
4 x 12mm_tube_clip (optional - I use 3 for the ESCs and one to hold the XT60 battery clip)
[2015/05 Update:]
1 x Tricopter Yaw Mount / Plate set : http://www.thingiverse.com/thing:687048

Miscellaneous Construction Notes:

I drilled a 3mm hole through the CF tubes to mount:
 - The motor mounts
 - The collars left & right of the main plate
 - The sleeve servo arm
 - The tail servo assembly & adapter

In each case I positioned the part first, then drilled the hole (in each side separately if necessary), then threaded the screw through the part and tube together.

The main motor arm is 290mm long because that was the longest length of a broken 500mm tube leftover from a crash that I happened to have on my bench.  It seems to work well, but that size is fairly arbitrary as it was determined by chaos theory, not computation.

Flight Controller Setup

[2015/05 Update:]
See post on Flight Controller software here:
http://www.phreakmonkey.com/p/vectored-thrust-tricopter-mod-for.html



Former text for posterity:

MORE TO WRITE ON THIS SOON!

Basic setup:
  • I reflashed the FC with Cleanflight and the modified it (provide patch?) to allow me to control an additional servo on S2 using the AUX3 channel input
  • I changed the channel map put AUX3 on the elevator (pitch) stick, and pitch on the AUX3 channel.
  • I put the FC in 'ANGLE' mode at all times so it will hold the craft level when I actuate the thrust vectoring.  This allows me to adjust the pitch with the AUX3 knob (as a result of the remapping above) and control the forward/reverse vector with the elevator stick.

You could accomplish something similar without modifying the FC software by using a traditional R/C receiver and connecting "ELEV" from the RX to the vector servo instead of the FC.  Just be sure to put the FC in "Angle" mode since you won't have any pitch control unless you connect an analog AUX channel to the FC Elev input.


If you undertake this, let me know what happens and GOOD LUCK!  ;)


Sunday, January 4, 2015

Phoenix (Nebula Class) UAS - Status: LOST

Class: Nebula (F330)
Date Built: 2014.04.22
Date Lost: 2015.01.02

Today we declare Phoenix - my primary FPV quadcopter - LOST.  Its final flight was Friday, 2 Jan 2015 in the large private dirt field that I like to fly at.  I was performing some aggressive acrobatics when something on the quad failed, sending it into the infamous quadcopter death spiral.

Despite knowing where it failed and roughly where it went down - the quad was not located at the crash site.  I had a colleague join me in the search, and we gave up after an hour.  Two subsequent returns to the area and I have concluded that we can't find it because it is in fact no longer at the crash site.  My current working theory is that someone from the neighboring park saw it go down and took it in the few minutes between the crash and my going to retrieve it. :(
This was the aircraft that I learned FPV flying on. It will be missed.

Phoenix final specifications:


  • Frame: F330 Quadcopter Frame
  • Motors:  Turnigy D2822/17 1100kv 100W
  • ESCs: Turnigy Plush 10A
  • FC: MultiWii Pro (Mega2560) running MultiWii 2.3
  • RX: OrangeRX R100 DSM2
  • VTX: Boscam TS-351 200mw 5.8GHz
  • OSD:  MinimOSD running MWOSD
  • Camera:  GoPro Hero 2
  • Props:  7" x 4.5" x 3 blade orange
  • Battery:  Turnigy 3S 3000mAh 20C


Some memorable videos taken with this particular quad: