Plan of a new DIY mount software (Raspberry Pi controlling TMC stepper drivers)

[Andy_ZH]

Hello all,

 

this is my first post at SGL, and it will be quite long. I am not native a English speaker, so please excuse any mistake.

 

I have quite some plan with my telescope mount and its goto control, and I am looking for some feedback and comments. If somebody else did a similar project, please let me know. And please feel free and encouraged to make suggestions, ideas, critics, etc.

The story in a few buzzwords: Raspberry Pi Zero → direct control of TMC2209 stepper drivers via the Pi's Uart serial interface to drive my telescope mount. I am writing a software (optionally: open source?) to control the mount. The language will NOT be C, as typically used for Microcontrollers (I know for instance OneStep)

I am using Kotlin, which is a more advanced JVM language.

 

I think this should be enough information to filter the readers who are interested in reading the rest of my post.

 

Now the long and detailed story:

My professional background: I am a physicist, and did a PhD in EE (Power Electronics). Later, I became software engineer. Besides being fascinated by Astronomy, I am a tinkerer (Reprap 3D printer, electronics, …). I did grind my first mirror (a 6'' Schiefspiegler) when I was 15 years old, and I built the cookbook CCD cameras in the 90's.

After many years without a telescope (study time, relationship, ... ), I settled down with my family, and I started to get back to Astronomy.

Recently, I did by a quite a massive second hand mount: the “Vixen New Atlux” from another other stargazer in Switzerland. My opinion is that the New Atlux' mechanical design is superb. It has (had...) internal wiring, the counterweight bar can be hidden in the mount for transport, good polar alignment screws, it has an excellent polar finder with a dimmable LED.

But on the other hand the electronics: two weak servo motors in combination with the incredible Starbook 5.... Seigh... the starbook...(!) it is, well... the mount is just superb, and no more comments about the starbook game boy, which shall rest in peace at the garbage dump.

I removed the servos and all electronics, and I put 2 stepper motors into the mount, which are coupled to the gear with a timed belt. My original plan was to put an Arduino into the mount in order to control the steppers. I have an old goto Celestron cg-5 with Starsense, and it would have been quite easy to mimic - with the Arduino as interface – the servos of the old cg-5 and translate the Starsense control signals to my New Atlux. I can write C, and there is even an open source project called OneStep, which uses a Microcontroller in a similar way as I do.

But I don't like to write C code anymore. In the 3D printer community, people need to use real time electronics to control the printer steppers. Due to the real time requirement, C with a real time microcontroler (Arduino & similar) are the only option for 3D printers.

Do we need real time for our telescope? No. We don't need to control a lot of Motor accelerations and high speed control. For the telescope, we need to set the Motors speed precisely, and we need to drive to any position in an accurate and controllable and slow way.

Then, there are new stepper motor drivers available with as much as 256 microsteps. The TMC2209 stepper driver , which is very well know in the 3D printer community, is not vibrating at all. It runs just smoothly, also at very low speeds. I do drive my motor with 0.25 rpm (sideral speed). In case of a slew, I can accelerate to 1500x sideral speed, which also would allow me easily to track the ISS. Wonderful.

 

The current status of my project is:

• The mount is equipped with the two new motors
• The TMC2209 drivers are connected to the Raspberry pi GPIO Interface, and I can control them via Software. Theoretically, I could attach up to 4 motors with a single Uart interface (1 wire protocol). For instance, a focuser or a filter wheel could be attached.
• I selected Kotlin as language. Java also would have been possible, but I think for a new project, Kotlin will lead to a much more readable code.
• The TMC drivers can be driven via a chip-internal clock signal. Different to what the 3D printer community is doing (they use the step / dir pins, and create every single microstep with the microcontoller), I can send a “speed” signal from the Raspi via UART to the 2209 chip, and it will execute this speed for me without any further action.
• The only time critical issue was that I need to precisely count the steps that the 2209 stepper drivers executed. This is done via a GPIO pin, receiving its index signal (a pulse for every 2209 fullstep). Here comes the pain with Linux (non real-time) and the Pi: For user programs, it is impossible to guarantee that every pulse from the stepper drivers will be registered. But I cannot afford to have a step count drift over time. The solution was that I wrote a Linux kernel module in C. I wrote that I don't want to write any C code. Well, a few lines for the kernel module were indeed necessary. I can live with that, having in mind that the rest will be written in Kotlin. The only task of the Kernel module is to count every registered step at the Pi's GPIO input pins. This kernel module output is then mapped to a character device file in /dev/ for every stepper. In Kernel space, it is possible to register and count interrupts without missing even any one of them. From a hardware point of view, this is indeed everything we I need.

