ValueError: Stage response to 'p?'


Instead of printing an entire Openflexure Microscope I printed gears to motorise an old Olympus EC. It works!
At first, I struggled with the stage mapping, as the x- and y-axis have different gear transmission ratios and backlash (x: 224 backlash and 0.27 px/step, y:53 backlash and 1.769 px/step). I lowered the “example values” in the file and rearranged it so that it starts with calibrating the y axis. Somehow that helped and it now works.
Now I’m trying to set it up so that it can scan the entire stage area (~6 x 5 cm) with probably thousands of pictures each 2500 steps in the x direction and 250 steps in the y direction. So far I managed to capture and stitch 22x15 images (15319 x 6904 pixels).
However, often it stops and I get the following error: ValueError: Stage response to 'p?' ('12500 250-782') wasn't matched by /%d %d %d/ (generated regex /([-+]?\d+) ([-+]?\d+) ([-+]?\d+)/)
I guess this error is caused by to many commands for the motors. I also get it when navigating and keeping the arrow keys pressed down. Or are the motors not strong enough?
I changed the settle time to 2.5 and disabled the gallery, that helped a bit. I use a Raspberry 3B, PiCam v2 and a Arduino nano clone. Would the increased power of a Raspberry 4 work better?

Thank you for you work and any help.

1 Like

That project sounds like a lot of fun.

I don’t have an answer to the direct question, but it is not clear what your power system currently is. The Pi is able to give a warning if it has a power issue - if you are using the Pi desktop then a power indicator appears on the desktop, otherwise you can query it I believe. The Pi 3B has a micro-USB connector which is not very good at delivering the power even with a good power supply. It does not really sound as though that is the issue.

The motors should always have a separate power supply, not powered through the Pi or the pi-Arduino USB. The quality control on the little stepper motors is not good and the current draw can vary over a wide range. Are they hot?

Even if there is a problem with power I can’t see it failing after a while rather than soon. the thing that does change with a longer scan is the number of files and the filesystem getting full. SD cards do fail remarkably frequently, and also the SD implementation on the Pi seems to be quite slow. Either of those factors could be an issue once a scan gets big, together with overfilling the SD that has the operating system on it. I would suggest trying an external hard drive for the size of scan that you are attempting to do. You will need to change the photo directory in the Openflexure software. I think that is in settings in the web app.

Thank you very much for the quick reply. Yes building it was surprisingly easy and lots of fun. If anyone has a 1965 Olympus EC, I’m happy to share the scad files. I plan to scan entire slides of plant roots to measure mycorrhizal fungi.

I was less concerned with the current the Raspberry and the motors draw, although there might be an issue as I was running them on the same power supply. The motors get warm, not hot.
I was wondering if the computing power of the newer Raspberry would solve the problem. Increasing the settle time seemed to help so I suspected that a faster computer might also help. But I don’t understand the Error message…

I will also check if the problem occurs more frequent on the y axis, which requires the motor to work much harder. I didn’t bother with the focus to much yet (although it works).

So far the largest scan was 330 images and ~85mb, good idea to get an additional drive as these numbers will grow exponentially.

1 Like

The motors don’t really do much more work when moving than when stationary. The coils are kept energised to hold the position. If you are powering from one power supply, it is best to split before before the power goes to the Pi.

A Pi 4 might help, I don’t know. The new Pi 5 will not run the current version of the microscope server.

I borrowed a Raspi 4B and now everything works. I can take scans with more than 1000 images. Now I need a better computer for stitching. The stage works quite precisely, maybe it will work with little overlap.

This is a sample of my Test slide: 50x20 images, 32000X10000 px, no autofocus ~15min :

I probably have to change y-backlash, but else I’m happy.


That is good news.
For scanning and stitching, @JohemianKnapsody has made progress in an algorithm that will stitch large image sets using the resources available on the Pi. It is not released yet, but I think there is a version that you might be able to try on your acquired images.
As the images are from a well-controlled stage and the subject is flat, there is a lot of information that can be used to start the positioning and check that there are not large errors in stitching.

This is such a cool project @bazzo, glad it seems to be working so well!

As William says, I’ve been working on a stitching program for OpenFlexure images that can run on the Pi, instead of requiring the immense power demanded by something like Fiji. I have to admit that 1000 images is larger than I’ve ever dealt with, but 530 images worked fine Pap smear | OpenFlexure

William’s also right that it’s not released yet, but I’m happy to either share a link or attempt to run it on your dataset if there’s somewhere you can share it?

Maybe the Raspy 4 wasn’t the solution after all. The error keeps popping up. It started when using the z-axis for image stacking. Does the Sangastage move the z-axis to compensate when moving in x- and y-direction? Is there a way to turn this off?

Here is a stitched image of a root sample 30x20 images, with little overlap. I used Fiji without any calculation.

@JohemianKnapsody: I would be very interested in using your code. I can also share the images I gathered so far. Is your email-address in Glasgow still correct?

If you’re doing a z-stack of images, the z position will also change during an x-y move. If you’re not stacking, I don’t think this should happen. @r.w.bowman is the best person to ask about your error, but he’s taking some well earned time off over Christmas

Yes, my Glasgow email would be best, cheers

Happy new year!

