LittleFoot Elegance Photo > Off-Topic Discussion

Little Foot Display Firmware

<< < (5/7) > >>

Armando:

--- Quote from: Astroquattro on Wednesday, 18.09.13 - 23:03:39 - CEST ---...
I think at this point we can finish our small excourse into what's about electric motors. Now we have an equal understand and won't suffer from different definitions.
...

--- End quote ---
I think to know how a stepper motor works.
Without taking into account mechanical aspects (step angle and overall reduction) tracking resolution is still related to the number of microsteps/step. Voltage PWM output with coils current feedback is what is required to make microstepping working. Appropriate IC stepper driver exist to properly move stepper motors with adequate PWM frequencies and appropriate (variable thanks to the feedback) PWM duty cycles.
Nothing else is required except the need to make the MCU asking for a ustep CW or CCW to the motor driver.

While referring to PID solution I meant to "guide" at variable speed (no more fixed usteps/s) according to the current detected tracking error.

CS
Armando

Astroquattro:
Yes, you're right about the deeper understanding.

About the PID we have to talk about a bit more. But let's do that when it come to implementing this module.
Since auto guiding is based on looking at the offset of a guiding star between to images, and correcting that offset right away, the speed differs because of how far the shift was. To do that as accurate as possible taking the image, downloading it from the ccd or cmos, pinpointing the center of the guiding star, measuring its x and y position and calculating the offset transferring it to µsteps and passing it to the motors, a CPU has it's advantages as I pointed out.

Normally one uses a subset of  lets say 40 by 60 pixels depending on how large a pixel is and how faint the guiding star was chosen. An MCU can do that in a couple of hundred milliseconds where a CPU does that in some some milliseconds to hundred nanoseconds. All we have to ensure is to stay below 997 milliseconds because that's what is the critical time you see a result with common telescope apertures. The large a telescope is, the more accurate it has to be and what's good for the large is good for the smaller ones, too.

cheers,
Christian

Armando:

--- Quote from: Astroquattro on Thursday, 19.09.13 - 00:10:18 - CEST ---Since auto guiding is based on looking at the offset of a guiding star between to images, and correcting that offset right away, the speed differs because of how far the shift was. To do that as accurate as possible taking the image, downloading it from the ccd or cmos, pinpointing the center of the guiding star, measuring its x and y position and calculating the offset transferring it to µsteps and passing it to the motors, a CPU has it's advantages as I pointed out.
--- End quote ---
In fact I think the controller should be compatible with current guiding software...
The PC guiding software computes the error and corresponding pulse durations on RA and Dec. But the MCU should properly manage it. Nothing new...


--- Quote ---Normally one uses a subset of  lets say 40 by 60 pixels depending on how large a pixel is and how faint the guiding star was chosen. An MCU can do that in a couple of hundred milliseconds where a CPU does that in some some milliseconds to hundred nanoseconds. All we have to ensure is to stay below 997 milliseconds because that's what is the critical time you see a result with common telescope apertures. The large a telescope is, the more accurate it has to be and what's good for the large is good for the smaller ones, too.
--- End quote ---
It's obvious a PC guiding software is required. Do you mean to implement also a new guiding software? I think it's not worth it.

CS
Armando

Astroquattro:

--- Quote from: Armando on Thursday, 19.09.13 - 00:28:55 - CEST ---
--- Quote from: Astroquattro on Thursday, 19.09.13 - 00:10:18 - CEST ---Since auto guiding is based on looking at the offset of a guiding star between to images, and correcting that offset right away, the speed differs because of how far the shift was. To do that as accurate as possible taking the image, downloading it from the ccd or cmos, pinpointing the center of the guiding star, measuring its x and y position and calculating the offset transferring it to µsteps and passing it to the motors, a CPU has it's advantages as I pointed out.
--- End quote ---
In fact I think the controller should be compatible with current guiding software...
The PC guiding software computes the error and corresponding pulse durations on RA and Dec. But the MCU should properly manage it. Nothing new...


--- Quote ---Normally one uses a subset of  lets say 40 by 60 pixels depending on how large a pixel is and how faint the guiding star was chosen. An MCU can do that in a couple of hundred milliseconds where a CPU does that in some some milliseconds to hundred nanoseconds. All we have to ensure is to stay below 997 milliseconds because that's what is the critical time you see a result with common telescope apertures. The large a telescope is, the more accurate it has to be and what's good for the large is good for the smaller ones, too.
--- End quote ---
It's obvious a PC guiding software is required. Do you mean to implement also a new guiding software? I think it's not worth it.

