Contribution to port from MATLAB to Open Source Alternative

[Akshay Verma]

Hi,

Academically I am an Aerospace System Engineer and currently into Embedded Software development.

I would like to help in converting your code base from MATLAB to Python, or any other, open source alternative as highlighted in this article under "Linux community contribute" question.

Regards,
Akshay

[Jonathan Kuniholm]

Akshay - 

Thanks! That sure was quick. 

We're having a call with another volunteer in 2 hours and 45 minutes (12 PDT) on the embedded system designed to collect the signals if you have any interest in joining and discussing your effort as well. 

If you (or anyone else on the list) is interested in joining the discussion (we will talk about software as well as hardware), please send me an email and I'll add you to the Google Hangout (so Gmail address is easiest).

Thanks,

Jon Kuniholm

--

---
You received this message because you are subscribed to the Google Groups "myopen-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to myopen-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Amol Sethi]

hi Akshay
for matlab porting i can also join in. please do mail the a brief project strategy & work distribution on the group.

[Akshay Verma]

Sorry for late reply.

I have not given much thought into porting.

Hi Amol, would like to know your thoughts on the strategy. Have you gone through the MATLAB code/ documentation?

Hi Jonathan, Would love to have your guidance on this porting strategy.

Best Regards,
Akshay Verma.

You received this message because you are subscribed to a topic in the Google Groups "myopen-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/myopen-dev/X1A7J4bukaw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to myopen-dev+...@googlegroups.com.

[Amol Sethi]

Hi Akshay

Following is a brief walk through of whatever i have understood after scanning through the svn repo so far  [Jonathan and others please correct me wherever i am wrong ] :

After you checkout the myopen-read-only directory , you can see a whole directory tree.

1)   myopen-read-only/Documentation/Reference :

For Theory:

This is the starting point . Kevin Englehart 1998 Thesis.pdf gives you the details of all the DSP related stuff that is required to process an "acquired" Myoelectric signal.

NOTE 1: In the thesis, Following approaches for feature extraction, dimensionality reduction, and pattern recognition of MES (myoelectric signal) are discussed :

 a) the short- time Fourier transform
 b) the wavelet transform,
 c) and the wavelet packet transform

Out of these wavelet packet/ PCA signal representation is favoured .

Once you are done with the theory, you will get a brief idea of what we are getting into.

A high level Work Flow of myoelectic signal acquisition & processing is shown below:

1. human thinks of hand /finger/arm movement  ---------------------> 2. corresponding nerves in upper arm get excited -------------> 3. Action potential in the muscles gets raised -------------------------------------------------> 4. This small electrical signal  (of the order of microvolts) gets detected from Skin surface using a sensor ( Surface EMG) ---------------------------> 5. these sensors are connected to amplifiers -------------------> Signal is now in volts ----------------- > 6. A/D converter ------------------------------------> 7. DSP /Blackfinn { this is where all the signal processing as mentioned NOTE 1 above happens } ------------------------> 8. decision about which particular action this signal maps to is concluded ( also in dsp) -------------------------------> 9. corresponding actuators connected to a prosthetic arm are triggered.

2) Most of the remaining directories except "Minivie" are concerned with the EMG Signal processor board and can be passed in the first reading.

3) myopen-read-only/MiniVIE/Readme.txt   explains what MiniVIE is ..

In Summary:

If you do not have a prosthetic arm ( as in step 9 above) and you have  to test how well your algos (as in step 7/8 above) work, use a simulator and check it on monitor screen ( a virtual arm).

Also the same tool can be used to train the end user also.

Problem Statement:

MiniVIE provides a GUI based tool to acquire MES signals from an external data acquisition system ----> run the algos ( as in step 7/8 above) on ur PC -------> and display results as movements of virtual arms /fingers on ur pc monitor.

Unfortunately all the GUI of MiniVIE as well as the algos are written in MATLAB. Which is not free..

Hence we want to move everything to "SOME" free and open source alternative.

Solution Strategy:

Software:

1) I propose Scilab . Not because i have experience using it , but because google results show that it is the best alternative to matlab.

even wikipedia mentions "Scilab is the most complete open source alternative to MATLAB.:

Please provide your inputs if we can find something more suitable.

Some discussion threads that i would like to initiate:

Hardware:

1) While we can work with sample data collected as raw files from myopen.
A light weight arduino based data acuisition system can help us acquire more training sets.. I am working on this aproach ... would try to come up with something in a few days  meanwhile.. comments and ideas are welcome.

thanks and regards
Amol Sethi

[Jonathan Kuniholm]

I've actually not heard of Scilab, but what most people used to use in academic research instead of Matlab is a clone called Octave (http://www.gnu.org/software/octave/). Unfortunately, none of simulink or many of the toolboxes that I believe are used in minivie are cloned in Octave.

Jon

Jon Kuniholm

[Akshay Verma]

Regarding the Open-Source alternative to MATLAB, I would like to propose the use of Python, e.g., along with NumPy, SciPy and Matplotlib (link). Apart from this reference, I have personally used MATLAB, Octave and Python and tend to favour Python for its open-source nature and ability to be used as a stand alone program/application, you dont need to setup a big application on your PC. GUI part is also handled in extensively. I have attached second reference for my point with this mail.

The above was my suggestion, but I am comfortable in other environaments as well.

Best Regards,
Akshay Verma.

[Amol Sethi]

If i look at the advantages of Octave :

Since Octave is a matlab clone, we can reuse a good amount of existing code. The only parts of the code that we need to write are the functions that do not have a parallel in octave.

WIth Python , we might need to write things from scratch.  Although http://stackoverflow.com/questions/9845292/a-tool-to-convert-matlab-code-to-python provides some hope. Python may also give us a lot more flexibility from GUI development perspective.

Akshay .., any ideas on Matlab to python code converter/compiler..?

I am open to both the options.

[Akshay Verma]

I looked into the options and came across

• victorlei/smop · GitHub
• awesomebytes/libermate · GitHub

But I have not used any of these. They may not be complete in there functionality.

Amol, whats your opinion?

Best Regards,
Akshay Verma.

[Robert Armiger]

Hi All, Thought I'd chime in here regarding some of the requirements for consideration if porting the MiniVIE code.  I've looked into a few of these alternatives and have used Octace, python + libs but for the academic environment matlab seemed ubiquitous and open 'enough' in that all the code is sharable (and you can use the run-time that's up there too in worst case).  There are a few things that matlab makes easy, but I 100% agree it's not the only way.  Note also that MiniVIE does not use simulink at all.

From the basic organization of the 'virtual environment'  here's some key features that are currently supported in matlab that should be considered for replication:

Signal Inputs:
Ability to pull from multiple data acquisition sources including: USB DAQ, PCI DAQ, Serial DAQ, UDP/Networked device.  Currently these are enabled using the analoginput() serial() and pnet() functions

Signal Filtering:
Ability to filter using IIR/FIR filters: lowpass, highpass, threshold, clamp.  Currently enabled using filter()

Signal Analysis:
Feature extraction using time domain and auto regressive features, wavelets, fft, etc
Signal classification using Artificial Neural Network, Linear/Quadratic Discriminant Analysis, Support Vector Machine
Parameter space reduction using Principle Component Analysis

Control:
Maintain the kinematics / dynamics of the virtual arm.  Matlab does suck at this part and internal state control 'threads' are achieved through timer()

Presentation:
Need to do 3D visualization of arm and world.  Currently using patch() and opengl in matlab for rendering
Interface with Serial / Bluetooth joystick and arduino controllers for virtual gaming. 
USB Video Grabbing for bringing games like Guitar Hero into the virtual environment (Air Guitar Hero)

User Interface:
Rapid GUI development and customization.

Right now MATLAB was chosen because it's pretty easy to mix and match all those combinations (Hence the 'Environment' rather the single 'System').  Certainly aware of the limitations and open to suggestions but just wanted to lay out some of the key elements. 

Long term, I see two main targets for this system:  1) the user interface components should be on a smart-phone  2) the 'embedded' parts (signal acquisition, pattern classification) should be able to live on a prosthetic device.  So that might be factored in as well.

-Bob

[Amol Sethi]

Hi Robert

Please find my suggestions in-line:

On 29 August 2014 21:09, Robert Armiger <rarm...@gmail.com> wrote:

Hi All, Thought I'd chime in here regarding some of the requirements for consideration if porting the MiniVIE code.  I've looked into a few of these alternatives and have used Octace, python + libs but for the academic environment matlab seemed ubiquitous and open 'enough' in that all the code is sharable (and you can use the run-time that's up there too in worst case).  There are a few things that matlab makes easy, but I 100% agree it's not the only way.  Note also that MiniVIE does not use simulink at all.

From the basic organization of the 'virtual environment'  here's some key features that are currently supported in matlab that should be considered for replication:

Signal Inputs:
Ability to pull from multiple data acquisition sources including: USB DAQ, PCI DAQ, Serial DAQ, UDP/Networked device.  Currently these are enabled using the analoginput() serial() and pnet() functions

 

Signal Filtering:
Ability to filter using IIR/FIR filters: lowpass, highpass, threshold, clamp.  Currently enabled using filter()

Signal Analysis:
Feature extraction using time domain and auto regressive features, wavelets, fft, etc
Signal classification using Artificial Neural Network, Linear/Quadratic Discriminant Analysis, Support Vector Machine
Parameter space reduction using Principle Component Analysis

Control:
Maintain the kinematics / dynamics of the virtual arm.  Matlab does suck at this part and internal state control 'threads' are achieved through timer()

>> Please refer comment 1:

Presentation:
Need to do 3D visualization of arm and world.  Currently using patch() and opengl in matlab for rendering
Interface with Serial / Bluetooth joystick and arduino controllers for virtual gaming. 
USB Video Grabbing for bringing games like Guitar Hero into the virtual environment (Air Guitar Hero)

 

>>Comment 1: For Virtualization & modelling of 3D Arm , we can consider Blender

[Jonathan Kuniholm]

Bob -

Thanks very much for your detailed thoughts on this. As you and I have discussed before, the user base that we have gotten for both parts of this project is very small: you and your students are really the only miniVIE users that I'm aware of, and the two labs that Tim has worked in are the only embedded hardware users. There are a variety of reasons for this, and increasing the potential user base I think should be a primary goal of the next phase of both parts.

It's worth noting that because the labs focus on neural research (as nominally, does the DARPA RP09+ effort), these two efforts are essentially split at this point because of the differences between skin surface EMG and neural implant work, although both parts are designed to accept multiple types of i/o.

I very much agree with your two suggested requirements that 1) UI live on a smartphone and that 2) the embedded parts be able to live on a prosthetic device. This is key to getting novice/prosthetist users to play around with it and provide feedback and data. Developer testing using a smartphone and peripheral is not a burden over current setups, so I see no problem starting there, and this means that novice users could potentially get up and running with an android app store download and peripheral device. 

Other features of the current miniVIE seem a little more challenging are those in your Presentation/Control section. It seems to me that novice users (and maybe even some researchers) are most likely to use these features if they are built into the smartphone UI, or by using the peripheral as a USB game controller running a PC or console video game or virtual environment. I've checked in with Jerry Loeb and Rahman Davoodi on the status of MSMS, which we used for a time on the DARPA project. I'd be interested hearing if you think that it could be useful. At one time they were considering opening the code, which never happened that I'm aware of. 

Other inputs would also be more of a challenge on a phone.

Tim and I had a discussion years ago with some game developers, and I think that there remains an opportunity to gain interest in this project as a peripheral for able bodied users to control a virtual hand. Development tools for Playstation and XBox are closed (but free in cases: http://www.gamespot.com/articles/sony-loaning-out-ps4-dev-kits-to-developers-free-of-charge-for-a-year/1100-6412084/) and hands aren't animated beyond endpoint, but there are some OS tools out there like OGRE and Blender: http://cgcookie.com/blender/2010/05/13/rigging-easy-to-animate-fingers/

What about continuing to use the visualization by using the peripheral or smartphone as a controller for the matlab environment in the short term (moving as much else to open source as possible), with the goal to move viz to either part of the smartphone app or desktop or console app when possible, using either MSMS, blender, or other alternatives?

Interested to hear everyone's thoughts.

Jon

Jon Kuniholm