I’ve been thinking about my error message ValueError: Stage response to 'p?' ('12500 250-782') wasn't matched by /%d %d %d/ (generated regex /([-+]?\d+) ([-+]?\d+) ([-+]?\d+)/).
Could it be caused by the Arduino clone I use? The only mention of a similar error on this forum was caused by somebody editing the Arduino sketch.
Might the newer and more powerful Arduino Nano Every be the solution? Or will the official Sangaboard get rid of the error?

@bazzo it is a shame that you are still getting the error. It is an intermittent fault and not a very informative ValueError, which is always hard to diagnose. However I doubt that a NanoEvery would be necessary, the Nano has quite sufficient capability, it is only controlling three motors at 1000 steps per second.

I have not tested my version of the Nano motor controller with such large scans, but I have been using it intermittently for a long time. As a scan is just repeating the same move-focus-capture over and over again, then if it can do a few it should be able to do many.

In experience from other software issues from members on the Forum, it is often some kind of software installation problem, and occasionally hardware. If you have not tried this already then I would suggest re-installing the Openflexure operating system on the SD card for the Pi (this will delete any images that you have already taken, so be sure to save those first) . Also re-install the Sangaboard firmware on the Nano. If you have a second SD card and/or a second Nano then I would also use those. SD cards are not particularly robust and this can cause all sorts of errors in Raspberry Pis.

I have seen corrupted serial data in this way (missing characters, in this case a space) multiple times before with arduino clones (not OFM related). Sometimes using a different cable fixed it, but I suspect it could be related to fake USB serial converter chips used in the clones, in some cases I had to switch the arduino completely. As William suggested, if you have an extra nano, it’s worth trying that.

1 Like

I went out and bought a genuine Arduino Nano and installed it. No error message so far. Tested it over an hour with more than 3000 pictures and movement in all 3 axes. hurray.

The Nano clone seems like false economy, or maybe I was just unlucky.

Thank you for all your help.

I already got a second Olympus EC (even with phase contrast) that I will now motorize…

1 Like

@JohemianKnapsody: Also the openflexure-stich script seems to work :grinning::

However I’m not sure about the focus stacking capabilities :thinking:

1 Like

Hi bazzo, sorry to keep you waiting, I’ve been out doing fieldwork but back in the lab now

Glad your issue seems to resolved and thrilled that you got OpenFlexure stitching to work! Focus stacking might be on the long term road map, but for now we should probably add something to warn against loading scans with multiple images at the same position (although it does lead to some spectacular pictures!)

Welcome back @JohemianKnapsody

The stitching is really fast and quite accurate. Not everything is hunky-dory though. I only later noticed that the composite image stitched_from_stage.jpg doesn’t use the full resolution. There is also an error message: IndexError: too many indices for array: array is 1-dimensional, but 2 were indexed.

What am I doing wrong?

I also saw on your post from Rwanda that you have a live preview of the stitching in the connect app. Is there a way to get this feature?


1 Like

Making the stage preview use full resolution should be fairly simple - for now, you can edit line 42 of src\openflexure_stitching\

stitch_and_save("stitched_from_stage.jpg", tiling_inputs, None)
stitch_and_save("stitched_from_stage.jpg", tiling_inputs, None, downsample = 1)

This is definitely something that we’ll be looking at making an option from the command line in the near future.

There is also an error message: IndexError: too many indices for array: array is 1-dimensional, but 2 were indexed .

That error occurs when there are no overlapping images to correlate - please can you try decreasing --minimum_overlap to see if that fixes it?

And regarding a live stitch preview, this is very much still in pre-alpha, and would remove some of the features that I think you’re relying on, including running snake and raster scans. If you’d like to test it out for us, we can work on getting a copy of the updated SD card image to you?

The downsample=1 works! Now I get the >50mb pictures I was expecting.
The --minimum_overlap does help as well. I created a new scan with more overlap, but I must say the stitched_from_stage.jpg looks better and should be usable for the next step.

There is also a warning after the stitching is done:
WARNING: no pixel size information. Scale bars will be wrong. A better starting estimate of the csm is [[-0.12164364377833616, -0.9602417773216804], [5.77764935119365, -0.026030452895334805]]. You don't need to update the width

The scanning process seems to ignore my backlash configuration. I have to use ‘raster’ so only the lowest row is shifted a bit.

Regarding the live-stitch-preview: I think I stick with the stable version. Soon some students will use it. But if you need a tester you can come back to me.


All of your slide samples have very strong vertical features because of the roots, and in some slides strong vertical blue marks between the roots. Most of the stitching looks good, but there are also clear stitching errors in all of the images when I look at horizontal features. One of the important things about the stitching algorithm that @JohemianKnapsody has is that it does not attempt to blend the stitch lines, so errors are much clearer as discontinuities rather than blurred.

In some stitched images here, there also ends up being a whole column of blank images, which would be likely to confuse stitching, or there is a single very sharp vertical line through the images, which would give very good horizontal registration, but a lot of uncertainty in vertical registration. It might be worth trying the slide diagonally on the microscope, to make the strong lines available for both horizontal and vertical registration.

In that final image of the post above it all looks good except for the bottom row of images which has clearly been placed too low down: there are features duplicated at the top of the first row and the bottom of the second row. In that case the sample fills all of the panes reasonably well and has a good range of horizontal and vertical features, it is surprising that it failed in that way.