Adafruit DC and Stepper Motor HAT is not much good at steppers really

Well I have setup my Adafruit DC and Stepper Motor HAT, and it does drive the stepper motors, but has....   certain limitations!

This is all down to the HAT doing everything over I2C, and because the HAT requires a prod for each step (including each individual sub step in micro step mode), this limits the step rate to how fast the commands can be poked down the (not very fast) I2C bus.

The max rate is around 75 - 80 commands per second - so with 2 motors to move I can only do around 40 per second. Any attempt to go faster just blocks in the Adafruit library calls to prod the motor. The CPU utilisation though remains low, so that part at least is sensible.

However tracking stars and autoguiding should be fine with this rate (sidereal tracking needs just under 10 per second), so I shall carry on with some software and also prepare to go for Pololu A4988, set up to drive the stepping direct from GPIO pins.

In the meantime I intend to use lin_guider to track a star and report deviation over UDP, I shall write a program to pick up the deviation and directly drive the steppers through a full PID implementation. I have a PID controller I wrote earlier which I can use for this, the only hiccup at the moment is that the Adafruit software only appears to be available or Python 2 *sigh*.

Telescope with Raspberry Pi - stepper motoring

On the few occasions that the weather has co-operated I have been testing tracking with the setup described earlier. It has not worked well. Tracking was very occasionally good, mostly mediocre and sometimes dire.

I have though much improved the wifi access by setting up an external access point. The signal is now excellent and remote desktop from inside to the pi on the 'scope works well. I used an outdoor ap with cheapo power over ethernet all stuck onto the house with a cheap aerial mounting kit from B&Q.

1. 7dBi GSM 4G Penta-Band Panel Antenna N-Type
2. ALFA TUBE2H 150Mbp/s 2.4Ghz Long Range Outdoor Ethernet WiFi AP/CPE with N-Type Connector

I wrote a trivial python script to pulse the ST4 interface to see what was happening at the coal face and it was not pretty.

At the 1.5x speed setting on the DD-1 controller pulses long enough to cause 3 steps were actually doing from 0 to 3 steps, very few were 3, and quite a lot were 0, this was with the mount indoors and no load. A bit of back pressure against the direction of movement made the situation significantly worse.

Increasing the speed setting to 2x helped quite a bit, but any significant load still saw the difference between intended steps and actual steps increase dramatically. I could hear the pulses on the motor, but they were not causing the motor to actually step.

I saw 2 ways forward:

1. buy an EQ5 goto upgrade kit - these fit the old Vixen mounts with very little adaptation, but they cost around £300.
2. go diy with a raspberry pi stepper motor HAT using the existing motors, cost circa £20.

And being keen to get to grips with stepper  motor magic for other reasons as well, I went with option 2.

Order has just arrived so I will be busy for a few days.........

Well some success, but not quite what I expected!

Telescope with Raspberry Pi

Notes and Info on using a Raspberry Pi with my telescope

Not going to say much about my scope other than it is using a Vixen GP mount which had an ra drive fitted when I bought it, and I am fitting a dec motor to it. Both motors are vixen MT1 and I have a hand controller DD-1.

I'm first of all planning to add an ST4 interface to the controller, which looks pretty simple, and then use a PiFace to drive the interface. I'll then use Linguider to give me an autoguide capability. I'll look at adding goto later.

