Buck Regulator (12V LiPo to 5V for the PandaBoard):

See the full gallery on Posterous

And color-coded both to make it easier when we’re mucking about in the airframe (lots and lots of wires)”

Jacob and Michael (fellow aerial robots club circuit wizards) did the board designs and sourced/ordered parts. Speaking of those guys…

Dudes, double check component sizes when ordering and change the schematic (if needed).  Theres definitely an F size tantalum cap on an A size footprint, so i just had to tack one side down to the middle of the ground plane.  Also, on the PoE injector, only one side had room to make mounting holes (for the connector).  Lastly, on the mounting holes on both, could you mark those with X’s somehow next time? it makes hitting them with a drill a LOT easier. Thanks

And the schematic for the Buck reg didnt have component values, I had to reverse-engineer the Bill of Materials we ordered from to figure out what goes where.

Just thought I’d post this.  This is a Flip HD video camera getting gutted so NCSU High Powered Rocketry (who Aerial Robotics shares a lab with) can control it via a microcontroller.  Awesome.

Working with Trent Young (grad student in flight research, he’s basically awesome) I got to test all 6 Degrees of Freedom (dof) on the boards, and all of the (tediously soldered and resoldered) QFN sensor chips worked.  After a little retouching all of the SD cards worked as well.  There were (still more) errors on the boards we fixed, and if we ever want to release this design I will fix all of those before we do.

Finally here is the previously only working HazardIMU here being lonely in the Plank UAV platform:

See the full gallery on Posterous

Now the epilogue: In learning about the design, programming and actually building these IMU/autopilots, I’ve learned a lot about what *not* to do, and I think I’m going to point this out as a natural law:

Circuit hackers in UAV groups will eventually design their own autopilot, or circuits they design will tend towards becoming autopilots.

I only have to look around at the HUGE list of open-source or partially open-source hacked together autopilots available to the community as proof.  Just at NC State here alone we have gone through several (FlightStix – a gumstix-based autopilot, Micropilot, OpenPilot, Ardupilot, and now we use the proprietary Piccolo LT by Cloudcap.)

I’m right now looking at making my own autopilot.  Still figuring that out now.

Ciao.

Close up of the front of one of the boards:

All three boards at the end of the night:

And this is an idea what they’ll look like mated to the main board:

A few weeks ago I was given a simple problem by my Engineering Advisor:

“Get an exact 8ms delay in Ubuntu.”

He uses these machines for industrial automation in the startup he co-founded.  My first answer was “that’s what a real-time operating system does”, but I figured I’d give it a shot.

Testing timing with code

The code I used is up on this gist of mine. test-timer.c is his version, test-timer2.c is mine. (Note you’ll need -lrt to compile mine).

test-timer.c - uses gettimeofday() for measurement, and usleep() for waiting.  Both deal in microseconds

test-timer2.c - uses clock_gettime() for measurement, and clock_nanosleep() for waiting.  These use nanoseconds (hopefully higher precision).

There are 5 clocks available on Linux, and I used the CLOCK_REALTIME one for my implementation.  I also noticed that it was regularly ~1% overshot, so i deliberately subtracted 1% from the commanded sleep time to make it more accurate.

Results

Here is the results of my run (on my Ubuntu 10.10 Desktop i386 machine):

Usage: <executable> <row index> <ctrspec>

• executable – this is just the name&path to the executable (pmcstat_p4, pmcstat_iaf, pmcstat_k8, etc.)
• row index – this is the counter index you want to set.  For K8: 0 to 3.  For IAP: 0 or 1. For IAF: 0 to 2. For P4: 0 to 18 (but be wary of the restrictions).
• ctrspec – this is a specification string with no spaces, and arguements are separated by commas

Example Usage:

 ./pmcstat_p4 12 p4-branch-retired,mask=mmtm+mmnm

You see that the ctrspec string can have key=value pairs, or just tags.  Generally just an event name will suffice (e.g. ‘p4-branch-retired’), but in this case we additionally supplied a mask to further refine the events counted.

There are some general events that are shared by (most) architectures, and are listed here: pmc

For the majority of events, you’ll use architecture-specific events, found here:

• Pentium 4 (P4) pmc events
• Intel Architectural Programmable (IAP) pmc events
• Intel Architectural Fixed (IAF) pmc events
• AMD K8 pmc events

