amchagas / flypi Goto Github PK

Currently the camera/lens combination gives a resolution of 50µm.
To increase the number of applications, it would be great to brings this resolution down to 10-20µm.

This could possibly be done with:

• Different optics
• Different cameras
• Software to process the data

What is the best cost/performance/easiness of use solution remains to be discovered.

We've been working on a version for the GUI using pyqt5. this is on the serialupdate branch.
the GUI is already functional but the files organization is a bit chaotic, there are two files, one describing the entire GUI and one having all callbacks.
We want to create a class for each part of the GUI so things are better readable/organized and easier to add and remove as they will be more modular.

Tom's request while using the flypi in Tanzania:
Request about the autofocus control. Can u change this so that it is just a "field". Then if you hover the mouse in the field and press mouse left it goes one direction and mouse right the other direction. so move while hold the click and stop move when release. Right now its very hard to focus on something as u need to accurately reposition and click the mouse to stop the focusing. Could even leave the slider with an auto home function (ie. that it just jumps to zero if u dont press a button)

Right now the GUI has "+" and "-" buttons, which work just fine, but it is hard to tell when a max or min is reached. It would be a good idea to substitute those buttons for sliding ones. Os some other solution that tells the user at which stage from each parameter he/she is in.

When no arduino boards are connected to the system, the GUI sends out an error:

pi@raspberrypi:~/Desktop/Flypi-master/Python $ sudo python3 run.py
Traceback (most recent call last):
File "run.py", line 16, in
flypiApp(root)
File "/home/pi/Desktop/Flypi-master/Python/flypiApp.py", line 112, in init
self.ser = serial.Serial('/dev/ttyUSB0', 115200)

It would be ideal to have an automated system so that when all "peripherals" are turned off, the serial library is not called.

Started a branch to tackle this issue: https://github.com/amchagas/Flypi/tree/load_arduinoless

In order to allow for more production methods, it would be nice to add a PCB layout where SMD components are used, instead of through-hole. I think using "large pitch" SMD components would allow people to still solder everything by hand and reduce the PCB footprint, making it cheaper to source

Hi, first thanks for the detailed instructions for such a cool microscope! We´ve managed to build one, using the PCB version 0.6 and the 2nd version of 3D-printed parts (some photos attached). It works as expected - a manual, together with some forum discussions were helpful enough to make the basic system running. Still, we have some extra questions and would be grateful for your opinion. The prometheus science forum seems like a better place to open this issue but I was somehow unable to register neither normally nor via Twitter.

We´ve implemented the automated focusing of the RaspPi Camera but it seems, with the printed cogwheels provided, that it can´t really do it´s job? Servo´s limited 180 degrees of rotation covers only a small range of the lens´ thread which enables focus adjustment. Since the cogwheels are quite tightly attached to each other, it is also not possible to roughly adjust the focus manually, at the same time the cogwheels are attached. Have you also encountered this issue or is there a better way to construct the automatic focusing? We´re using Reely Analog Servo S-0009 MG. Besides increasing the cogwheel size, we were thinking a bi-directional DC motor could help us with the issues. Maybe something similar as it is described here: https://learn.adafruit.com/adafruit-dc-and-stepper-motor-hat-for-raspberry-pi/overview ? Or is there a specific reason the servo motors are used? Any suggestion would be appreciated.

Also, as it seems servo motor cogwheels and the LED matrix holder STL files are missing in the second version. Maxime kindly sent the cogwheel STL files. As for the holder, I´ve read that you haven´t update it due to lack of public interest. Just in case, I wanted to ask, wheather it has been created in the meantime?

Lastly, it´s not really crucial but we have a problem with the zap function in the LED1 module. It works well for the LED Ring but nothing happens when the zap button is pressed to control the timing of high-power UV LED. I´ve seen that the arduino sketch (flypi_development.ino) in the LED1 section doesn´t include similar zap parts as in the LED Ring section - is this why it doesn´t work and should still be added?

Thank you very much!

When the Peltier class is turned on and a certain protocol is executed, sometimes the system will freeze. This is related to the fact that there is a "lock system" where the python code and the arduino code are exchanging messages to make sure certain tasks are completed before moving on to the next ones. If for some reason the code is not received, the system will freeze.

