×

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

Bi-monthly release with minor bug fixes and improvements

Capture & Solve -> Slew to Target...

  • Posts: 333
  • Thank you received: 24
Ah, Thank you for confirming. I had actually start using parts of the AuxCommand class in the celestron_gps driver. It was working well but resulted in the same symptom. So I simplified things down, resulting in the same symptom. So I will stop working on the move commands in this way.

I have looked as using the nester-evo driver to add in serial instead of IP. I was stuck at the connection point in the design to say.... do not use IP, use serial connection.

If you can point me to the correct place to make the decision point, I can try to work the serial part in, to test and see if I get it. If I do then I will gladly work it a bit more to see if I can help.

I am assuming sending the AuxCommands through the HC is still valid to add in serial to the nester-evo driver.
Last edit: 6 years 4 months ago by Stephen.
6 years 4 months ago #21309

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

  • Posts: 333
  • Thank you received: 24

I have looked at your code to to learn and it helped a lot. I was trying to see I could find a driver for the RPI3 that would move the CGEM for better entering before investing too much time. It was not clear to me how I could test it with Ekos and INDI on the RPI3. Do you have any suggestions?

My Java skills are many years old, yet, if there is a starting point for a HellowWorld like point... I can run from there.
6 years 4 months ago #21310

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

  • Posts: 200
  • Thank you received: 57
The problem is I have written the driver without planning to factor out the communication part. It was written explicitly as network based. Fortunately Jasem has implemented communication classes which will help refactoring. I have started the process. Right now only connection and handshake is partially done but I think it should be doable without major pains. Essentially we need to move all communication to INDI infrastructure and the work will be mostly done. As far as I understand the INDI is now capable to fully encapsulate the communication layer ( @knro Is that true?) so we only need to decide if we need to prepend HC-pass-through code to the message or not. Any help with this will be appreciated. We can work in the separate branch - PR against my repo (github.com/jochym/indi/tree/drv_nexstarevo) are welcomed ;)
6 years 4 months ago #21317

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

  • Posts: 333
  • Thank you received: 24
Ok, I will start reviewing your branch, compare the differences in the conversion to Jasem's classes, and then I will come back with questions :)
6 years 4 months ago #21326

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

  • Posts: 200
  • Thank you received: 57
I intend to work on this next weekend, maybe a bit earlier but that depends on the workload. If you have any questions regarding the code do not hesitate. We can use github collaboration mechanisms as well.
6 years 4 months ago #21331

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

  • Posts: 14
  • Thank you received: 0
Hi guys,

Any update on the Nudging precise slewing project? I use a celestron AVX and I have the same problem. So, I'd be extremely interested in the solution being developed here.
I do have some experience in writing code, although not for this kind of stuff (but I'm not too bad at C/C++ in general). So, if you think I can help, I'd be happy to contribute. I'm also happy to test the code to see if it works on the AVX.

Thanks,

jf
6 years 3 months ago #21746

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

  • Posts: 333
  • Thank you received: 24
Hi,

No sorry. I got hit with two snags:

1. The approach I started with actually created a competing for state in the state model. I have some direction but...
2. My mount is in for warranty work, so I cannot test changing this anymore.

Hopefully, I will have a mount again in a month or so. For now, my hands are tied unfortunately.
6 years 3 months ago #21751

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

  • Posts: 14
  • Thank you received: 0
Sorry to hear about your mount. I hope it gets fixed quickly.

I must say that I'm a bit surprised to see all the problems you seem to have encountered on this project. When I do it by hand (using the "motion" tab in the "mount" tab on the INDI control panel) it works fine. So, all I would need is the same function than the one which is called when I click the Nord/South/East/West buttons on the INDI control panel. From there, it should be quite straightforward.
Of course, I say that and I'll probably realized that it is more complicated than what I think...

I guess I need to start getting into the INDI/Ekos source code one of these days. Maybe that's going to be my fun project for Christmas break...

jf
6 years 3 months ago #21776

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

  • Posts: 333
  • Thank you received: 24
Actually the code is quite nice. My stupidity was to attempt to use AUXCommands within the current celestron_gps driver. This driver's a state model will not work with the monitoring of the AuxCommands for the Alt/Az movement.

The nudging attempted was to determine the RA/DEC deltas and if under 2' to use the AuxCommands to inheritently nudge the mount in the right direction using the alt/az deltas.

The good news is that it seems quite possible to use the Aux commands to nudge the needed Alt/Az deltas, just do not do so in an in appropriate state model.
6 years 3 months ago #21795

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

  • Posts: 200
  • Thank you received: 57
I am afraid that this is not going to work. Since HC is not monitoring AUX commands send by your code it will gradually lose the calibration as time progresses (with each nudge). You can probably mitigate it somewhat by syncing the mount after each nudge - but I am skeptical of the effectiveness of this approach.
6 years 3 months ago #21806

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

  • Posts: 333
  • Thank you received: 24
Hi, agreed. I stopped the approach and I intended to do it out side of the slew. Something you mentioned initially I think as a new client. Work is in the way and I have no mount so I am stuck to continue for a month or so unfortunately.

Cheers!
6 years 3 months ago #21812

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

  • Posts: 14
  • Thank you received: 0

Yes, I would re-sync after each nudge. I know it works not too bad because that's how I do it now, except that it is done by hand. Here is a detailed description of my operating scheme:

1. Do a regular GoTo for the target (or a precise GoTo, doesn't change the rest of the operations)
2. Capture and solve.
3. Sync on the RA/DEC values given by the plate solving (I do this in the INDI control panel)
4. Move the mount (with the North/South/East/West buttons in the INDI control panel) until the coordinates given by Ekos are that of my target.
5. Capture and solve.
6 If coordinates of the new images are close enough to the target, done. Else, repeat from step 3.

I have quite a lot of backlash on my mount, so usually I have to do 2 or 3 iterations of this. But it works great. In just 2 or 3 minutes I can get the target to within 1' of the center, which is plenty good for me.
Now, all I need is a way to do the same with some code, rather than by hand. Should be straightforward for someone familiar with INDI/Ekos. I should have a bit of time over Christmas, so I'll start looking into that.
The only problem I could see is if the multiple sync somehow screw up the alignment model.

Thanks,

jf
6 years 3 months ago #21816

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

Time to create page: 1.074 seconds