In addition, for now setting the event causes a side effect of initializing the counter to 0 before the event is enabled.

To read the counters, simply run `rdpmc <rowindex>` where rowindex is the row index of the counter you set the event to.  The exception to this is the IAF counters, to which you have to add 0x4000_0000 to the row index to read them.

For example, on a Core2 machine you would read the programmable counters with

• ./rdpmc 0
• ./rdpmc 1

And you could read the fixed-function counters with:

• ./rdpmc 0×40000000
• ./rdpmc 0×40000001
• ./rdpmc 0×40000002

(Also, it goes without saying that you need to set the PCE bit of CR4 in order to read the counters as non-root).

These are using the most recent libpmc functions, including a re purposed general allocate function which reads the counterstring and extracts the event.

I just pushed pmcstat that builds.  Let me tell you right now that even though it builds, right now it can’t do anything useful (without the architecture specific support).  Here’s my upcoming plans for it (and libpmc, and some other things):

Arch’s

Add architecture-specific support for pmcstat.  Because the hwpmc/libpmc have been previously simplified, pmcstat needs to be told what architecture it’s on.  This is going to take the shape of some preprocessor macros at the top.  They will contain this (and possibly more):

• Allocation Functions (macros replace a generic allocator with the proper libpmc allocation function)
• Number of PMCs
• Bit-length of PMCs (used to calculate printouts)

libpmc

In addition to these, two smaller functions need to be added for each architecture.  Some of the functionality of these is actually already covered by the allocation functions and can be separated.

• pmc_read() functions (while RDPMC is universal across all the x86 archs, the addressing scheme is not)
• pmc_set() functions (instead of setting the event registers, this sets the counter value, used to initialize it to 0 or whatever you want)

debug wrap

The last thing for right now is to take the debugging stuff I put in libpmc (mostly printf()s) and just put some conditional compilation around it.  This way the allocators will return just set the PMC events themselves (As opposed to the current setup, where libpmc outputs a value which an event-setter then uses).

The debugging compilation of the libpmc routines would allow the event-setters to still be used, but the regular routines (like those used by pmcstat) would just do the whole job of constructing event/control register values and WRMSR-ing them.

sidenote

I now have pages of notes on PMCTools on my tablet and around my workspace.  One of the conclusions I’ve come to in trying to decipher all of this is that even though I (myself, as a programmer) don’t like Object Orientation, this might have been well-suited for it.  I’ll be the first to admit that I’m must more comfortable with procedural programming, and it works for my (greatly simplified) PMCTools implementation, but for the FreeBSD PMCTools, I think it would make lots of things cleaner and easier to read.  Maybe it’s that I’m still an undergrad (and don’t get my coding powers til grad school) but it’s taken me often many MANY readthroughs and cross referencing both the FreeBSD kernel and the Minix kernel to make heads or tails of it.  (slightly less related to the OO problem, but in general readability has been a barrier for me) </rant>

Some sleep. Back to coding.

First off, because there are no interrupts, only counting modes are supported.  In addition only system-wide counting works for right now.  With a little hook in the scheduler/switcher process-virtual counting should be possible for one process at a time.  More on that later (in planning on the rest of the summer).  Cutting that functionality out for now works, because as I’m removing I see how strongly it’s tied to the FreeBSD kernel.  Adding that functionality would mostly be original code.

pmcstat is a convenient and clean interface to libpmc functionality, which is in turn a clean interface to hwpmc functionality, which is in turn a clean interface to the hardware… wait a minute.  For now pmcstat will work as follows:

1. pmcstat is called from the command line w/ systemwide counting and some other options
2. either the options are bad (and it returns w/ an error) or it sets up the appropriate counters and starts counting events
3. pmcstat issues RDPMC’s at regular intervals to update it’s count (this is because depending on the frequency of the event, counters can overflow regularly)
4. this information is output to the user (or saved to a file)

For process-virtual counting, is a bit more complicated, but still doable.  Mostly the same as above, with these differences:

1. pmcstat fork()s off a child process which waits on a signal
2. pmcstat then sets up the counters/events for the child
3. pmcstat signals the child to start
4. the child process exec()s to the desired process
5. pmcstat monitors the counters at regular intervals (using RDPMC)

More to come soon.

(As an informal note, I should say I gave this figure because pmcstat really is the simplest part of PMCTools so far, thankfully)