This issue is part of the MiPi:zap: extension!

We want to develop an agar plate imaging and live colony counting system!
Because colony counting will be relying on image analysis algorithms image quality is a key factor for a low error rate. That's why a good agar plate imaging system is essential for this and all future MiPi:zap: modules.

Experience with imaging Agar plates:
Problems:

• reflections in the agar (wet surface!)
• imaging through the agar or from the top impacts image quality
• possible contamination
• different bacteria behave differently -> low consistency regarding colony opacity

Experience/Solutions to avoid the Problems:

• indirect lighting of the agar plate produces high contrast images (pseudo "dark field", other project)
• uniform lighting through a white weighing dish might be good enough!
• a good algorithm can compensate problems with image quality/different colony opacity (e.g. OpenCFU)

First steps:

• test lighting setup with already existing modules of the FlyPi
• develop algorithm using example images

Currently the GUI runs on TKinter.

It would be an enhancement to port everything to PyQT5 due to its active development and user base.

Work for this has started on this branch

Right now the PCB holder is a printed part. This solution works, but it is not optimal. It would be great to come up with an alternative.

Things we thought about were:
-- Adding screw holes that fit with the Pi's screw holes, this way we could use longer screws and spacers (nuts threaded against one another, or plastic tubes) to keep everything together.
-- Adding a female connector to the PCB that fits the IO connector of the pi and connect them via this plug - This might not be super stable, but may allow easier access to the IO ports.

Right now we record h264 videos, and to be able to read them into imagej/Fiji, we have to convert it to mp4, then to avi, which is a bit idiotic. Specially because the MP4 to avi conversion is done in a tool that is not available for linux.

It seems more people than we thought are using the LED matrix that was published with the paper. Since there wasn't much use from our side, we didn't port the holder of version 1 to version 2 of the printed parts.

We want to create a holder for it. The matrix is this one: https://www.adafruit.com/product/870

Currently the system has 1 PCB containing all hardware modules. Optimally, each module would be implemented in a small PCB, as a piece of a puzzle. Seeed has implemented something like this with their grove system.

The advantage of this modularity would be to reduce costs (as users only need to source parts for the modules they need and each PCB will be smaller). Also it will allow bigger customization as users might want 3 LED modules and no Peltier module (as opposed to the stock 2 LEDs and 1 Peltier).

The current systen for holding samples only allows microscope slides to be held and it is based on a tight fit. If a thicker or thinner microscope slide is used, it is a bit troublesome for the user.

To correct this, a system with a screw lock would be nice. Maybe re-using the printed screw system present in the other parts of the system. Another nice addition would be to have an interchangeable head, where different holders could be placed in, depending on what the user needs in terms of attachement.

Part that holds the microscope slide:
https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/Manipulator_Zaxis.step

Here are the files containing the screw system (as guidance):
https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/NeckTriangle_Thread.stp

https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/NeckTriangle.stp

The UI (currently at the serial update branch) needs an upgrade on the design, focusing on usability and layout. Here are some screenshots and some ideas of what can/needs to be improved:

The light devices tab should be rearranged/reorganized to fit better on the screen and look more harmonic.

The current petri dish holders are fixed to two different sizes. It would be nice to have a clamping system that is able to handle dishes and other containers with different sizes.
It can use the thread/screw system already implemented on the system.

here are the files for the petri dish holders:
https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/PetriDish_56mm.STEP

https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/PetriDish_36mm.STEP

and the thread/screw system:
https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/NeckTriangle_Thread.stp

https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/NeckTriangle.stp

In the FlyPi publication we showed the system works for certain types of fluorescence samples/assays.

A very nice enhancement would be to extend the fluorescence library, so that the device can be used for different experiments/protocols.

This will most likely involve playing around with:

• different LEDs (different wavelengths and power).
• different light filters (different shades, different combinations of emission and excitation filters).
• different cameras (maybe using true BW cameras will give a better sensitivity to pick up fluorescence).

Hi all,
My build is a v. 2.0, running GUI 2.2.

