Finally something we can use!

Sorry guys. This post will be brief and contain some little technical detail. Some things will be confusing because I’m still working on straightening things out.

If I could be any video game character, it would probably be Megaman

https://github.com/dharbott/ASCOM-Telescope-Driver
https://github.com/dharbott/Arduino-Telescope-Driver

Here’s the ASCOM Telescope Driver code. And then there’s the Arduino Telescope Driver code. You’ll need both, to operate the Motorized Telescope Project. I’m putting it online so you can access it there, and watch my slow progress. It is really messy in some places, but once it’s done I’ll clean it up nice and proper.

 

Just to be clear, the ASCOM driver is not finished. It’s barely 15%-20% complete. I’m working on details for byte transmission protocol between Arduino and ASCOM Driver. It must also be able to process, format, and send Single Floating point 32-bit numbers over Serial communication, and receive and process it on the Arduino end. Otherwise, we can’t send local RaDec degrees to the Arduino. The alternative is we only send raw 16-bit unsigned ints, which technically works, but by principle of modular design the Arduino should receive degree-based commands, and be less dependent on the ASCOM Driver for certain tasks. This is the hardest part, but once it’s done, everything else should be alright

 

Notes on data types :

Arduino char -> 8-bit signed, ASCII 
C# char -> 16-bit unsigned UNICODE

Arduino float -> 32-bit single precision floating point 
C# single -> 32-bit single precision floating point

Arduino double -> doesn't exist 
C# double -> 64-bit double precision floating point

Arduino int -> 16-bit integer 
C# int -> 32-bit integer

Arduino microcontroller - LittleEndian byte encoding 
My Computer i3 processor (?) - LittleEndian byte encoding

Arduino Serial.write(...) -> sends byte data, serially 
C# Serial.TransmitBinary(...) -> sends byte data, serially

Arduino Serial.read() -> reads in one byte of data 
C# Serial.ReceiveByte() -> reads in one byte of data

Arduino processing -> weak 'typed' language 
C#, .NET -> strong 'typed' language

strong 'typed' language : less freedom, more security - also means we must use proper, logical, and hopefully efficient data type agreement throughout the entire driver

 

Leave a comment!

Slow Progress Is Still Progress

Impatient… BTW – Not my dinosaur gif!

Eeep! Not much since last update… a week ago. I had to clear something off my ToDoList. Well at least I can say I got the driver connected and talking to the Arduino.

Part 1 : Arduino Code

– This code will blink the onboard LED (pin13) however many times the length of the command string that is being read on Serial, whose command string is terminated by a ‘#’ character

String temp;

void setup() {
    // put your setup code here, to run once:
    Serial.begin(19200);
    pinMode(13, OUTPUT);
    digitalWrite(13,LOW);
}

void loop() {
    // put your main code here, to run repeatedly: 

    if (Serial.available())
    {
        //readStringUntil will consume the '#' character
        temp = Serial.readStringUntil('#');

        for (int i = 0; i < temp.length(); i++) {
            digitalWrite(13,HIGH);
            delay(200);
            digitalWrite(13,LOW);
            delay(100);
        }
        delay(1);
    }
    delay(100);
}

Part 2 : Telescope Driver Code

– This code snippet belongs to the Connected member object, which includes get() and set() functions. The get() just returns whether or not the driver already established a connection to the hardware. The set() checks if we’re already connected, and if not, then we establish a serial connection to the Arduino over the ASCOM.Utilities.Serial Library. Common serial parameters I use are port 26 and baud 19200. It also sends a text message to the Arduino to confirm that it’s established a connection. The next step would be to have the Arduino send back an acknowledgement text message.

private ASCOM.Utilities.Serial objSerial;

public bool Connected
{
    get
    {
        tl.LogMessage("Connected Get", IsConnected.ToString());
        return IsConnected;
    }
    set
    {
        tl.LogMessage("Connected Set", value.ToString());
        if (value == IsConnected)
        return;

        if (value)
        {
            connectedState = true;
            tl.LogMessage("Connected Set", "Connecting to port " + comPort);
            // TODO connect to the device
            objSerial = new ASCOM.Utilities.Serial();
            objSerial.Port = 26;
            objSerial.Speed = SerialSpeed.ps19200;
            objSerial.Connected = true;
            objSerial.Transmit("Hello Arduino#");
        }
        else
        {
            connectedState = false;
            tl.LogMessage("Connected Set", "Disconnecting from port " + comPort);
            // TODO disconnect from the device
            objSerial.Connected = false;
        }
    }
}

