×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Driver OnStep (LX200 like) for INDI

  • Posts: 257
  • Thank you received: 22
Finally got around to some testing and have clear skies too! Initial build and run looks good so far.
The frequency adjust buttons show and take commands. This is good. I'll know if it works for sure as soon as I get focused and tracking. Since it updates the firmware I think it will hold across boots, but I can't remember for sure. i'll try to test that at some point- probably at shutdown. As for feedback of frequency, there is a line there(tracking frequency - freq) that seems to be getting it from firmware. If we update/call that line when the +- buttons are used I think it should show the change.
buy that man a beer! The pesky 60.1 limit is gone! My worn out worm gears thank you! I'll edit this and add anything I find as I go.

Followup, before I forget, I think the PEC should default to OFF since it's an addon and people who use guiding will probably not go the extra for it...and it appears to cause issues if it is running without data for some reason..or i'm crazy and only THINK it does... i've been turning it off, and found an encoder in scrap at work just in case.. :)

observations:
  • The +- button goes down but stays down. I can't see it making changes after that and it doesn't appear to effect speed.
  • --update, I think it is working, just looks weird.
  • Changing frequency now works and effects speed, even above 60.1(woot)
  • Verified changes do not cross reboots of onstep arduino, or are cleared by driver which returns to 60.1643.
  • I had some very strange behavior a while ago i'm still trying to pin down. Even astrometry seems effected. - I found the auto meridian flip was disabled

    Day 2 observations:
  • Park/unpark has a syncing problem and will not unpark.
  • Suggestion: Maybe it should automatically call unpark if you turn on tracking as presumably you want to go somewhere is tracking is enabled.

    There is still some kind of sync or parsing problem keeping it from unparking. I had to go out to the mount and use bluetooth phone app to set home(reset) and then unpark the thing. I had tested it in daylight(fixed a mechanical dec axis lash issue) and then parked it for several hours until after dark to keep the motors cool. I couldn't get it to unpark from ekos no matter what I tried. Slews reported okay and in slew but no motion from the mount or kstars indicator. I didn't have any weird mount wrong way crashes during the second night of testing. I think the auto meridian flip was off somehow and last checked with the app during startup to make sure it was on.
  • Last edit: 5 years 9 months ago by Ray Wells. Reason: Edited for clarity when more awake.
    5 years 9 months ago #26582

    Please Log in or Create an account to join the conversation.

    • Posts: 161
    • Thank you received: 39
    I think you are right with the PEC. That's on my list next. Including training.

    When I looked at it, it never clears it, so if the storage has been used before, it will have whatever is on it. So agreed on it should default to off.

    The other thing is the alignment in the Alpha branch which is changing. I think the plate solver can be used to make it easy.
    5 years 8 months ago #27019

    Please Log in or Create an account to join the conversation.

    • Posts: 257
    • Thank you received: 22
    Integrating that into a scripted 3 star routine would be fantastic! Sit back and watch the mount tune itself. 8-)

    Extra long project update..hopefully not overcooked by all my editing:
    I'm in planetary mode right now and can't see stars (4500mm f30!) but my usual dso/eaa/ap setup(asi178mm/150mm f4 newt) sees everything, and after installing a ton of Astrometry.com data files I can report good service from the plate solving and alignment feature. Sure beats trying to get lined up on Jupiter with a misaligned guide camera and a noisy dark main one.
    I may be playing with PEC with my next build. I'm a bit confused with the way they are using it though. I would go with a high resolution encoder and hit the error reset more often than once a shaft revolution instead of using the Z shaft index. I'll have to study the code and find some online info when I get into it. I found a couple of the little red lion shaft encoders to try, and a super 24bit absolute encoder I rescued from the scrap pile at work which got me interested in trying it.
    My current project has badly outgrown its little control box and I'm making something bigger to house things. Bigger power supply requirements for dew heaters, tec cooling(a water pump!?) etc. and 4amp capable stepper controllers(hopefully better than drv8825's) caused the latest upgrade cycle.
    Hope you guys are well and not getting cooked in all this heat. :)
    Last edit: 5 years 8 months ago by Ray Wells.
    5 years 8 months ago #27033

    Please Log in or Create an account to join the conversation.

    • Posts: 322
    • Thank you received: 31

    Having plate solving integrated with OnStep alignment has been something on my to do list for some time.

    Whether it is the old alignment or the new one, it does not matter.

    The idea I have in mind is changing OnStep, so that

    If:

    a) alignment is started (:Ax# issued),
    b) not yet completed (no :AW# issued),

    And:

    A :CM# is issued,

    Then:

    Treat each :CM# as an alignment point.

    All this has to be within OnStep itself.

    If Howard agrees to doing this, and sees no problems with it, this will allow the INDI OnStep driver to start an align, take a few images on the sky (using the Align Model tool), and that is all there is to it.

    No need to center a stars, no eyepiece required!
    Last edit: 5 years 8 months ago by Khalid.
    5 years 8 months ago #27034

    Please Log in or Create an account to join the conversation.

    • Posts: 161
    • Thank you received: 39
    As far as the alignment, there's also another option which is to use INDI's model, to then update OnStep's. I think this is possible, but it'd be a lot more work. Given the power, I think it might ultimately be a better option, for things like Megas (which are restricted in the new code.) However, that's a batch of research to double check that it will work and to set it up. (If it does, then any change in the alignment setup will mean changes needed to do.) I think your solution is a lot better for getting it working.

    Alright: So opinion time:
    Here's a proposal for the UI on PEC. Top two are informational. I'd reuse the standard PEC control on the motion tab. (Which currently does nothing.) Or should I dispense with the PEC that inditelescope has, which can do exactly 2 things: Turn it on and off, and have it show there? (Actually I could probably as well.)

    Should it also display more information?

    Of note: I think that some of this should be incorporated into inditelescope, or a PEC Interface. But, as far as I can see only EQmod has anything like OnStep's capacities. Including triggering recording. For comparison I included a screenshot of EQMod's PEC training/enable tab. (To note, you have to modify code minorly it to get that to show up on Simulation.)

    I'll probably get the PEC training fairly soon. I also wanted opinions on the file format: Should it just be a raw dump without anything, or should it have data fields, like the information (buffer size, worm size, steps a second, etc) and verification on restoration? (Which will make it more complicated, but possibly made in a format compatible with tools like pecprec (eq-mod.sourceforge.net/pecprep/)) Which is noted as a tool that works with OnStep/ASCOM
    5 years 8 months ago #27226
    Attachments:

    Please Log in or Create an account to join the conversation.

    • Posts: 161
    • Thank you received: 39
    So I've implemented it to test that (took longer than expected to write), It's in my master, and a pull request with it has been submitted to azwing.

    It adds a new tab. Use either the existing alignment (Main), OR the new one. (I don't think anything terrible will happen, but since they mess with the same things in different ways...)

    Follow either the Manual setting or the Semi-Automatic one:
    Hit Start

    Per star (up to 6):
    Manual: Goto and then center.
    Automatic: Goto then plate solve
    Both: hit 'Issue Align' (I should probably change the name)

    After what you are comfortable with is done hit Finished Align.

    It does NOT currently: Give message if align points are accepted, It will however, give an Alert (red) if it fails. I will add that.
    It does NOT currently: Count the starts, or provide feedback via :A?#
    It does check if the finished works. If not, it will give you a "Align WRITE FAILED" in the status portion

    Let me know if that works for people, I'm going got out to test it. (On a Mega, so it might still have some issues.)
    The following user(s) said Thank You: Ray Wells
    5 years 8 months ago #27406

    Please Log in or Create an account to join the conversation.

    • Posts: 257
    • Thank you received: 22
    Excellent work James! I can't wait to try this. The nights are so short that testing that alignment is about all I'll get to do. I'm also using an arduino mega and on the new updated beta code (which was parallel to alpha when I did it). Is there anything I need to uncomment or add to enable tuning?

    This will give me the reason I've been looking for to put the newt back together and stop chasing darkness around with an sct at f30 trying to catch Jupiter between the trees.
    @azwing : how often are you pulling from master? I recently found a nasty bug that was effecting my zwo cameras and Knro fixed it in nightly. I just want to be sure it's made it to your branch before updating. -- I bet there's a way to tell in git :ponder:
    5 years 8 months ago #27411

    Please Log in or Create an account to join the conversation.

    • Posts: 322
    • Thank you received: 31
    I have code inside OnStep itself that allows the use of the Ekos Mount Model tool, without any changes in OnStep INDI.

    Basically, alignment is started from INDI with, say, 3 stars. Then Mount Model is configured to align on the same number of stars. As Mount Model slews to the stars selected, it takes images, does a plate solve, and sync on the coordinates of the solution. With my change, OnStep detects that an alignment is in effect, but not yet completed (i.e. :A3# started, but not enough iterations of :A+# done yet), and the :CM# internally calls a new function that mimics a :A+#, and this repeats until all stars are plate solved and aligned to.

    This requires my branch (see link below), which is a fork from Alpha, since the latter has the new alignment code that allows alignment anywhere in the sky.

    The workflow would be: in INDI, click Align 3, then go to Mount Model, add 3 stars, and let the mount process them (slew, take image, do plate solve, and sync to solution coordinates). By the time it finishes, the Alignment line in INDI should show 633, meaning 3 stars requested, and 3 stars completed.

    Here is an overview with links to the pull request.

    groups.io/g/onstep/message/3998

    If someone can test it that would be great.
    The following user(s) said Thank You: james_lan
    Last edit: 5 years 8 months ago by Khalid.
    5 years 8 months ago #27414

    Please Log in or Create an account to join the conversation.

    • Posts: 257
    • Thank you received: 22
    @kbahey: I'm not sure your code was intergrated when I did this. There's some cross coding going on there but I'm sure you guys will get it sorted out. I like this new method that can sync from plate solving, I was basically already using that, it just didn't update the mount model. There is also a set script in ekos for mount modeling for some types of mounts that might be used, but I don't have access to many of the low east and west stars it wants so haven't test it vs. OnStep code(which is apparently commented out in the mega version?). There is a super cool startup model to be had somewhere in all this, it just needs coordinating.

    TL;DR: inconclusive due to modeling not being enabled in mount, but I eventually got procedurally positive result.

    I got a chance to try a test this evening. With no OnStep(mega) changes I ran the new driver compiled from azwing and tried to align. I'm not sure what is going on so i'll just relate my experience.
    I hit align, did a goto to Vega just about at meridian and straight up. Then I fiddled with focus for a long time after just put the thing back together it was too far in and ran out of tracks...fixed that and then ran the solver. It solved and claimed nearby and synced to that position. so I issued a slew to vega from current plotted position expecting it to go there. Instead it did a meridian flip..okay it was close to time anyway I thought. So I decided to just do it again except this time I hit solve and slew in the plate solver... and it went home to flip again...but it already had to it tested the belts badly. Good thing I moved the mount out front where I could run and release the clutches.
    I hand aimed it near vega and am going to try to solve and sync again. Meanwhile the system thinks it went home for no apparent reason. I manually synced it back to vega for easier solution.(this will prove an error) I moved it until I found a small cluster and solved again and this time it worked. So I moved to vega, got it centered, synced, and hit the issue align button and went looking for another star. When I slewed to deneb the mount decided to flip again and wouldn't you know it... the thing thought it was west when it was east and so wrecked the alignment and tested the belts again.(this is where I was supposed to stop around 1am)
    Now it's personal. I reset everything for a clean try. --hit cold start and init home..and it started slewing for home. That's wrong, It should sync to home and reset the program. I hit stop and only init home and it synced. A Problem may be in the cold start button routine. After this the mount claims deneb is below the angle limit in red and won't slew.. repowering. SAme result..

    2018-07-15T05:03:04: [ERROR] Object below the minimum elevation limit.
    2018-07-15T05:03:04: [ERROR] Error Slewing to JNow RA 20:42:04 - DEC 45:20:45

    I suspect something got stored weird somewhere.

    I eventually restarted Kstars and manually reset the mount to upright home and retried the new alignment tool after aiming at m39 initially to make solving easier. I got 3 good sync's and finished. The third put m31 onscreen. This did not solve my tracking speed( was hopeful it would tweak ratios and affect this) problem however and I had to tweak that again before I could get any photo longer than 10 seconds. I suspect this is due to the modeling not actually being on in onstep-mega config, but it works procedurally at least. (when you hold your head right <-- That's Virginian for do the right procedure)

    That's when I noticed the collimation screws are loose on the newt. hurray! ... (thud)
    **I also found a possible bug in the Ekos focus module that now does not return to the correct previous setpoint on auto focus failure. I am using moonlite focus rather than onstep. I'll try to remember to report it at master git.
    I installed new stepper drivers last week, changing from drv8825 to much nicer TMC2100 with good results. So smoooth now...
    The following user(s) said Thank You: Khalid
    Last edit: 5 years 8 months ago by Ray Wells. Reason: Try to clean up test intel and move ramblings to the bottom.
    5 years 8 months ago #27447

    Please Log in or Create an account to join the conversation.

    • Posts: 161
    • Thank you received: 39

    I probably can't test that for a while, but it should be good. I did test two nights ago, and it worked ok. Better than I've had before, though I noticed a bit of slack places, which has been corrected, so it's probably not as good as it could be.

    I did it fairly simply. Locate, Solve/Sync, move to next. It was off by a bit, then wrote it. Only had 6 targets, and the goto was off on the last one, but I think it was after the 4th one. (Should have started again.)

    Here's the results:
    Note this was on a Mega, I don't think that played with it. (Started with NCP in shot, not quite sure how good my polar align was (no polar scope.)) It was cloudy last night, and I'm going to be doing things next week and the week after that, so I likely won't be able to work much on it.

    kbahey's solution is a lot more elegant. I could see adding a sync command to enable that mode, because someone might want to not use that method, or as a define.
    (:AI# or something)


    Blueshawk: Note that the Align tab is intended for the setup added in the Alpha branch only, this month! So if you haven't updated OnStep since the new align code has been added, I'm not sure what to expect. If you do a goto, and that object isn't centered, then I think it would record the wrong target. (ie, whatever you hit goto on, rather than the sync. I'd have to look at the now-Beta code, to see.)
    The following user(s) said Thank You: Khalid
    5 years 8 months ago #27460
    Attachments:

    Please Log in or Create an account to join the conversation.

    • Posts: 257
    • Thank you received: 22
    Beta was synced with Alpha when I updated last week when I did the new driver install but i'm sure about the alignment. I feel like I missed something. Is there a thread I should be following at Onstep.io for indi/onstep interactions?

    I'll update to latest OnStep if needed. It was good to get back to good views at any rate. Planetary is for the birds.(falcon heavy :P)
    5 years 8 months ago #27463

    Please Log in or Create an account to join the conversation.

    • Posts: 322
    • Thank you received: 31
    Blueshawk and James, thanks for the comments.

    I think I should have been clear about how to test this, and from which repo.

    The changes are not in the official Alpha yet. They are in my own branch of OnStep:

    github.com/kbahey/OnStep/archive/plate-solve-align.zip

    Download this zip, extract it, rename the directory to "OnStep", then copy your Config.h file to that directory, and use the Arduino IDE compile/upload to your OnStep controller.

    For KStars and INDI, I am using the versions from Jasem's repositories on Launchpad. I use Ubuntu 16.04.

    indi-bin 1.7.3~201805251740~ubuntu16.04.1
    kstars-bleeding 6:2.9.6+201805251429~ubuntu16.04.1

    Nothing compiled locally is needed for the alignment code within KStars/Ekos/INDI.

    Connect KStars to INDI. Go to the INDI panel, then "LX200 OnStep" then "Main Control".
    Click on "3 Stars" (Howard says that more alignment may not work on Mega2560/RAMPS).

    Sidereal tracking will start.

    At this point, note the status in INDI, which will say: "613 Manual Align: Star 1/3", meaning it is ready for the 1st star to align to, out of 3 stars total.

    Then in Ekos, go to the Align tab, then click "Mount Model", select "3" for Alignment Points. Then select the stars you want, or let Ekos choose for you, using "Generate".

    Then click the triangle to start the alignment. It should be all automated from that point onwards.

    You will see 613 change to 623, then to 633. Finally, you should see "Manual Align Completed" when all is done.

    I tested it indoors and it seems to do what I intended it to do.

    And of course, I would have tested this under the stars if I had a working mount and controller. My project for converting a mount I have to OnStep is still ongoing.

    Please test under the stars to see if the Goto is more accurate after you do the above.
    Last edit: 5 years 8 months ago by Khalid.
    5 years 8 months ago #27466

    Please Log in or Create an account to join the conversation.

    Time to create page: 0.785 seconds