Aside from a non-responsive servo module (if anyone has run into this issue please let me know), all seemed to be working fine (all the lighting options are working great) until I tried the peltier module. It heats up fine, e.g. to 35C, but when I try to cool to 15C, it will not cool beyond 25C. I have a heatsink attached to the peltier module, and a fan blowing at it (according to instructions).

Anyone run into this issue? Do I just need more powerful cooling?
Thanks for any insight.
-Ruud

Hi,
I am working on trying to get the GUI running. I have solved some roadblocks that I have come across so far, but can't get past this one yet after a couple of hours of searching and troubleshooting. So I thought it was time to reach out. Did you do anything special to get PyQt5 installed on your Raspberry Pi with PyQt5.sip as a module?

I was finally able to get PyQt5 using $ sudo apt-get install python3-pyqt5
But there was not PyQt5.sip module.
I tried making sip from source as PyQt5.sip and that worked... but then there was another PyQt module that was missing and I could not make the dependencies match.

Then I tried installing miniconda thinking that it should have all of these modules. It almost worked. I am still getting an error (now for PyCapsule_GetPointer called with the wrong name). In searching it sounded like downgrading PyQt5 to 5.10.1 would solve that. But I cannot seem to do so.

Did you have troubles with this? Do you have an environment file that you could share (though I only know how to do that in conda)?

Any insight would be great.

Currently the PyCamera library sends the image to the screen sending data directly to the GPU, and bypassing the Pi's CPU:

That takes care of how each line’s read-out time is kept constant, but it still doesn’t answer the question of how we can guarantee that Linux is actually listening and ready to accept each line of data? The answer is quite simply that Linux doesn’t. The CPU doesn’t talk to the camera directly. In fact, none of the camera processing occurs on the CPU (running Linux) at all. Instead, it is done on the Pi’s GPU (VideoCore IV) which is running its own real-time OS (VCOS).

This means that connecting to the PI via SSH doesn't allow for the camera feed to be displayed on the remote computer. We would like to solve this issue by sending the camera stream to eg. a file, and then sending the data via SSH. This has already been implemented by the waterscope project, so that would be a good place to start looking.

Important here would be to know:

• what is the lag this generates ( can users focus their samples using only the feed sent via SSH? This way we could bypass needing a keyboard, mice and computer screen).
• What would be a safe way to implement this for true remote access (Flypi in Germany, accessed from the UK). Mozilla IoT project might be a place to start looking.

Hi,
I was just wondering which Arduino file should I write into the Arduino board, since there are several files in the Arduino folder.
Also, is there missing something on page 5 of the assembly manual? After installing the Adafruit libraries, further steps are not specified.
Thanks!

The GUI currently controls servo movements with a single slider. The moment the slider is dragged, the servo starts moving and only stops when the slider is reset to zero. This system makes it very hard to accurately focus at high zoom. Instead, it would be helpful if some controls could be added that move the servo in small installments e.g. upon clicking a "execute" button or similar.

The protocol tab needs to have aesthetics improved.

Right now the high power resistor used for the Peltier Unit is on the backside of the board, and the soldering has to follow a certain order, otherwise the holes for other components get blocked. We should change the location, maybe move it to the top side of the board.

We are currently using a 5V fan to cool down the Peltier element. It would be nice to change the circuitry that controls the fan (mainly a transistor and the power line input) so that we can use 12V fan instead, as they are cheaper and easier to source.
On the transistor topic, it would be nice to revise the other transistor implementations, the ones that are used to power "strong LEDs" and the one used to control the servo motor, to make sure they are fine tuned to those needs.

The 12 to 5 voltage conversion module for the Pi (bottom right corner, close to power supply), seems to deliver enough current for the system to work, but a "low-power" indicator blinks on from time to time in the Pi Desktop.
Additionally we should change the plug from the power output from the board to the Pi. Right now it uses screw terminals. Having a USB connector so that a "normal USB smarphone cable" is possibly the best solution here.

The system to keep the boxes closed is too fragile, as the stress points are in the same axis as the printed parts. it would be great to develop a new closing/clicking system for the boxes where the locking parts do not break so easily.