The project cost so far: 2x10€ for the stepper drivers, 2x10€ for the motors, 2x20€ for the tooth belts and pulley, 10€ Pi Zero plus some peripheral expenses: Micro SD card, USB charger, and 1200 € for the used Vixen new Atlux mount. And a lot of time.

I have so many ideas on how to extend the ecosystem of my software, but these ideas are for the longer term (maybe years from now on):

• Multi-star alignment. The alignment should be able to be updated continuously during an observation night. With a set of stars, it should be possible to calculate the quality of the aligment points, and e.g. drop them if they are errorneous.
• PEC correction (should be easy on the Pi)
• End-Stop support
• The polar alignment routines of today's goto scopes are quite good. But what I would like to have is some audio-feedback when I move the alignment screws into the right direction.
• Possibility to pre-plan an observation night (e.g. the mount could tell you that the Jupiter moon shadow will be on Jupiter in a few minutes).
• Record the telescope movements during the night in order to be able to tag any picture.
• The TMC drivers have much more capability than what I am using currently. For instance, they could be current controlled for slews in order to set the stepper current exactly to the value that it needs without stalling. This saves a lot of energy. The TMC drivers have a feature called “Stall Guard”. This could be used instead of endstop switches (for 3D-printers, this is done frequently).
• Advanced options for tracking: siderial, solar, moon speed, ISS speed. Tracking in both axis (e.g. to compensate polar misalignments of atmospheric refraction) or just in right ascension. Commercial mounts do not allow much customization here.
• With slow slew speeds, 5V input via a USB-C cable is sufficient for the Pi + Motors. Usb-C and newer usb battery packs allow to output a higher voltage via USB. With an “USB-trigger”, the input voltage can be selected to my needs. Higher voltage allows higher slew speeds, but consumes more power.
• Autoguider support, or even better: simply connect a webcam via the Pi's USB connector and do the guiding on the Pi
• The Raspberry Pi touch screen could be used for telescope controlls
• Advanced German mount limits and meridian flip control (e.g. a warning about a necessary flip when driving to a specific goto target).
• An Android App, connected via WiFi to the Pi could be used as display alternative
• Language control (have a look at Mycroft, an open-source artificial intelligence). "Hey mount, please slew to the whirlpool galaxy!"
• Control the mount via SkySafari and Stellarium
• The Pi has a built in camera interface. How about an open source auto align? The Pi could look at the stars to align itself, which makes a lot of sense. I did already order a long focal length lens and monochrome camera from Arducam in order to do some experiments (the standard Pi camera has 3.5 mm focal length and is not really usable, although star imagining is possible).
• My first observation site is my balcony. And there, the real Starsense does not work at all. It always spin-loops on 2 alignment positions where the sky is covered by the roof – how silly is that?. This can be done better. Further, Starsense is doing only a initial alignment. It should update its position and accuracy over the time! I think I could do this better.

 

Besides all my ideas, the first and most important focus of the software will be:

Readability (therefore my choice of Kotlin), extensibility and open source. I like to have the Maths of the internal mount model clearly visible and understandable in the software. The calculations that are done within all our goto mounts are no rocket science. I admit, I am the nerd guy who wants to go the hard way and implement this from scratch.

I am looking for a good project name, do you have any suggestions? How about QuickStep? this is possibly too close to OneStep and would offend the creators of OneStep?

Does anyone of you have interest in joining my plan? Doing such a project in a small group would be more encouraging then just doing it for myself. And of course later on, I would appreciate if other stargazers would update their old mounts with my software.

 

Any comments on my project plan are welcome!

 

Clear Skies!

Andy

 

Edited January 7, 2020 by Andy_ZH
added picture of my second hand new atlux

[Andy_ZH]

