WSL Skippy

[FrederikBaumgarten]

@lizzieinvancouver @afong3 @DeirdreLoughnan @soleil-nocturne123 @kim-dajeong

Hi there Last night I had a great chat with Holger Gärtner, one of the two persons that invented Skippy. After a few questions he told me we should stop reinventing the this wheel and gave me all the instructions and parts for their model! (I put it on the repo in the folder "Skippy_WSL"). He will send me the files for 3D printing as well and also the software along with it! They have build 15 devices meanwhile. Took them 2days per device. And yes, this is all for free. They would greatly appreciate if we could improve the code and share it with them. I think their new model involves x and y axis. He was very intrigued by my question of the one shot, especially because he told me that their 60MP camera is right at the edge...

So I think you should go through these slides and the parts...

cheers, Fredi

[lizzieinvancouver]

@FrederikBaumgarten That's amazing! I am okay to go this direction if others want to. @soleil-nocturne123 @afong3 @kim-dajeong -- thoughts appreciated.

One concern here is that we will not be able to publish or share how we built our device, since Skippy has made their materials proprietary as best I understand.

[afong3]

Awesome work getting the details from WSL! I'll highlight some key components to help our decision making.

Specifications:

Specification	Skippy Spec	Ideal Spec	Specs Met
Maximum Diameter	35 cm	50 cm	:x:
Cost	~$7,000 CAD	Unclear, but sizeable	:white_check_mark:
Plane of Camera Travel	x-axis, z-axis	x-axis, y-axis, (z-axis?)	:x:
Image Stitching	Set of images exported, processed on different machine	Stitching on device prior to export	:x:
Ring Image Analysis	Out of scope	Automated with reasonable operator intervention	:x:

My thoughts:

From a materials perspective, the documentation seems pretty complete for acquisition + assembly. From the skippy video on youtube, it appears they have a desktop GUI and connect to the printer via USB or similar. I assume this could also be acquired from WSL. Their design seems to be reasonably functional but is pricey considering their fancy camera.

My main concern with Skippy is not being able to digitize the entire tree core. This sacrifice will likely be able to lessen the total time for the project to be delivered significantly. That being said, I wouldn't discount the open source and well-documented resources for x-y gantry machines (due to their popularity with the 3D printing community). Making a machine that does this just takes more time than making a Skippy.

If it's more important for the lab to get digitizing as soon as possible, I figure we should duplicate a Skippy. Identifying and segmenting tree rings is still a non-trivial task, and having as many samples to work with while developing that will be key.

If we're aiming to publish, which I think would be a perk, there's definitely potential to make our own rendition. This would be with a realistic lead time of a few months - not including robust image stitching and ring identification. I think it'd be very interesting if a raspi camera could perform comparably to a professional camera in this specific lab environment.

I may have missed this discussion but it's hard to choose which path to go forward without knowing what everybody wants and what the lab needs. My interest would be in publishing a paper, as it would be a first for me. But if that doesn't meet the time requirements, I'm happy to build a Skippy. Building something useful is my first priority.

[DeirdreLoughnan]

@afong3 Thanks for this, it does a great job of laying out the pros and cons of the different options.

In talking with everyone, including @lizzieinvancouver, I think we are interested in building something that goes beyond what the current design of skippy does.

We would like to prioritize having a device that can quantify tree cookies, with movement in the x and y-axes and automatically stitch the images. I agree that this is not an impossible task and we can draw on other fields to help with our design.

So in terms of next steps, @afong3 could you create a google sheet and share it with everyone? We can have a tab for the structural parts, with a column for estimated price. We can add to this as we go, but once we have a rough budget for the main components, we can discuss the easiest means of paying for things and how to reconcile expenses.

@soleil-nocturne123 @kim-dajeong could you add a tab to the google sheet for a list of the firmware components and prices?

Let's aim to have this done by the end of next week, Dec 1, so we can start ordering things soon.

[lizzieinvancouver]

@DeirdreLoughnan @afong3 @soleil-nocturne123 @kim-dajeong @FrederikBaumgarten Just showing up here to express my excitement about this!

[afong3]