Here are the files for the boxes:
Raspberry pi case
https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/RaspberryCase_Top.stp

https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/RaspberryCase_Rails.stp

https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/RaspberryCase_Bot.stp

PCB case:

https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/PCBCase_Top.stp

https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/PCBCase_Bot.stp

We want to create new FlyPi modules for microbiology applications!

This issue collects all the possible MiPi modules and links the respective module issue. Please post any general ideas and comments right here.

Module ideas:

• Agar plate imaging and colony counting module
• Colony size/migration area analysis tool
• Colony shape identification
• Blue/white screening help
  usw.

There is a PDF describing how to build and use the FlyPi. Unfortunately this document is outdated, since the hardware and software have been updated.

This update has been started and we are now favouring an open online documentation system called wikifab. The FlyPi documentation can be found here.

This documentation needs to be extended and finished.

The current software makes photos and videos just fine, but the way files are named allows for data to be overwritten. One should add a time stamp to the file names as a simple way to avoid this problem

The base could use some optimizations:

1 - Currently it takes quite a while to print, it would be useful to hollow out some parts so that it prints faster. It should be kept in mind that hollow parts require some sort of support/bridge to print properly.

2 - on the top side of the base, where the peltier cables go in, one of the sides is higher then the other. we want to fix that by making both sides as low as the current lowest side and to make the slits curved and not squared as they are currently (this will lead to better finishing when it is printed)

file for the base https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/Base.stp

Hi,

is it possible to add a scrollbar to the main window? Depending on the screen resolution, the main windows sometimes does not fit in the screen and some buttons are not accesible. I tried increasing the resolution in the Raspberry pi, but for an unknown reason, VNC does not show the desktop if it put in the highest possible resolution
thanks

The UI (currently at the serial update branch) needs an upgrade on the design, focusing on usability and layout.

Here are some screenshots and some ideas of what can/needs to be improved:

• The sliding bars and displays should be made similar to the ones in the other tabs (for example light devices).
• Due to a limitation of the Camera system in the Raspberry pi, the camera feed is always displayed on top of everything else on the screen. to work around this, and keep the feed update speed we want to:
  • have an "empty space" on the UI where the camera feed can be displayed over
    • it should react to changes in the user interface size (always trying to display the maximum size possible from the camera feed)
    • turn the camera feed off if the UI is minimized.
• The servo tab content should be bring to the camera tab, since it will be controlling the focus/magnification of the camera

E.g. https://github.com/amchagas/Flypi/blob/master/PCB/flypi_pcb_kicad/1-click-bom.csv#L4

Kitspace build is failing because of this.

As an enhancement it would be great to have on the PCB:

• Open source hardware logo
• Link to github repo
• Revision date and author
• Trend in Africa logo

We see that there is a v2.0 folder in the STLs folder but none in the releases. Is the Flypi getting a new iteration?

The current version of the z axis of the micromanipulator consists of an M4 screw and a single locked nut that act as the axis carrier. this makes the axis a bit wobbly.

A possible solution for this would be to add a second nut at a certain distance from the previous one similar to what is present on the other axis.

Other improvements to be implemented are:

• Adding a spring (or two) to the axis to decrease backlash
• improving the pockets where the nuts go in.

Here are the files for the manipulator:

Thumb Screws: https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/Manipulator_thumbscrew.step

Base: https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/ManipulatorBase.stp

X axis: https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/Manipulator_Xaxis.step

Y axis: https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/manipulator_Yaxis.step

z axis: https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/Manipulator_Zaxis.step

Hi,
It's me again. I know you are very busy so don't want to create too many 'issues'. I am solving things where I can (and learning a lot). I came across a new issue that I think I know how to get around but am not sure. At some point, I can learn how to propose/contribute edits via git (I have never done that before and have not been good at following branching protocol, etc in my life; but want to).

Today I am trying to get the Arduino code going so that the Rpi GUI can communicate. (Yesterday I got GUI_1.0 working on my Rpi but only with the camera module). Today I learned how to communicate with Arduino via Python and serial! (I was learning using pyfirmata). So I think I am understanding the premise behind the FlyPi communication setup between the Rpi and the PCB/Nano.