I added a picture of my mount. The raspberry pi zero is in the red plastic box, with some GPIO wires going into one TMC2209 stepper driver. The Pi zero is small enough to be placed inside the mount. I will replace the original metal mount cover with plastic. Otherwise, the Pi's Wifi signal will probably be screened too much. A mobile phone external battery pack is sufficient as power source. This could be integrated into the mount, too, or it can be attached with a USB-C.

[tonyowens_uk]

Hi Andy and thanks for your most interesting post. Your Astro-related activity level over your life as you describe it is actually very typical for a professional person!

The overall impression I got from your post was: ‘here is a chap who wants to “boil the ocean”, but do I really believe that is necessary? Ummm - no!’ 
ASCOM modularity allows even simple amateur telescope and instrument control to be simplified and maintained more easily. As TCS’s have bloated in the last two decades this modularity and ability to keep the bits that work and in which people have invested learning time is important.

My suggestion would be to first look hard at what is wrong with other more developed telescope mount controller products and open source projects before doing anything more. I’d be particularly critical about conflating cost-driven Reprap technology from 3D printing with performance driven tech as needed in credible imaging mounts to be used in cold damp environments by elderly people of widely varying abilities! Cast a cold, critical eye on what you see.

Some practical points:

1. You would be very brave to take this on, alone. But some of the finest engineers on this planet are involved with Open source astro engineering projects and getting their assistance would be wise

2. Be careful about stepper motor technology in telescope tracking applications where both position and rate control are critical. In the real world, microstepping a common bipolar step motor does not increase the positioning resolution of a motion system by anything like x256 times, due to low rotor stiffness, constructional and phase current tolerances, resonant effects and load torque variations. Trinamics impressive driver technology is great but won’t change the laws of physics. I recommend looking hard at low cost closed loop stepper-based motor/driver units from Chinese firms like Leadshine. They blur the distinctions between brushless servo and stepper technology very nicely, offering ‘real’ x64 microstepping capability out of 100 pole motor construction and smooth loop closure with step/dir interface.

On the motion controller side, dont neglect the most recent Duet 3D print boards being introduced. These are provoking interest in the professional CNC world due to the safety engineering, embedded RTOS, and open source code base, and work well with a RPi front end.

Another consideration is the emulation of common mounts. There is a huge installed base of Skywatcher/Orion amateur mounts globally, for example, but only one TCS project  (EQDrive out of Ukraine) I’ve seen that exploits that ecosystem by adopting the SW mount controller command set (perhaps with extensions). By adopting a de facto standard like this, your users benefit from existing investments they’ve made in Skywatcher mounts and accessories. I’ve also found Skywatchrt Engineering to be professional and accommodating of people who can customise or extend their platforms.

I hope my remarks don’t discourage you Andy. My experience over two decades has been that Astro engineering helped transform my professional engineering career from a stepping stone to boring old programme management and power politics to a far more satisfying one in technology consulting. I hope you are seeing that too!

Tony Owens

Edited January 8, 2020 by tonyowens_uk
Corrected name of Ukrainian GOTO mount controller

[pete_l]

Hi Andy.