(Well, adding an ST4 interface to the DD1 didn't go too well.... )

I'm using Raspberry Pi, 'cos I have a couple already doing other things and I like them, plus it's nice low power so I can run on batteries, and lots of people are using them as telescope controllers. The GPIO on the pi means I can drive various things direct, rather than through various adapters, although I will use a PiFace to protect the pi and give me a bit more drive (the built in output pins are only 3.3v and very limited current).

I'm using linguider 'cos I've read in many places that it works far better on pi than the other obvious alternative - openphd, plus I relatively easily added support for driving piface outputs to it.

This setup all works, although I need to tweak the settings of lin_guider and / or the scope alignment to get a nice tight tracking. lin_guider reports a swing on tracking of around 6 - 8 arc seconds on 1 axis (the other axis is < 1 arc second). This is a 2 minute exposure with a 560mm lens on a crop frame camera. If you open up this piccy (which is a big crop from the original) you will see all the smaller stars are slight stripes.

This setup looks like it will work well for tracking, but as I can't change the speed of the motors except by moving the switch on the DD-1, goto is not going to be seamless.

Lego Mindstorm EV3 motors - some performance info under EV3DEV

I'm getting ready to write some nice control software for my Lego motors and have done some initial tests to see how they perform.

This graph shows how rpm varies with duty cycle, no load and powered by a rechargeable battery at 7.4v (the battery was under charge as well)

For real use normally one would use rpm regulated mode of course.

Unless you need the ultimate rpm, the large motor is a more consistent performer.

Mindstorming with Python

The motors that come with the Lego Mindstorms EV3 comes with motors with positional feedback and reasonably sophisticated controls. The 'brick' that interfaces with all the widgets can also easily be hacked to enable use of sensible programming languages rather than the visual language (which has some significant limitations) that Lego have developed.

The ev3dev update is especially good as it can easily be removed to revert back to the original state (it is installed on an SD card and no changes are made to the controller).

So here is a quick blog of what I have done to get up and riunning with python on the EV3. I did fall down a couple of bear pits along the way, so this describes how to get to a working solution.

Running with multiple graphics cards for compute and gaming

I have a small but ostensibly conflicting set of requirements for my desktop computer:

1. General use - keep the power low
2. 3D modelling /  graphics - exploit GPU as much as practical for rendering in particular
3. Video / gaming / live grahics - use my best GPU

The CPU is an i7 with intel 4000 series GPU, so more than adequate for general messing about. I have a GeForce 660-Ti and recently was donated a GeForce 670 as well. Happily my PSU can support both cards in use.

I also know from previous messing about with Blender that using the GPU for compute (rendering) that is also driving the screen is not a good plan, so the quest was on to find a way of using the Intel graphics to mostly drive the screen, while having the option of using the GeForce 670 for modest gaming, and with the ability to use Intel graphics to run Blender using both graphics cards for compete while rendering.

The current working method to achieve this is not perfect, but from my perspective quite usable.

Motherboard / bios settings

Motherboard set to allow both integrated and discrete graphics to be active. Without this setting either the Intel GPU or the GeForce GPUs will not be available to the OS. Also integrated (Intel) graphics is set the the default graphics option. This means that the bios and grub bootloader (I run dual boot linux / windows) run through the Motherboard graphics port.

PC / Monitor connections

My monitor (Dell U2713H) has multiple digital inputs - in particular 2 DisplayPort inputs and an HDMI input.

I use DisplayPort to connect the Motherboard to the monitor (I cannot run my monitor at native resolution from the integrated graphics over HDMI, it's fine over DisplayPort)

I connect the GeForce 670 to the monitor using HDMI.

Windows Settings

I have windows set to extend the desktop with the DisplayPort (HD4000) connection as the primary display, and HDMI (GeForce 670) as the second display positioned on the right.

Working method

Monitor set be default to use DisplayPort input. This setup is also set to use wide gamut colour and is colour calibrated.

To run games or other software that meeds to use the GeForce to drive the display, I set the game to run on the second screen (this only needs to be done once typically), and then immediately after launching the game, I switch the monitor input to the HDMI input.

Disadvantages

Windoze thinks that the second display (in normal mode) or the first display (in gaming mode) are really there and allows the mouse to roam onto that screen, which means it completely disappears. Really just a minor irritation once you are aware of what is happening.

Also the monitor has to be manually switched between the two modes, not really a problem, just a mild inconvenience.

Power

Adding the second GPU increases the idle load very slightly - around 10 watts or slightly less. Windows idling now runs at around 85 watts mains input.

Gaming (which uses the 670) increases this to around 180 watts (although a heavy game would probably use more).

Full on compute - such as ray trace rendering in blender takes power to around 320 to 330 watts.

Timelapse from a Raspberry Pi webcam

Just a few notes on taking very large numbers of photos with a view to making timelapse videos.

I've done a few timelapse videos using my DSLR, then processing them through Lightroom and LRTimeLapse. This work well, but is quite hard work, ties up my dslr and of course uses up a lot of shutter time (since I can't do electronic shutter with the dslr).

So I thought I'd have a go at making it happen with a webcam and a raspberry pi (I already had the webcam from other PC things I'd been doing, or else I might have used a picam).

I'm using a Logitech C920 webcam and planning to take full HD sized photos.

1. Kit in use & setup
2. Taking the photos - fswebcam
3. And the answer is python and v4l2?
4. First tests to check performance.