Soo yeah. That’s all I’ve accomplished for now. I’m considering writing the MoveAxis method, and the SlewToAltAz method. Eventually, I’ll be able to move the telescope by sending it a text command, such as “SlewToAltAz(123.45678, 98.76543)#” or “MoveAxis(0,0.01234)#”, with each command ending in ‘#’ character. I’m not sure how to invoke those functions through the driver test app yet, but I might have to make a form in Visual Studio. I’m thinking something like a simple CNC manual Jog feature interface.

After I can get those two functions working, then we’ll figure out how to translate between the telescope’s machine coordinates and the coordinate based on planet earth…

I’ll leave you with one of my favorite comic strips:

John Heeris http://heeris.id.au/

 

Until next time

-david

Plate-solving : What is it good for?

Wikipedia

Ok – so let’s assume we have a functioning, working telescope. This telescope has it’s own set of coordinates in relation to it’s location on planet earth, and the exact time of day. These coordinates in theory should work with the World Coordinate System on which numerous star databases are built upon. If we want to use other star catalogs, we have to be very confident in our telescope’s coordinate system. If we direct our telescope to a known stellar object, and we see that our telescope fails to point at that object, then we have a misalignment somewhere. There are several reasons our telescope could be out of alignment : poor polar alignment, unbalanced mount, misalignment of the optical tube assembly, etc.

So, how do we correctly and accurately compensate for these errors? We use plate-solving. Plate solving is best described somewhere else. What plate solving entails is :

1. Pointing the telescope at a visible, known celestial body
2. Taking a digital photograph of what is visible
3. Making note of the exact time and ‘intended coordinates’
4. Connecting to an online star database
5. Finding a match for that photograph using some fancy open source computer vision software

Unimap, one of the plate solving softwares we want to try.

What follows next is we compare that match’s coordinates to the telescope’s coordinates, and apply some error correction techniques so that in the future, our telescope will point more accurately.

There are numerous plate solving softwares. Not all of them require an ASCOM driven telescope. But the fancy ones do. That’s what I’m building at the moment – the ASCOM-compliant hardware driver. (I’m actually quite busy this week, so don’t expect it to get done any time soon.)

We don’t necessarily have to write the fancy computer vision software, or dig through an online database – those parts are already done for us. But we could try to make those, if we could develop something EVEN better…

Sorry, that’s all for now. Next post ought to be better after I make some progress.

-david

Upcoming astronomical events, from Sea and Sky Astronomical Reference Guide

• April 13 – 18 – International Dark Sky Week
• April 18 – New Moon
• April 22, 23 – Lyrids Meteor Shower
• April 25 – International Astronomy Day

“What’s the thinking?”

Step 1 : Download Visual Studio Community 2013 installer. Run Installer. Find out I don’t have enough space.

Step 0 : Free up 11 GB of space on C:\ drive for Visual Studio Community 2013

Step -1 : Delete hiberfil.sys by disabling the Hibernation feature in my power settings, cuz hiberfil.sys eats up 4.4GB and hibernation doesn’t really help much. But, it can only be done through the command line, in Administrator mode. Arrrggggg………

Step 2 : Run the installer again. Wait 30 minutes

Step 3 : Write on Blog.

* * *

Hello Step 3!

Today, I am installing Visual Studio Community 2013 because it’s free!! AND, I’m going to use it along with VisualMicro. This is because the folks at Arduino.cc said so. And if you don’t want to click on that last link, here’s a blurb from the page that sums it up:

Arduino IDE Plugin for Microsoft Visual Studio and Atmel Studio

---

• Microsoft Visual Studio 2013 Community Edition (it’s free and great!)
• Supports all Arduino versions 1.0 to 1.6 and the Intel Edison/Galileo
• Super fast compiler with double click drill down into source code
• Supports multiple .pde/.ino files in a single project
• Easy set-up
• Usb/wifi debugger with break and update of variables on the mcu
• Educational mode

Well, there you have it. I’m going to be programming in a more advanced IDE than the one provided by arduino, using visualmicro within visual studio. And, I’m going to need this in order to build the hardware driver that will interface with the ASCOM software layer, which in turn interfaces with all the other sky mapping softwares that are publicly available and free.

sky mapping software -> ASCOM -> hardware driver -> motor action

Piece of pie.

All of this is just the beginning of the end of the first major iteration of the telescope motorization project.

Cheers

-david

Taking too long…

Also, since it’s been a while, I’ve uploaded a video of the telescope work-in-progress :