The goals for this rotor system are:
- Easily handle two full size satellite antennas on a cross boom.
- Azimuth rotation 10 times faster than the Yaesu G-5500
- Fit in the trunk of a car.
- Run off DC power.
- Robust construction - it should be able to take a punch.
The goals for the rotor were met. One of the most important parts of an antenna system is the tripod. Camera tripods are often used and work for portable rotors designed for a single light weight hand held antenna. They are not suitable for a high performance antenna system. This 3 foot tripod is perfect for the project. I am limited to indoor antennas and have use one of these for my indoor antenna system (G-5500 and two full size antennas) for many years. It folds up easily to fit in the trunk.
There are many choices for a motor for the rotor. DC motors, Servos and Stepper Motors are the most common choices. Each type has its advantages and disadvantages. I used a stepper motor and re-designed a similar rotor I designed and built several years ago. The new version is more compact and robust. The image below shows the rotor mounted on the tripod mentioned above. As you can see the design removes the load from the stepper motor. Steppers are not designed to handle high axial or radial loads so it is isolated with a chain drive. The chain drive also reduces the degrees per step from 1.8 to 0.45 and increases the torque available to move the antennas. The rotor looks large in the image but it is only 5.5 x 8 x 3 inches in size.
The main disadvantages of stepper motors in this application are lack of a reference position and missed steps. Missed steps can be a huge problem as the error is often cumulative. All motion control with steppers is relative - the stepper never knows what direction it is pointing. Using a stepper in an open loop control system is generally not a good idea. The easy solution to both of the stepper motor problems is to run the motor in a closed loop control system. For a closed loop control system we need position feedback. This is most easily accomplished with a multi-turn pot.
The sprocket on the motor has ten teeth and the sprocket on the drive shaft has 40 teeth. This 4:1 ratio means the motor turns 4 revolutions for each revolution of the antenna. The image below shows a 5 turn pot mounted to the rotor and driven off the chain.
The electronics for the first version of rotor I built several years ago were based on a Parallax Propeller chip and were quite complicated. The new version uses an Arduino Uno with an Adafruit motor control shield. The image below shows the old version on the left and the new version on the right. Advances in hardware make things so simple now it almost seems like cheating. Just write a few thousand lines of code to put all the bits in the right places and you are good to go.
or 
This project started out using an Arduino. It was chosen because I am most familiar with it and I have several laying around. During the development process version 2B of the Raspberry Pi was released. I had been using earlier versions of the RPi and they were not quite up to the task. I believe the RPi people got it right with the version 2B board. It is an incredible value and works very well so development was switched to the RPi. Due to some concerns with the RPi the RPi version (click here) was finished and work was resumed on the Arduino version. The RPi version does work and you might find it fits your needs.
The RPi and the Arduino are at first glance very similar. The most important difference between them is the operating system. The RPi was designed to support a variety of operating systems (some variation of UNIX is the most common). The UNIX like operating systems are multi-tasking just like the operating system on most computers. The multi-tasking operating system is a big plus for the RPi. Just like your PC it can run many different programs at the same time. The Arduino has a Real Time Operating System (RTOS) which is designed to run one program. There are some RTOS operating systems that will run on the RPi like (ChibiOS/RT) but they are not common. A rotor controller is a stand alone program and the features of a multitasking operating system are not needed. The RTOS does not have the overhead and complexity associated with a multitasking operating system.
You can run different versions of UNIX on the Arduino board. This would not make any sense. If you want to run a version of UNIX the RPi is much lower in cost and offers many more i/o ports than the Arduino.
http://playground.arduino.cc/Learning/Linux
Another even worse idea is to run the Arduino OS on an RPi. This note on the install instructions page was more than enough to stop me from even trying it.
"Note: This will install an old version of Arduino, and may not support some of the newer boards."
http://playground.arduino.cc/Linux/Raspbian
One of the interesting differences between the Arduino and the RPi is the fact that the Arduino has a reset switch and the RPi does not. Newer versions of the RPi board allow a connection the the hard reset pin on the ARM chip. It is also possible to have a soft reset using an i/o pin to trigger a system call to reset the system. A hard reset switch on a multi-tasking operating system is very dangerous. There are often many programs/processes running at the same time most of which the user is not aware of. The PC you are using is no doubt doing many things most of the time that your are not aware of - checking with an NTP server to update the clock, de-fragmenting your hard drive, various application programs checking for updates and many others. If you hit the reset switch or turn the power off on a multi-tasking OS damage can be done - most often to the drive containing the operating system. The OS on the RPi uses a SD card as a very slow hard drive. If you reset it or unplug it damage can occur to the SD card data. Leaving the hard reset switch off the RPi was done to reduce the chance of this happening. This is not really what we want in something doing a single simple task like controlling a rotor.
All these background operations also result in a degree of uncertainty in program execution timing. Most PC's have hardware that is fast enough so this is usually not a problem. Small devices like the Arduino and the RPi are more like tablets or smart phones than PC's which means they are relatively slow and execution time can be an issue if a multi-tasking operating system is used on a low power cpu with limited memory.
Both the Arduino and RPi have good characteristics. The RPi currently offers the best value in terms of cost and flexibility. Each is well suited to different tasks. If you use an RPi for a rotor controller you will have to go through the shutdown procedure every time you turn it off. If you do not you will at some point corrupt the SD card. This means you will need a keyboard and display connected to the RPi or a remote desktop connection to initiate the shutdown process. When you shutdown the RPi you also have to wait a while after the screen goes blank for the shutdown to complete before turning off the power. If you do not you will at some point corrupt the SD card. You will also have to wait a fairly long time for the RPi to 'boot up' each time you turn it on. The Arduino rotor controller can be shut down by simply turning off the power when ever you want. The Arduino will also 'boot up' very quickly. For me this is enough to make the Arduino the board of choice for a rotor controller application. For other applications where there is a need for a full featured multitasking operating system the RPi is an excellent choice, for a rotor controller it is overkill.
Motion Control
The graph below shows movement for my G-5500 rotor. The gray horizontal lines show the destination angle as the rotor is moved from position to position. This is an actual graph of the performance of the rotor not a MatLab simulation. You can see the linear speed of the G-5500 as it moves from position to position.
Getting a rotor and antenna load to move fast is not a big problem. The problem with high speed rotors is angular momentum which is the moment of inertia multiplied by the angular velocity. The faster the rotor turns the higher the angular momentum. Angular momentum is not a problem until we try to change direction. Consider a rotor and antennas rotating at a high speed tracking a satellite and suddenly we switch to tracking another satellite that requires the rotor to reverse direction. The system has to do something to dissipate the existing momentum before we can change direction. There are basically two ways to deal with this problem - brute force and motion control. With brute force we simply design the rotor, rotor mount and supporting structure to be able to handle the load. The G-5500 uses this method. If you look at the graph shown above you can see that the G-5500 maintains a constant velocity as it heads to the new heading. When it gets there it simply stops. This puts a large stress on the system which has been designed to take it. This system works in part because the rotor never gets rotating very fast. There is only an occasional small amount of overshoot. I suspect that if the G-5500 rotated 10x faster something would break when it changed direction.
The other method is motion control. With motion control we keep track of how fast the rotor is turning and how far it is away from the new heading. Knowing those two things we can gradually reduce the speed of the rotor as it gets closer to the new heading such that it is stopped when it gets to the new heading. During this deceleration period the rotor will be turning a bit slower than the load and will provide a gradual breaking action.
The easiest way to deal with the angular momentum problem is to keep it low by keeping the rotor speed and the moment of inertia low. The moment of inertia can be reduced by using a single light weight antenna centered over the rotor axis of rotation. This is ideal for small portable antenna systems. When using a pair of full size antennas on opposite ends of a cross boom the moment of inertia becomes much higher and the rotor system must be made stronger and/or motion control used.
Motion control settings for a simple system consist of max velocity and acceleration. The graph below shows the rotor using motion control. Remember the graph is an actual graph of the rotor operation not just a MatLab simulation. For a point of reference the speed is set to 150 and the acceleration is set to 12. The rotor is simply rotating between two headings with no delay between direction change. The space between the data points is a good indication of the speed. It can be clearly seen that the speed is decelerating as the rotor approaches a new heading and accelerates on the way to the new heading.
Motion control rotor systems need to be tuned to maximize performance for a given rotor and load. In theory you can do this by just watching the rotor movement but it is almost impossible if the rotor is moving fast. Here is a short video showing the rotor in full speed motion.
Conclusion
This is not a Heathkit step by step project and I am not trying to sell you anything. If you are looking for something like that you might take a look at Satnogs, WRAPS or CNCTRK - they are all very interesting. This is merely a collection of ideas that have been proven to work. Here are some links that can help you if you are designing your own rotor system.
I am very interested in hearing from anyone who is designing a new rotor system.
If you are interested in Amateur Radio Satellites be sure to visit http://www.amsat.org/