CS
Armando

--- End quote ---

Did you take a look at the software lately? Guide9's gui is pretty oldschool. It is infact the same look and feel as it was when it started as a DOS program. Bill Grey said, that he know C and C++ to get the algorithms right and the concepts fast, but he does not know opengl nor direct_lightning nor other graphics libraries and he does not have the time to get them to know good enough to build a modern gui. The Sky is nearly the same but it relies completely on Windows therefore forget about it's calculations they have nothing to do with realtime. If you run Guide with Windows it's the same, but you can use wine under Linux and than you have realtime and the benefits. Those two programs are nice for pointing to targets and moving the telescope but they do not support autoguiding the way it is useful. MaximDL does that for good, but it lacks the other way round, no good star map program and it's pointing is rather bad. Stellarium is a virtual planetarium with the capability to move telescopes. It claims to be as accurate as Guide9 but it isn't. What ever, it moves the telescope but has not autoguiding section. CCDobs, Nebulosity3 and all the other do control the camera but their guiding has issues and lack important parts one needs by getting all necessary images like bias frames in the first place, the do it amateur style and think that "a calibration" is what has to be done. It's like Msoft think that you need a "logical device (c:)" and the user is not capable of understanding the concept of partitions and file systems. I had a little test on all those ccd recording programs which give the user reduction capabilities and compared them to pro stuff like IRAF and MIDAS. Producing a masterbias should, if you use the same images and the same algorithm without any weighting function in it, the same result over and over again. You get that with for example IRAF and can proof it by doing so and substracting the resulting images from each other with complete black images. However I did that with MaximDL's "calibration", with images I got out from Fitswork, AstroImageJ, Nebulosity, CCDStack etc, the results were different and even if you do it ten time with one program allone, the results were different.
So much for that.

For example the Badlands Observatory in South Dokota uses old Dos software for slewing the telescope and that is common.
At my home town observatory we do the same. Our control software was written in pascal and is still a Dos program because you can't compile it for Windows. It won't run! It is specificly written for Dos. I won't compile with necessary changes on Linux either. Badlands uses MaximDL for guiding because their is no better.

Yes of course I have to write new Software because we are using new hardware. Using Arduino with shields doesn't free you from writing new Software. I don't want to develop the wheel again, but since what's on the market isn't a complete suite which gives us the opportunity to get a piece of software that is a summarization of all the good things without the lacks.

We won't start writing another ASCOM driver, because that would turn all the advantages we just pointed out in. Besides, the software should be plattform independant. So no ASCOM allowed. Building a gui with python3 and QT which runs on every OS even on smartphones and tablets is easy because of QT's designer. Implementing all the nice features within modules is easy, too and gives us the possibility to just use or provide what the telescope and the other equipment let's us do. For example, you do not need auto guiding if you just want to go visual or haven't cameras. The bare minimum can also be used as stand-alone version, but that is only optional not the main goal!

Loose yourselves from the idea that a handheld stand-alone version mirrors state of the art telescope usage. What's good for scientists is good for amateurs, too. Not only the hard- and software but methods and ways of doing things. Scientist like it easy, reliable and comfortable but not screwed up.

The telescope controls at the big observatories are very easy to use so most times, it's profound to the observer and one can do that after half an hour. What's very much more complicated is, setting up an amateur telescope for the night because hard- and software, when it's even there, is not meant to be use for such equipment.

One or two sentences to writing new software for the Arduino or in general... whether you build new closed or open hardware you need to write a new piece of software anyway. You have to implement ASCOM support, you have to write cpp code to be loaded to Arduino, that is new software!

cheers,
Christian

Armando:
Hi Christian,

what do you think about Metaguide?

Anyway I think Qt framework is a cross-platform framework if you don't mean to communicate to specific hardware.
Try just to make use of serial COMs on Linux and XP/W7 by an unique code... Try to make use of an USB HID; then let me know...
What camera should be supported by your guiding software?

I think you meant to make a new mount controller; now I really don't know...

--- Quote ---whether you build new closed or open hardware you need to write a new piece of software anyway. You have to implement ASCOM support, you have to write cpp code to be loaded to Arduino, that is new software!
--- End quote ---
Ok, you excluded ASCOM. So develop a new controller, a new cross-platform guiding software able to communicate to the controller on each OS. Then remember your guiding software should be able to communicate to a guiding camera. Only one? You'll have to offer support for each camera on each OS... Good work!  :)

CS
Armando

Navigation

[0] Message Index

[#] Next page

[*] Previous page