sleat
New Member
Posts: 12
|
Post by sleat on Nov 19, 2018 13:13:20 GMT
OK, First test with the NEQ 6 mount.
For ASCOM, you may need to get your USB serial port set to a low number, like com 2. You can do this in device manager.
So, it connects to the scope just fine, assuming you use the chooser correctly.
It of course, loads three-line data from space-track.org for something soon to arrive.
In this configuration, there is no camera. No source of images via USB on this computer right now, so presumably it should just "dummy" the camera and not get any guidance from it.
So, we hit "Start Tracking Satellite"
It wants us to "start camera first", so we do this.
When we hit "Start Tracking Satellite" again, we get something referring to dnow.
So, the question is, will the program run with no camera plugged-in at all? Seems like NEO did, and slewed my scope around under its own control.
Here's a few lines from the command prompt screen, where it spits its errors to the console so you can see them:
C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts>SatTrakerBetaV1.py
Connecting to Scope.
Connected to telescope now
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\tkinter\__init__
.py", line 1705, in __call__
return self.func(*args)
File "C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts\SatTrakerBet
aV1.py", line 877, in set_tracking
self.axis0rate = float(self.tel.AxisRates(0).Item(1).Maximum)
AttributeError: 'tuple' object has no attribute 'Item'
Start Camera First!
Select TLE File First!
C:/Users/me/AppData/Local/Programs/Python/Python37/Scripts/ESTCube.txt
Start Camera First!
Starting Camera.
Exception in thread Thread-2:
Traceback (most recent call last):
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\threading.py", l
ine 917, in _bootstrap_inner
self.run()
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\threading.py", l
ine 865, in run
self._target(*self._args, **self._kwargs)
File "C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts\SatTrakerBet
aV1.py", line 396, in sat_track
self.dlast = self.dnow
AttributeError: 'buttons' object has no attribute 'dnow'
Stopping Camera.
A few times that I tried it, it certainly did seem to connect to the 'scope.
Maybe I'd better plug in a Webcam or something, just to give CV2 something to chew on.
Any ideas?
|
|
|
|
Post by Astronomy Live on Nov 20, 2018 14:55:05 GMT
At the moment SatTraker isn't designed to work without a camera attached. dnow is a variable created when each frame is received from the camera, in order to ensure that the tracking algorithm works in sync with the camera and doesn't track each video frame more than once. It doesn't get created as a variable if there isn't a camera delivering images, which is why it gave that error. If you hook up a webcam to feed the program images it will work, you need to do that even if you just want to run it open-loop without video tracking (which is unlikely to place a satellite in the field of view unless you're using quite a wide field of view).
|
|
sleat
New Member
Posts: 12
|
Post by sleat on Nov 23, 2018 10:38:09 GMT
Great! I can organize that video source!
Once I plug in a video capture dongle (with a camera) or dedicated webcam, how do I ascertain the "camera number" required parameter?
EDIT: OK, great. Just plugging in a capture dongle fixes the "Start Camera" bit. No actual camera needed, I guess.
Also, just one other question to get me going again;
Previously I was photographing the ISS just by manually "aiming" the scope with the locks off, using a Telrad, which actually worked, but was a bit painful. Your way is obviously far more civilized.
Now, doing some satellite tracking with "Satellite Tracker" from Heavenscape, I've managed to get the mount (in the living room) to follow various satellite passes where the mount seems to be pointing the right way, but I have a niggling uncertainty about the RA axis.
Now, let's say you start your EQ mount with the RA axis "parked", maybe just physically "vertical" i.e. the long axis of the first moving part is vertical, and the DEC pointing to -90.
You've set the 'scope location to your location. The actual RA that the scope is at while "parked" is dependent on the sidereal time.
Basically, unlike an ALT-AZ mount, the RA axis is "uncalibrated" before you align the scope, it seems, unless the scope firmware keeps track of what the RA of the scope is whilst it's parked and on, assuming you started from "park" and aligned the scope at some point in the past, and didn't change anything else.
So, does this mean that with an EQ mounted scope being used to track satellites, that the axes should first be calibrated to actual celestial objects each time?
Have you tried this IRL with your EQ mounted 'scope?
I'm assuming that's probably the case, since clearly the encoders' frames-of-reference need to come from somewhere.
|
|
sleat
New Member
Posts: 12
|
Post by sleat on Nov 23, 2018 12:29:16 GMT
At the moment SatTraker isn't designed to work without a camera attached. dnow is a variable created when each frame is received from the camera, in order to ensure that the tracking algorithm works in sync with the camera and doesn't track each video frame more than once. It doesn't get created as a variable if there isn't a camera delivering images, which is why it gave that error. If you hook up a webcam to feed the program images it will work, you need to do that even if you just want to run it open-loop without video tracking (which is unlikely to place a satellite in the field of view unless you're using quite a wide field of view). OK, here's some dump from trying with the EQMOD Telescope simulator, instead of the actual 'scope. It seems to get further! It might be that I need to hook back up to the actual 'scope. C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts>SatTrakerBetaV1.py
Starting Camera.
Connecting to Scope.
Connected to telescope now
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\tkinter\__init__
.py", line 1705, in __call__
return self.func(*args)
File "C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts\SatTrakerBet
aV1.py", line 877, in set_tracking
self.axis0rate = float(self.tel.AxisRates(0).Item(1).Maximum)
AttributeError: 'tuple' object has no attribute 'Item'
C:/Users/me/AppData/Local/Programs/Python/Python37/Scripts/E-STAR TLE.txt
38.3023190629419 4.728983029686951
Exception in thread Thread-2:
Traceback (most recent call last):
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\threading.py", l
ine 917, in _bootstrap_inner
self.run()
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\threading.py", l
ine 865, in run
self._target(*self._args, **self._kwargs)
File "C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts\SatTrakerBet
aV1.py", line 433, in sat_track
self.tel.Tracking = False
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\site-packages\wi
n32com\client\dynamic.py", line 581, in __setattr__
raise AttributeError("Property '%s.%s' can not be set." % (self._username_,
attr))
AttributeError: Property 'EQMOD_SIM.Telescope.Tracking' can not be set.
Disconnecting the Scope.
Connecting to Scope.
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\site-packages\wi
n32com\client\dynamic.py", line 89, in _GetGoodDispatch
IDispatch = pythoncom.connect(IDispatch)
pywintypes.com_error: (-2147221005, 'Invalid class string', None, None)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\tkinter\__init__
.py", line 1705, in __call__
return self.func(*args)
File "C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts\SatTrakerBet
aV1.py", line 864, in set_tracking
self.tel=win32com.client.Dispatch(driverName)
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\site-packages\wi
n32com\client\__init__.py", line 95, in Dispatch
dispatch, userName = dynamic._GetGoodDispatchAndUserName(dispatch,userName,c
lsctx)
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\site-packages\wi
n32com\client\dynamic.py", line 114, in _GetGoodDispatchAndUserName
return (_GetGoodDispatch(IDispatch, clsctx), userName)
File "C:\Users\Joe\AppData\Local\Programs\Python\Python37\lib\site-packages\wi
n32com\client\dynamic.py", line 91, in _GetGoodDispatch
IDispatch = pythoncom.CoCreateInstance(IDispatch, None, clsctx, pythoncom.II
D_IDispatch)
pywintypes.com_error: (-2147221005, 'Invalid class string', None, None)
|
|
sleat
New Member
Posts: 12
|
Post by sleat on Nov 24, 2018 10:43:06 GMT
At the moment SatTraker isn't designed to work without a camera attached. dnow is a variable created when each frame is received from the camera, in order to ensure that the tracking algorithm works in sync with the camera and doesn't track each video frame more than once. It doesn't get created as a variable if there isn't a camera delivering images, which is why it gave that error. If you hook up a webcam to feed the program images it will work, you need to do that even if you just want to run it open-loop without video tracking (which is unlikely to place a satellite in the field of view unless you're using quite a wide field of view). OK, Here's the latest attempt, with the actual scope running in "PC Direct Mode" and with a video source available, selected, and displaying (dead-air, no picture). Worth noting not only did NEOTraker connect in this way, but it actually slewed this same scope, same setup, with some semblance of routine control. However, in this iteration, we start popping out exceptions right away, soon as we finish connecting. It does connect okay from the 'scopes point of view, the ASCOM chooser comes up, and we get the "control pad" up on the screen. Here's the command line dump: C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts>SatTrakerBetaV1.py
Starting Camera.
C:/Users/me/AppData/Local/Programs/Python/Python37/Scripts/Max Valier Sat.txt
Connecting to Scope.
Connected to telescope now
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\tkinter\__init__
.py", line 1705, in __call__
return self.func(*args)
File "C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts\SatTrakerBet
aV1.py", line 877, in set_tracking
self.axis0rate = float(self.tel.AxisRates(0).Item(1).Maximum)
AttributeError: 'tuple' object has no attribute 'Item'
13.382125785452978 -40.5096027102644
Exception in thread Thread-2:
Traceback (most recent call last):
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\threading.py", l
ine 917, in _bootstrap_inner
self.run()
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\threading.py", l
ine 865, in run
self._target(*self._args, **self._kwargs)
File "C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts\SatTrakerBet
aV1.py", line 433, in sat_track
self.tel.Tracking = False
File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\site-packages\wi
n32com\client\dynamic.py", line 581, in __setattr__
raise AttributeError("Property '%s.%s' can not be set." % (self._username_,
attr))
AttributeError: Property 'EQMOD.Telescope.Tracking' can not be set.
It appears that the code is trying to set an attribute which ASCOM doesn't think can be set, after unsuccessfully trying to read one axis's max rate. Could it be your ASCOM object model reference material for rates is out-of-date? Maybe you could use a different enumerator/iterator expression to get that value? This structure-read/assignment fails: self.axis0rate = float(self.tel.AxisRates(0).Item(1).Maximum) Maybe use axisPrimary and axisSecondary definitions to get to the values instead? I guess you might also try just blind commanding the thing with standard rates, letting ASCOM do the polite stuff, rather than being polite with that mount whispering it looks like you're doing. If it starts skipping steps due to inappropriate stepper control, or doing other funny things, I can easily pull the power, not that this is likely to do any mechanical damage. Hope this helps! I'd be glad to answer any questions about the setup. If you want I should edit the source, and try again, you can feed me some edits, or I could have a look myself if I can so motivate. Cheers, sleat |
|
|
|
Post by Astronomy Live on Nov 27, 2018 18:26:11 GMT
Ok it seems like the error has to do with how the EQ mount is returning the values for the maximum slew rates. "AttributeError: 'tuple' object has no attribute 'Item'" seems to imply it's returning a simple tuple (probably drive number and drive rate) rather than the kind of generator object that my NexStar returns. The odd thing is that I would have thought this would be standard across all ASCOM drivers. That's supposed to be the point of ASCOM, it should standardize how these mounts communicate. My bigger concern is what this means for other mounts, my plan was that testing the software on NexStar would clear out bugs for other ASCOM mounts, but I guess not? My mount does not give this kind of error, but maybe it has to do with the scope being in Alt/Az rather than Polar mode. I'll check that later today if I can get the time. I definitely need my software to know the maximum drive rate though, that's not optional. If the software requests a higher drive rate than the telescope supports then it will start throwing up ASCOM errors and cause the software to lose control of the telescope. Even though you can pull the plug on the mount, that's not ideal and not really acceptable. It will likely do this near the start of the tracking. After the initial slew is completed the software will have to do catch-up and this usually results in hitting near or past the max slew rate limits of my NexStar. Slew rate limiting is really mandatory. Let me see if I can find out more info on why your mount is reporting a tuple where it wasn't expected. In the meantime, please verify you're using the latest version of SatTraker, the line numbers those errors are reporting do not seem to line up with where those lines should occur in the current version. github.com/AstronomyLiveYt/SatTraker/blob/master/SatTrakerBetaV1.py |
|
sleat
New Member
Posts: 12
|
Post by sleat on Nov 27, 2018 21:12:37 GMT
Ok it seems like the error has to do with how the EQ mount is returning the values for the maximum slew rates. "AttributeError: 'tuple' object has no attribute 'Item'" seems to imply it's returning a simple tuple (probably drive number and drive rate) rather than the kind of generator object that my NexStar returns. The odd thing is that I would have thought this would be standard across all ASCOM drivers. That's supposed to be the point of ASCOM, it should standardize how these mounts communicate. My bigger concern is what this means for other mounts, my plan was that testing the software on NexStar would clear out bugs for other ASCOM mounts, but I guess not? My mount does not give this kind of error, but maybe it has to do with the scope being in Alt/Az rather than Polar mode. I'll check that later today if I can get the time. I definitely need my software to know the maximum drive rate though, that's not optional. If the software requests a higher drive rate than the telescope supports then it will start throwing up ASCOM errors and cause the software to lose control of the telescope. Even though you can pull the plug on the mount, that's not ideal and not really acceptable. It will likely do this near the start of the tracking. After the initial slew is completed the software will have to do catch-up and this usually results in hitting near or past the max slew rate limits of my NexStar. Slew rate limiting is really mandatory. Let me see if I can find out more info on why your mount is reporting a tuple where it wasn't expected. In the meantime, please verify you're using the latest version of SatTraker, the line numbers those errors are reporting do not seem to line up with where those lines should occur in the current version. github.com/AstronomyLiveYt/SatTraker/blob/master/SatTrakerBetaV1.pyEDIT: OK, I've grabbed the latest version, although the name (...BetaV1) hadn't changed. This version required imutils to be added, and a few other things. So, I did the edit described below to get the rates, and that's the only mod to your code. Regarding the exact mount-type, it's a Skywatcher NEQ6Pro with a Synscan (V4) hand controller. I can pull the HC firmware version if you need it. EDIT: I can also pull the MC firmware version... Again, we can successfully get the max drive rates now. The current problem appears to be setting the TRACKING attribute. Could it be "read only" until the mount is properly aligned? My other problem is getting the whole show to work using the "Skywatcher" driver, which is from the people who make my mount, rather than the vanilla ASCOM HEQ5/6 mount driver, which will control the mount, in other ways besides this. This may be a firmware issue, so I'll try to backup and grab the latest FWs for both the motor-controller and the handset. Here's the latest command-line dump: RESTART: C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts\SatTrakerBetaV1.py Starting Camera. C:/Users/me/AppData/Local/Programs/Python/Python37/Scripts/CZ11 RB.txt Connecting to Scope. Connected to telescope now 3.3424593333333332 3.3424593333333332 C:/Users/me/AppData/Local/Programs/Python/Python37/Scripts/Hoopoe.txt 61.651904865418935 -22.946528018726326 Exception in thread Thread-2: Traceback (most recent call last): File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\threading.py", line 917, in _bootstrap_inner self.run() File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\threading.py", line 865, in run self._target(*self._args, **self._kwargs) File "C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts\SatTrakerBetaV1.py", line 453, in sat_track self.tel.Tracking = False File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\site-packages\win32com\client\dynamic.py", line 581, in __setattr__ raise AttributeError("Property '%s.%s' can not be set." % (self._username_, attr)) AttributeError: Property 'EQMOD.Telescope.Tracking' can not be set. Looks like for some reason, the "Tracking" telescope property still cannot be set. This is while actually connected, with the scope responding to the onscreen slew-pad properly, using the HEQ5/6 choice in ASCOM. I also tried the new "Skywatcher" driver, which matches my Synscan handset, apparently, but for some reason, I can't set COM2 in that one, although COM2 works in the HEQ5/6 driver. =================================================================== Earlier: I did a little sniffing around with the types and tuples while I was waiting, and managed to get what look like sensible rates by modifying the AxisRates assignment code. self.axis0rate = float(self.tel.AxisRates(0)[0].Item(1).Maximum) You can verify if you use the telescope simulator driver. This doesn't match the documentation I have, since you'd expect only the COMObect to be returned, and then the code would work as you wrote it. Basically we know AxisRates is a function that is supposed to return an IAxisRates object. AxisRates() DOES return a tuple, when using the ASCOM telescope simulator. It contains an embedded COMObject as its 0th [0] element, and seemingly its own argument as the EDIT: first [1] element. So if you refer to the COMObject.Item(1).Maximum that is then a valid statement. This was revealed whilst testing, not with my actual mount, but with the ASCOM telescope simulator. I think that may be important, so I'll re-test with the actual Synscan-controller-connected NEQ6. There are two driver choices in the ASCOM chooser that should be appropriate for my hardware, and so I'll test with both of them. One is ASCOM HEQ5/6, and the second is called SkyWatcher Telescope When using the simulator, Telescope.Tracking property seems not to be writeable, which crashes the code a bit later. I'll test that with actual hardware drivers as well, and update you when I've done that, hopefully before heading to work in 2 hours or so. Here's the most recent Idle command line dump, with the simulator and my slight edits shown above. RESTART: C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts\SatTrakerBetaV1.py Starting Camera. Connecting to Scope. Connected to telescope now axis0rate: 3.3424593333333332 axis1rate: 3.3424593333333332 C:/Users/me/AppData/Local/Programs/Python/Python37/Scripts/CZ11 RB.txt 177.33500993387176 12.48302919559338 Exception in thread Thread-2: Traceback (most recent call last): File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\threading.py", line 917, in _bootstrap_inner self.run() File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\threading.py", line 865, in run self._target(*self._args, **self._kwargs) File "C:\Users\me\AppData\Local\Programs\Python\Python37\Scripts\SatTrakerBetaV1.py", line 433, in sat_track self.tel.Tracking = False File "C:\Users\me\AppData\Local\Programs\Python\Python37\lib\site-packages\win32com\client\dynamic.py", line 581, in __setattr__ raise AttributeError("Property '%s.%s' can not be set." % (self._username_, attr)) AttributeError: Property 'EQMOD_SIM.Telescope.Tracking' can not be set. |
|
sleat
New Member
Posts: 12
|
Post by sleat on Nov 27, 2018 22:19:21 GMT
See updates to previous post with actual scope hardware.
Also, another few things; I'll try to get the Skywatcher driver to work, by cleaning up my Serial Port registry gunk (all showing "in use" even though not), and enable command tracing to see if I can determine why the "Tracking" property CAN be set by the onscreen control-pad, but CANNOT be set programatically in ASCOM via Python.
The other ASCOM driver (HEQ5/6) also allows tracing I believe, so I'll try that, too if I can.
|
|
|
|
Post by Astronomy Live on Nov 30, 2018 16:49:27 GMT
Thanks for all your help sleat. I'm sorry I got bogged down by some other distractions, namely a troll who is now trying to get my all-sky cam YouTube channel taken down, as well as issues with webcam interfacing with Python on my end. My laptop is acting bizarre when OpenCV tries to request access to a camera, and it doesn't deliver images now. Nothing changed in the program, it's something to do with the laptop itself. I think Windows might have changed its default API preference for webcams for some reason, maybe from VFW to DirectShow or vice versa or to something else altogether. I'm trying to track down what's causing it, it happened once before and I fixed it by rolling back Windows, but that hasn't helped this time around. I tried your fix to specify one part of the tuple in the ASCOM drive rate request, but it didn't seem to like that and generated errors. I'm still not sure why it gives errors for your EQ but not for my Celestron.
|
|
sleat
New Member
Posts: 12
|
Post by sleat on Dec 2, 2018 3:01:35 GMT
Thanks for all your help sleat. I'm sorry I got bogged down by some other distractions, namely a troll who is now trying to get my all-sky cam YouTube channel taken down, as well as issues with webcam interfacing with Python on my end. My laptop is acting bizarre when OpenCV tries to request access to a camera, and it doesn't deliver images now. Nothing changed in the program, it's something to do with the laptop itself. I think Windows might have changed its default API preference for webcams for some reason, maybe from VFW to DirectShow or vice versa or to something else altogether. I'm trying to track down what's causing it, it happened once before and I fixed it by rolling back Windows, but that hasn't helped this time around. I tried your fix to specify one part of the tuple in the ASCOM drive rate request, but it didn't seem to like that and generated errors. I'm still not sure why it gives errors for your EQ but not for my Celestron. Sorry to hear about your driver config going awry. Have you tried re-installing (or just disabling/enabling) your webcam device drivers? As far as trying my edit, it's important to note that it also works with the simulator, at least on my end, no telescope needed. If you wanted to incorporate *both* "handlings" of the AxisRates() call, just look for the types and lengths, and case accordingly. If the thing returns a 2-tuple, with the first one being a COMObject and the second being presumably, your calling axis argument, it's the other version. I still can't fathom how ASCOM calls this a "standard". But note well, so far I'm getting exactly the same errors, both with the actual 'scope, either thru the Synscan hand-controller or direct through an EQ6 "shoestring" interface, or through the ASCOM Edit: EQMOD simulator. But still, it seems to me that if you could get SatTraker to work with the various ASCOM simulators for EQ mount scopes, it would probably work with mine and others as well. What do you think? EDIT: I think the EQMOD stuff is part of the problem, at least with Python. The ASCOM stuff seems a lot better. What does your driver return when you call AxisRates() as far as type and len both for the returned object, and for the internal things? For me, I get a COMObject (with its own details and internal structure) and what appears to be its own argument as the next tuple element. So, in other words, what type(s) and length is returned by *your* AxisRates() call? float(self.tel.AxisRates(0).Item(1).Maximum) being the original code that works with yours, and self.tel.AxisRates(0)[0].Item(1).Maximum being the code that *appears* to return rates with both mine and the simulator. Aside from this, what's really troubling me is that the "Tracking" property of Telescope cannot be set. EDIT: Except in the non EQMOD simulators supplied with ASCOM. One suspicion I have is that maybe this property is locked until alignment is done. Studying the alignment data in the dialogs when the sim is running indicates that it thinks alignment has not been done. Another odd thing seems to be that my Skywatcher ASCOM driver, running against a Skywatcher scope and handset, doesn't return a valid COM port, even though the driver's stated function is to detect valid Skywatcher hardware on connected COM ports (it's connected) and allow the user to use that COM port. Wonder why it doesn't just allow the user to set the desired COM port based on empirical data? |
|
|
|
Post by Astronomy Live on Dec 4, 2018 22:10:38 GMT
Doing self.tel.AxisRates(0)[0].Item(1).Maximum generates an <unknown>.Item attribute exception with I try the .Net ASCOM simulator. self.tel.AxisRates(0).Item(1).Maximum generates a float for which len() does not yield any info, it just generates an exception that it's a float and therefor len() is not valid for it (even without my redundant statement assigning it as a float).
|
|
sleat
New Member
Posts: 12
|
Post by sleat on Dec 6, 2018 5:26:49 GMT
Doing self.tel.AxisRates(0)[0].Item(1).Maximum generates an <unknown>.Item attribute exception with I try the .Net ASCOM simulator. self.tel.AxisRates(0).Item(1).Maximum generates a float for which len() does not yield any info, it just generates an exception that it's a float and therefor len() is not valid for it (even without my redundant statement assigning it as a float). Yes, it appears that the EQMOD/EQMODLX drivers (separate package) do one thing, and the included ASCOM drivers do something different. If you do AxisRates(0)[0].Item(1).Maximum with the EQMOD driver, or sim, you get a number that appears to be a float, although I didn't type-check it yet. As I mentioned in the PM I sent you on this forum, your unedited code works on the .NET ASCOM simulator, at least superficially, only with self.tel.Tracking = False removed. Again, I'm eager to test with the Skywatcher driver, but I currently can't get it to acknowledge that any COM port exists with my mount behind it. I've contacted Skywatcher about this problem, and they're apparently looking into it. With Heavenscape Satellite Tracker running against EQMODLX, it basically uses the EQMOD driver to connect to the 'scope, although it may also be able to use the Skywatcher driver. Did you get my PM message about the breakthrough I had? Running the code as you originally wrote it, but commenting out the Tracking attribute set command, it does seem to work with the .NET simulator here! That's why I'm focusing on getting the Skywatcher driver working here, as I think it's more like standard ASCOM object-model, rather than whatever the EQMOD people have done. |
|
|
|
Post by Astronomy Live on Dec 7, 2018 11:16:28 GMT
Just now saw the PM, thanks for the update. I'll comment out the self.tel.tracking statement and see how that goes. Unfortunately I thought my laptop was working with external cameras only to find out this morning that my video capture card is not working with the laptop, only external regular webcams. It's really odd, I think something's gone wrong with this laptop's internal webcam system and it's screwing up my program's ability to access the capture card. I had everything set up to track Hubble, but no dice. I may break down and buy a dedicated laptop for this project.
|
|
|
|
Post by Astronomy Live on Dec 8, 2018 2:49:55 GMT
I went ahead and acquired a new laptop to use for astronomy and for this project specifically. It seems to be working well so far, but now I get to do the fun dance of reinstalling python and all the dependencies from scratch again. I can't wait to have a stable release version compiled that I can easily distribute to naive machines.
|
|
sleat
New Member
Posts: 12
|
Post by sleat on Dec 8, 2018 7:10:34 GMT
Just now saw the PM, thanks for the update. I'll comment out the self.tel.tracking statement and see how that goes. Unfortunately I thought my laptop was working with external cameras only to find out this morning that my video capture card is not working with the laptop, only external regular webcams. It's really odd, I think something's gone wrong with this laptop's internal webcam system and it's screwing up my program's ability to access the capture card. I had everything set up to track Hubble, but no dice. I may break down and buy a dedicated laptop for this project. I share your pain! Hardware failures always bog me down, too. I spoke with the local Skywatcher rep here in French's Forest NSW, and he was very up-beat and enthusiastic, and promised to help me solve my "no valid Skywatcher mount found" conundrum (despite the fact that 100% of the rest of my setup is working) but apparently hasn't heard from the higher-ups yet. It'd be great if they'd just publish the VB source for the darn thing, it's only a driver, after-all, and it's not like people will be pirating it, since it's free to all, and only useful to people who own the hardware. Again, with the .NET ASCOM simulator driver, it seems to do something with TLEs for objects that should be above the horizon, as long as some image source is connected, but it doesn't require an image, apparently. It sort of seemed to diverge and get a bit wild near the end of the pass, so that was interesting, but it'll be better with a live set of steppers on the other end that I can actually hear and see. Maybe the datadump whilst tracking could be a bit better formatted, i.e. current coords every 10 iterations, and rates in-between, or something. That would help me see if the thing is making sense, I think. EDIT: Regarding datadumps, and the screen filling up with numbers while the thing is tracking, it's important to note that when something needs to run "on the clock" and be synchronous with real-time, finishing everything before the next iteration is due, prints, especially ones that cause scrolling in uncontrolled environments like Windows, don't return until they finish doing their thing, unless the time-critical part is in a separate thread, or running on an interrupt. This may cause you to be late for a tracking iteration, and it's not hard to imagine the numbers going a bit wild if that happens, most likely resulting in the system that's trying to "zero in" on a target value to oscillate. You can see this in a simple realtime PID servo, where, if you skip processing loop steps, or run them late, you get oscillation or "hunting". You're probably already aware of this, but I thought it'd be good to throw out there. One counter to this is to go ahead and print, and possibly skip-steps, but keep monitoring the actual time in millis or micros, and then change the feedback based on whether time was lost. Basically you're fighting the tendency for the loop to: See target values diverging from current value too fast=>speed up rate=>overshoot=>see overshoot=>slow down the rate=>undershoot=>speed up...and so on. |
|