So from what I understand currently, you have written arduino code that sets it up to receive commands via python directly (analagous to the pyfirmata 'standard' script that I was loading earlier today onto my nano to control via python). I am working with the most recent script found in the v2 folder called 'serial_test'.

I solved some Library import issues with the adafruit packages by adding via zip downloaded from git directly and found Stephen Cogswell's 'SerialCommand.h' at https://github.com/scogswell/ArduinoSerialCommand/blob/master/SerialCommand.h, which I used to 'add library via zip'.

The #include works for this, but it seems like one of the modules called in your arduino script is not (no longer?) a part of their library.

ArduinoIDE check fails on:
sCmd.setDefaultHandler(unrecognized); // Handler for command that isn't matched (says "What?")

Looking at Stephen's code, it seems like the command might have changed to 'addDefaultHandler'?
void addDefaultHandler(void (*function)()); // A handler to call when no valid command received.

I edited the Arduino code for addDefaultHandler for now.
When I did this, the IDE compilation completed.
BUT I do get the following orange text:

<my filepath>/Flypi/Arduino/v2.0/serial_test/serial_test.ino: In function 'void setup()':
<my filepath>/Flypi/Arduino/v2.0/serial_test/serial_test.ino:120:38: warning: invalid conversion from 'void (*)(const char*)' to 'void (*)()' [-fpermissive]
   sCmd.addDefaultHandler(unrecognized);      // Handler for command that isn't matched  (says "What?")
                                      ^
In file included from <my filepath>/Flypi/Arduino/v2.0/serial_test/serial_test.ino:31:0:
<my filepath>/Arduino/libraries/ArduinoSerialCommand_master/SerialCommand.h:85:8: note:   initializing argument 1 of 'void SerialCommand::addDefaultHandler(void (*)())'
   void addDefaultHandler(void (*function)());    // A handler to call when no valid command received.

Let me know if you think this is an error that I am missing a step somewhere or have the wrong library.

Control the focus motor with GUI. Have to write a class for it.
should be able to:
move fast
move stepwise
completely shut down motor so that it doesn't drift.

It will be very useful if the connectors to the ring, fan, etc. were changed to USB_A. This will make it easier for users to plug in/out external modules at their convention.

Please also take care of the inductors footprint on the PCB, they are of the wrong size.

In order to plug and unplug modules, users need to disassemble at least the PCB box.
What we want is to create a click on or flipping system where the modules can be plugged and unplugged in an easier manner.

Here are the files for the PCB box, where the modules are plugged in and out:

https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/PCBCase_Top.stp

https://github.com/amchagas/Flypi/blob/master/3D_print_files/v2.0/STEPs/PCBCase_Bot.stp

If the users create videos or time lapses that are too long/big, the sd card will be filled up and the system will be inaccessible upon the next boot. Recovering data will be a pain and normally the whole system has to be reinstalled from scratch.

This normally happens because up to now, we have been using only one partition for user data and system data. One solution could be to partition the SD card, so that the /home folder goes into its own partition, and even if that gets filled, the system partition will still be able to work.

Here is a link describing steps to create different partitions in raspian https://mike632t.wordpress.com/2014/02/10/resizing-partitions/

The peltier tab needs to be worked so that it passes together visually with the other tabs.
Also the spacer left there should be prepared for plotting temperature data in realtime.

Hi,
The digikey cart almost fills completely using the current BOM but there are two obsolete parts.
Would you be able to advise on appropriate replacements that fit the specs of the unit and also match the footprint on the gerber?

https://www.digikey.com/en/products/detail/parallax-inc/452-00007/7791449?s=N4IgTCBcDaICwFYwFoAM7UHZkDkAiIAugL5A
and
https://www.digikey.com/en/products/detail/osram-sylvania-inc/LZ1-10UB00-00U4/5034037

Thank you!

Change the "addressing" system. The way it works right now, only values up to 999 milliseconds are possible. If one uses two subsequent address variables, the problem should be fixed.

Rewrite on the development branch, the "protocols" user interface.
should be able to:
-run trials
-independently control devices
-dry run
-log temp
-log start and end time