Star Tracker

The code required for this project is organized in blocks, for motor control, sensor reading, battery status reading and user interface management (button and sounds).

Motor

I started programming, with a Arduino Uno, designing small examples for control the bipolar stepper motor. Lacking a driver for this type of motor, I should send the correct signals to each motor coil at every precise moment to get the shaft rotating in an orderly manner. I thought about spending libraries available for it, but because I needed to control the time between step and step I finally ruled out its use.

I ended up implementing the basic code to rotate the engine in both full steps and in half steps. With a loop, a steps counter and a pause between each step, I managed to rotate the motor at the right speed thanks to the calculations made earlier.

With this basic program prototype I decided to do a test to validate it. I programmed the ATMEGA for rotate the motor during 10 minutes at constant speed. The objective was to predict mathematically how many revolutions and what will be the end position of the shaft after that time. Then I would compare this theorical results with the reality.

Unfortunately the tests results were unsatisfactory. At every test i made, it seemed that the engine was loosing steps, accumulating errors in each revolution.

I tried to optimize the code, without success, so I began to read internet documents about the clock accuracy of Arduino UNO, the registers used for "counting the time", the delay(), delaymicros(), millis () and micros() functions... They were very hard readings and tests, without good results. My goal was to use the internal oscillator of 8Mhz so I opted to look for another solution to this problem. I found the solution using the microcontroller interruptions.

With interruptions the motor control was broadly simplified. The idea was to avoid control the time delays programatically and waste time on loops or arithmetic and logic operations. All of this instrucctions maintain the microcontroller busy and could introduce delays when sending the motor signals. Interruptions allow you to instruct the CPU to run a very simple routine every X milliseconds. This routine is used to advance a step. The interrupts are executed with priority, no matter what the CPU is doing, this way each step occurs at its right moment, without delays.

For someone like me, with no experience in ATMEGA specifications, this seemed low-level programming, too many aspects closely related to micropocesador and clock signal. So I finally looked for a library to help me, "TimerOne".

The piece of code that initializes the interrupts establish the time period between interrupts activation (AstroDelay). In each activation the associated function (stepMotor) is executed, associated with the interrupt on its initialization using attachInterrupt(). To stop and start the motor, the interrupt is enabled and disabled by calling the start() and stop() procedure. Once initialized, a new time period can be set with setPeriod().

With the engine controlled in this way, the code that runs on each interrupt is very simple. First we define the vectors that store the activation order of the motor coils, both in full-step and half-step mode:

Finally the interrupt associated function that moves one step the motor shaft:

The operation of this loop can be explained graphically. The color sectors represent the stepCount variable, while the gray-scale sectors represent the step variable.

With 48 steps per revolution of our motor (number_of_steps_per_revolution), at each step we will use one of the 4 (step_sequence) different coils combinations, 8 if we use half-step.

After 48 steps (96 using half-step) the motor has done a full revolution and we have iterated 12 times over the coils combinations array.

Two additional functions are used for the motor control: start_motor() and stop_motor().

With start_motor() we can do rotate the motor shaft choosing a period time between steeps, a rotation method (full or half-step) and, opcionally, the movement direcction (up o down).

With stop_motor() we can stop the motor, thus all the motor lines remains at stand-by mode. We also switch-off the motor activity led.

Sensors

Las barreras iR se comprueban cada segundo cuando el motor esta en marcha. Sólo se comprueba el sensor correspondiente al sentido de la marcha.

• The lower sensor (sensor_up) acts with the engine in the upward direction, normally the beam is broken (low level) and is an error if iactivated (high level).
• The upper sensor (sensor_down) acts with the engine in the down direction, normally the beam isn't broken (high level) and is an error if ideactivated (low level).

In order to find minimun value that activates the down side sensor we have to do some test readings. We have increased the distance between emitter and receiver, so the minimun/maximun at high state are in 871-1017 range. This narrow range forces us to set an average border value of 950 (ir_up_threshold).

The upper sensor has normal operation and its high/low values are between 31 and 1017. In this case you can put a border value of 100 (ir_down_threshold).

When an error state is detected in a sensor, the motor is stopped and a high frequency sound is emitted for the upper sensor, and a low frequency sound for the lower one.

In case of malfunctioning sensors, due to failure or too much light pollution, their verification can be deactivated by means of the variable (do_check_sensors).

Battery

The battery status is read by measuring the voltage present at the output of the voltage divider. This way we ensure that digital input isn't feed at higher voltages than 5v.

The show_battery_status() function reads such voltage value and applies a scale transformation to display the actual value present at voltage divider input. The circuit is designed so that the maximum input value of 21.67v is equivalent to 5v at the output, also we take into account, for calculating battery status, the voltage drop (0.76v) caused by D1 diode, that protects the power supply of polarity reversals.

To show the battery status is used the bi-color led LD1, which indicates the system power status with the following color scheme:

• Green: The system is on and the battery has a voltage greater than or equal to 11v.
• Orange: The system is on and the battery has a voltage greater than or equal to 10v and less than 11v.
• Red: The system is on and the battery voltage is less than 10v.
• Off: The system is power down.

Finally we store the current time in the last_bat_check variable, since the battery is only measured every 20secs.

Interface

The user interface is based on two leds, a buzzer and a pushbutton. The LD1 led indicates that the system is power on and the battery status. The led LED1 indicates activity on the motor and blinks red when the engine is running, every 1sec when the sensors are active and every 2sec when deactivated.

The mount functions are controlled by pressing the S1 pushbutton. With short presses you can control the different options:

1. With one press the motor starts up if it is stopped and stops if it is running.
2. Two short presses change the full-step motor mode to half-step and vice versa. This allows smoother operation and control the motor torque.
3. Three pulsations cause quick closing of the mount plates to their initial position. Remember that if the sensors have been deactivated, the plates may collide and overheat the motor.
4. Four presses and the plates open at fast speed. Remember that if the sensors have been disabled the screw can exit the nut, opening the plates abruptly.
5. Five presses disables or activates the sensors. You can check the status of this option by observing the flashing latency of the LED1 led.

With each option selected the system confirms it by beeping as many times as the number of the selected option.

The function used to play sounds is playBuzz(). It allows to play a long or several short beeps by selecting the frequency of the sound. The duration of the sounds is fixed in the code.

In the program's loop() function, the sensor, battery and button status are checked. A ClickButton library is used to detect button presses.

Preparing the ATmega chip

Once the code was finished and tested on the Arduino ONE, I prepared the ATmega to receive the code. First I had to configure it to work with the 8Mhz internal clock as I bought it with a bootloader configured for an external 16Mhz clock. The procedure for programming the chip using an external Arduino is described here.

The same circuit is used to load the program. Whenever the ISP circuit is used to program the ATmega, it is necessary to remember to unplug the battery, so that the Atmega is fed from the Arduino board.

In the case of an error recording the ATmega, by mistake in the connection (for example powered the ATmega in the line of 3.3v), one can try to recover the chip using an high voltage programmer like the one here. With this we can rewrite the correct configuration bits (fuses) and rewrite the bootloader and the program. The fuses are 3 bytes of EEPROM memory that remains between power cycles, but that can be changed as many times as you want. The fuses determine how the chip will act, if it has a bootloader, at what speed and voltage it is going to work, etc. To explore the meaning of these configuration bits you can use a "fuse calculator".

At this point the mount is ready for operation!