Group Actions
Engagement
  • Author Author: balearicdynamics
  • Date Created: Date Created
  • Views 1206 views
  • Likes 1 like
  • Comments 7 comments
Related
Recommended

Meditech: The imaging component settings and the data sharing strategy

balearicdynamics

Introduction and usage

One of the most versatile probes of Meditech is the camera that cover a meaningful wide range of applications shortly described below

 

  • Screening of areas, like skin or injuries detail for post-intervention documentation or to describe particular environmental characteristics
  • Series of short timed shootings to see reaction to some kind of stimulations (e.g. allergy test, eye reaction and so on)
  • Image details extraction to enhance some specific characteristics
  • False-color representation and low-contrast images enhancement
  • Image measurement
  • More

 

The camera probe should be relatively small and lightweight, battery operated and - despite the other parts of the Meditech "block" (the main case) needs to be managed independently, eventually near the patient. Accordingly with these specifications the "camera probe", not yet sure what other associated probes can contain, should have the following charactristics

 

  • Waterproof impermeabilised (not for liquid immersion but should not be damaged by rain, water drops and so on)
  • Flip-up camera lenses enabling an automatic time-lapse image shooting
  • Battery operated so when the probe fits its housing in the Meditech main case it is automatically put in charge ready when it is extracted
  • One or two button(s) to control the required features
  • 16x2 alphanumeric LCD controlled by a 74HC595 Shift Register
  • A white light ring Led set around the camera lens
  • Battery charger

 

Setting the capture side

To capture the images in the different conditions that are needed the raspistill has all the needed features: shooting time settings, single repeated image or different named frames, frequency, duration, resolution and a lot of other controls. So a couple of commands for starting and stopping the camera has been created; these will evolve in a more complex one managing all the features the camera can do as mentioned above, controlled by the button.

 

startcam.sh

#!/bin/sh
# Start still frame and stream to the server

echo "`date +%y/%m/%d_%H:%M:%S`: stream_start" 1>>/home/pi/stream.log
# Mount remote share
sudo mount 192.168.1.99:/home/pi/stream /home/pi/stream >>/home/pi/stream.log

# Image numbering
# for test only
#raspistill -w 640 -h 480 -q 10 -o /home/pi/stream/pic%04d.jpg -tl 200 -t 9999999 -th 0:0:0 -n >>/home/pi/stream.log 2>>/dev/null &

#Fixed name
raspistill -w 640 -h 480 -q 10 -o /home/pi/stream/pic.jpg -tl 50 -t 9999999 -th 0:0:0 -n >>/home/pi/stream.log 2>>/dev/null &

 

stopcam.sh

#!/bin/sh
# Stop still frame

echo "`date +%y/%m/%d_%H:%M:%S`: stream_stop" 1>>/home/pi/stream.log
sudo killall raspistill >>/home/pi/stream.log 2>>/home/pi/stream.log
sudo umount /home/pi/stream

 

These commands append a status log to the file stream.log

To start the camera still sequence you can see that before a remote folder has been mounted: this was the problem s that required most the time to test due the way the streamer interpret the new files added.

For a continuous still capture, to save disk space and avoid problems the command use always the same name for every frame. The result is that every new shoot the same file is rewritten.

A more detailed description of the file sharing strategy over the net for both the client and server will be discussed in the next paragraph.

 

The sharing strategy

The question of sharing files over the network Meditech is based on (it uses three different Raspberry PI has been solved using the NFS file system The entire installation procedure will be discussed in a separate post.

The principle is that the RPIMaster Raspi device includes a large storage: 1Tb USB hard disk so one of the roles of this unit is to collect and store all the data that are produced for any reason by the entire system. Adopting this kind of centralised architecture give the possibility to increase the number of future optional probes without altering the system in any way.

The approach is the following:

 

RPIMaster is the centralised device with the large storage system

RPISlave2 is the device dedicated to manage the camera features

 

The still image streaming process

  1. RPISlave2 starts capturing images and storing them to the folder ~/stream that is a shared folder on the RPIMaster
  2. SPIMaster runs the program mjpg-streamer that sends to the IP address of RPImaster via http on the port 8090 every net image detected
  3. The Display control device (the Android tablet) access the image

 

The streamer application

A note it is the worth on the mjpg-streamers application. It is a lightweight linux utility that manages all the streaming process with several options: can send the files to a folder, on the http output and so on.The problem is that the plugin of the application that detect the image, when a new frame is detected but then for some reason id deleted of changed it stops the acquisition and the streaming port become unresponsive. This event occurs randomly the streamer on RPImaster does not need to be synched with the remote device that shares the images. So in come cases some millisecond after the images has beed reconised by the streamer on the RPImaster, the same image is replaced by a new frame in the RPIslave2 sequence.

To avoid this psoblem I had to modify the plugin so that - only for testing purposes - when this event occur it is only noticed on a log file. As soon as the streamer has been definitely tested the updated version will be shared on a post to be available to other users with the same problem.

 

The streaming command

Also in this case a bash simplified command has beed created to start the streaming process when needed.

 

#!/bin/bash
#Start streaming

echo "`date +%y/%m/%d_%H:%M:%S`: stream_start" 1>>/home/pi/stream.log
/home/pi/mjpg-streamer/mjpg_streamer -i "/home/pi/mjpg-streamer/input_file.so -f /home/pi/stream" -o "/home/pi/mjpg-streamer/output_http.so -p 8090 -w /home/pi/mjpg-streamer/www" 0>>/home/pi/stream.log 1>>/home/pi/stream.log 2>>/home/pi/stream.log >>/home/pi/stream.log 2>>/dev/null &

 

The following video shows how this architecture works

 

Parents Comment Children
No Data