I'm starting to work on the structural design here. I plan to have it roughly done in CAD before ordering any parts. The structure for a Raspi camera and a DSLR / mirrorless camera will be drastically different. My heart tells me to design it for the Raspi cam, resulting in a smaller frame, less material cost, cheaper camera. The risk here is that the Raspi camera doesn't provide sufficient quality, which would go against previous calculations. A major benefit is that the majority of the design concepts would be transferrable to a larger camera down the road.

On the topic of firmware / motors / electronics, I strongly suggest we should stick to what the CNC or 3D printing industry uses. The majority of the 3D print industry uses the open-source firmware (Marlin)[https://marlinfw.org/] and CNC's use the open-source firmware GRBL. As far as I know, the firmware is only compatible with stepper motors. Either of these can be installed into common Arduino motor controller boards. So either should be fine for us to rely on - CaptuRING uses Marlin.

I foresee two major coding tasks. The first would be making a robust method for stitching together a grid of images with a reasonable amount of overlap (20% recommended per PTGui, the software recommended by CaptuRING). This may be as simple as calling a function from OpenCV's image-processing library. Combining a grid robustly might need more nuance than this though. I've only stitched horizontally sequenced images together in the past. It will also likely be far too heavy of a CPU load for a Raspberry pi to compute in a reasonable amount of time. This could be developed in parallel to the physical device - using carefully taken photos from a phone and a tree ring.

The second task would be writing a script to create "Geometric Code" (G-Code)[https://howtomechatronics.com/tutorials/g-code-explained-list-of-most-important-g-code-commands/]. G-code instructions are what tells a 3D printer / CNC where to move, and along what path. This is also what Marlin / GRBL digests to control the motors. In our case, it will move the camera to frame a portion of the cookie. I imagine the G-code will navigate a grid projected onto a bounding box at the extents of the cookie. This will be mostly dependent on having a physical device to make meaningful progress.

Thoughts would be appreciated on this! Sorry for combining almost every design topic on this thread. Just wanted to keep things in one post for my own train of thought.

[lizzieinvancouver]

@afong3 Thanks for your work on this!

The structure for a Raspi camera and a DSLR / mirrorless camera will be drastically different. My heart tells me to design it for the Raspi cam, resulting in a smaller frame, less material cost, cheaper camera. The risk here is that the Raspi camera doesn't provide sufficient quality, which would go against previous calculations. A major benefit is that the majority of the design concepts would be transferrable to a larger camera down the road.

I have been out of the loop on this, so take everything with a grain of salt ... I worry the raspi camera will too low quality -- I think we need a camera that takes different lenses (right?), which I think raspi does not do (right?) That said I have not followed raspi camera improvements etc..

I like breaking down the coding tasks so we have a lead on each .... we should touch base on who can do what next week. We should also see what time @sandyie has in the new year for coding on this.

[afong3]

I share the same worry with the RPi camera! But they do now offer a version with a lens mount - when paired with a microscope lens, they take surprisingly good images. Below are two images of the Raspberry pi's logo, zoomed in. For reference the Raspberry pi logo is ~1.5 cm x 1.5 cm. Sorry to fixate on this but it does have the potential to save a few thousand dollars compared to a macro lens + camera combo.

[lizzieinvancouver]

@afong3 Okay -- you've convinced me! @DeirdreLoughnan and @FrederikBaumgarten seemed to agree with this proposal also. Let's try it! Worse case is we learn something and then try the other way -- and that's worth something too.

Thanks for all your work on this to explain it and think on a good option.

[DeirdreLoughnan]

@afong3 thanks for laying out the different options. It is exciting to see things take shape.

I am fully behind trying it with a Rasp pi camera. @lizzieinvancouver it sounded like your concern was that we still might want to use a macro lens. There are a range of different lenses we could be using and mounts we can easily buy. At around $40 each, we could also try a couple options and see how easy it would be to build something interchangeable.

I agree that a stepper motor is the way to go (see issue #4). Our rate limiting step wont be the motor speed, but the number of images we take. But there is such a large community using this type of motor and I think we should take advantage of what is already out there.

Adam, you might have some better resources that you have been using for the camera options. Could you add any you are using to git issue #2 when you have time?

[lizzieinvancouver]

@afong3 @FrederikBaumgarten @lizzieinvancouver Posting this to a couple issues to share -- I started a refs page with a cool new ref to check out