Author Archives: Gary Pajer

Low-jitter Reaction Wheel Prototype for Kestrel Eye

Posted on by
Reply

The Army is developing the Kestel Eye imaging microsatellite to provide ground imagery directly to the warfighter.    The goal of the program is to provide tactical grade images to forces on the ground at any time and deliver the images fast enough for use in fast moving ground operations. The satellite will provide battlespace awareness for rapidly evolving tactical situations on the ground, for example: the implanting of Improvised Explosive Devices (IEDs); perimeter security of forward operating locations; or movement of hostile motorized forces.

Princeton Satellite Systems is under contract to develop a control system to  meet the exacting standards of stability, satellite location, and pointing accuracy required to meet the needs of the Kestrel Eye satellite.  The objective of our work at PSS is to improve the pointing accuracy or the ground location accuracy of the Kestrel Eye imagery from 60 meters to 10 meters or less.

The features of the proposed control system that are critical to enabling this superb accuracy are:

• Ultra-precise star image centroiding with custom algorithms
• Miniature precision fiber-optic gyro for attitude base and high bandwidth control
• Low-jitter microsatellite reaction wheels utilizing Halbach array motors
• Nonlinear attitude filters incorporating star camera and nontraditional measurements • Composite structure to eliminate thermal distortion
• GPS orbit determination enhanced with two-way ranging

Recently, PSS has completed the design and fabrication of the first prototype reaction wheel.  The wheel is driven by a low-jitter axial flux brushless DC motor, the design of which is currently under patent review.   An important enabling technology is the Halbach array of magnets.  A Halbach array is sequence of permanent magnet segments, each with its magnetic axis rotated from the axis of its neighbor.  The resulting assembly concentrates almost all of the magnetic field on one side, with an almost negligible field on the other side.  This arrangement favors an axial flux motor with a single stationary stator holding coil windings sandwiched between two permanent magnet rotors, each of which has its Halbach field directed toward the stator.  The sketch shows the arrangement.  The stator is green, and the two rotors are red.

rwa_cutaway

We’ve gone through a number design iterations,  settled on a first prototype design, and fabricated it.  We also purchased a simple general-purpose motor driver in order to explore the operation of the motor before moving on to developing custom driver electronics.

We’re very pleased that our first iteration works.  Here’s a video showing the device in action.

We’re already at work on the second-generation wheel incorporating lessons learned in the first prototype.

Confession: I don’t use Subversion.

Posted on by
Reply

The software developers at Princeton Satellite Systems use Subversion to manage revision control.  Usually, we don’t use branches.  We work locally and commit changes to the trunk when we feel that we’ve finished a chunk of code, and we haven’t broken anything.   I had no problem with this until …

About two years ago I ran into a merge conflict  / reversion problem while trying to use Subversion branches in the way that they are intended to be used. I don’t remember the details, but I do remember that the process of fixing things was painful and time consuming.  I never again tried to use an svn branch; I worked locally.   I also wondered if there were a better way.

Google advised me that lots of people had problems with merging and branching while using svn.  And reverting to earlier versions was non-intuitive.  In fact if I remember correctly (and I may not), you can’t really revert in svn.  Rather you merge in a previous version of your work.  So your history becomes <old working version> –> <new broken version> –> <old working version>.   I may be entirely wrong about all that; I really don’t remember very well.

Other people with the same complaints said that they switched to Git, or Mercurial, or Bazaar.   I took a look at all three, and decided to try Git.  The reasons:

  1. Git can be used to manage a Subversion repository
  2. Git can be used off-line for most tasks.
  3. People report that merging goes smoothly
  4. People report that reverting is trivial
  5. People report that branching is trivial

After a period of learning, I learned that all of the above are accurate.  I now rarely do anything directly in svn.   And then later Apple integrated Git into Xcode (although I never use that integration feature) which made me feel a little better about choosing Git over Mercurial or Bazaar.   I now use branches liberally, every day, to try out ideas.  I create branches and destroy branches with abandon, and when I’m ready I merge my work into the “main branch”.  Git keeps all of the things I tried (until I’m ready to ditch them), and I can switch between them instantly and effortlessly.  If I want to see how the application behaved three revisions ago, that’s also effortless and instantaneous, as is returning to my current working state.

I chose not to tell my colleagues about this subterfuge.  The reasons:

  1. Git is not so easy to learn if you are starting from a knowledge svn.  For some reason, the Git developers chose to use the same words (like “checkout”) to mean things that are entirely different from what they mean in svn.  (What’s up with that?)
  2. There’s no reason that anyone has to change a workflow that works for them, especially if there’s a learning curve to endure.
  3. Git is structured very differently than svn.  My brain revolted for a while.
  4. It took me a while to get comfortable with Git, and even now I’m get a little nervous at times.  But then again, I’m nervous at times using Subversion.

I am now a gitophile.  The main advantages from my point of view are:

  1. A copy of the entire repository is kept on your local machine.  (In fact, strictly speaking you don’t need a central repository.)  So you don’t have to be online to use Git (except to push your changes to a central repository if you have one).   
  2. Creating and destroying branches is fast and easy.
  3. Reverting to any previous rev is fast and easy
  4. Revisions can be assigned names at any time, so I don’t need to hunt for revision numbers.
  5. Merging branches seems to work quite smoothly.
  6. Setting up Git locally is a breeze, so it’s easy to use anywhere you want to manage a changing document… for example that novel you are writing about a fictional small engineering company.

Things about Git that I’m not crazy about:

  1. If you get a conflict while updating, it’s not as easy to choose “theirs” as it is with svn.
  2. There are one or two operations whose locations or syntax don’t make sense to me.  The developers could have chosen more wisely.
  3. Git has some tools that are dangerous in that it is possible to screw up and lose data and/or history.  I suppose that’s true of any revision management system.
  4. There is one feature that I call a bug that seems to involve a time-out.  It comes up only in very specific circumstances, but I’ve hit it a couple of times.

I also use Git for some other special activities.   Since I have a desktop and a laptop, I have the issue of being able to start work on one machine and then continue on the other.  There are a number of ways to solve the “sync” problem, including using Subversion to hold intermediate work.  My solution was to set up a Git repository on a local server we have in house (very easy to do) which I use to sync work between the two computers.  When I’m ready, I can then I can update the company’s master Subversion repository from either machine.   I did a similar thing when a colleague and I were the only two contributors  to a small specialized project.