When I started to read your plan my immediate thought was that Linux was not a real-time O/S. However your kernel module addresses that limitation. I use Pi's for lots of applications, but I would never use one for real-time work. An Arduino is much better in that respect ;). The other drawback with a Pi is that it depends on an SD card. These have quite limited lifetimes. I used to burn through them regularly until I moved all the temporary data I was storing onto RAMDISK partitions. SD cards simply don't have enough write cycles to be used in a permanent device. Does a Pi zero have enough free memory to do this? I also dislike SD cards as their connectors are cheap, mechanical and not very robust. They also get corrupted very easily if power is removed unexpectedly (and sometimes even when they are powered down properly, if the applications don't lock them up while doing so.

There is an implementation of a mount driver using an STM32. It is called On Step and looks quite interesting. You can even purchase kits of all the parts!

Edited January 8, 2020 by pete_l

[Andy_ZH]

On 08/01/2020 at 03:46, tonyowens_uk said:

 

I’d be particularly critical about conflating cost-driven Reprap technology from 3D printing with performance driven tech as needed in credible imaging mounts to be used in cold damp environments by elderly people of widely varying abilities! Cast a cold, critical eye on what you see.

Some practical points:

1. You would be very brave to take this on, alone. But some of the finest engineers on this planet are involved with Open source astro engineering projects and getting their assistance would be wise

2. Be careful about stepper motor technology in telescope tracking applications where both position and rate control are critical. In the real world, microstepping a common bipolar step motor does not increase the positioning resolution of a motion system by anything like x256 times, due to low rotor stiffness, constructional and phase current tolerances, resonant effects and load torque variations. Trinamics impressive driver technology is great but won’t change the laws of physics. I recommend looking hard at low cost closed loop stepper-based motor/driver units from Chinese firms like Leadshine. They blur the distinctions between brushless servo and stepper technology very nicely, offering ‘real’ x64 microstepping capability out of 100 pole motor construction and smooth loop closure with step/dir interface.

On the motion controller side, dont neglect the most recent Duet 3D print boards being introduced. These are provoking interest in the professional CNC world due to the safety engineering, embedded RTOS, and open source code base, and work well with a RPi front end.

Another consideration is the emulation of common mounts. There is a huge installed base of Skywatcher/Orion amateur mounts globally, for example, but only one TCS project  (EQDrive out of Ukraine) I’ve seen that exploits that ecosystem by adopting the SW mount controller command set (perhaps with extensions). By adopting a de facto standard like this, your users benefit from existing investments they’ve made in Skywatcher mounts and accessories. I’ve also found Skywatchrt Engineering to be professional and accommodating of people who can customise or extend their platforms.

Tony Owens

Hi Tony,

thanks for your in detail reply and your advice, i will for shure consider some of your points. I have to admit: My efforts looking at Reprap equipment is not really low cost driven, it is fun driven. I know about the microstepping / accuracy issue. Actually, I can see this  discontinuous motion just by looking at the motor shaft operating at very low speed.  However, with 0.25 rpm, 200 steps per revolution and microstepping, I don't think this will be an issue. Currently, I will not do any further action until I have my scope with the new setup outside. Even though the microsteps are not 100% accurate, they provide some kind of smooth motion which will (as a first guess) lead to an tracking error of some arc seconds.

Later on, when this seems to manifest as a real issue, i can a) go for a 0.8 degree / step motor or b) fine-tune the stepper driver microstep table. This driver is able to store a specific current in a chip-intern table for every microstep. I guess that the biggest influence for the observed discontinuous motion is the motor design itself, which is not behaving as an ideal (n-pole) permanent magnet synchronous machine, but the sinusoidal current rotation is leading to a non-sinusoidal field rotation within the motor.

I know a short article where someone measures the stepper (and driver) microstepping accuracy:  https://hackaday.com/2016/08/29/how-accurate-is-microstepping-really/ and I could do a similar measurement, but being pragmatic and use the setup under the sky will be more efficient.

> Open source astro engineering projects and getting their assistance would be wise

I did find a Pi image called "Astroberry", this looks quite promising. My option is: I will continue with my project (and I have fun with it), and later on it could be a nice extension which could be included in Astroberry, for instance.

> Another consideration is the emulation of common mounts. There is a huge installed base of Skywatcher/Orion amateur mounts globally, for example, but only one TCS project  (EQDrive out of Ukraine) I’ve seen that exploits that ecosystem by adopting the SW mount controller command set (perhaps

 

Yes, this is indeed true, I will keep this in mind.

 

Also thanks to Brown Dwarf for your reply. I know that SD cards could make problems. I just got a bunch of them for 10€ each. At the moment, I am just doing a backup image of the card, with the expectation that it could die anytime. On the other hand: How many hours per Year do I use my mount / scope? I know some people who are outside under the sky at every opportunity, but even wenn the card will be used 10-20 nights per year, I expect them to live for some years.

So, thanks again for your opinion. I will try to use this thread as an update history for my project.

Andy.

 

[JamesF]

INDI may well also be worth a look if you're unfamiliar with it, as might Thomas Carpenter's AstroEQ project.

James

[JamesF]

Don't really know anything about it, but the TeenAstro project looks like it could be worth a browse, too.

https://github.com/charleslemaire0/TeenAstro

James