An additional driver layer

[John CC]

Rather than just having a PVC driver which talks directly to the arduino I'm proposing we develop another driver layer.

The extra layer sits between the PVC driver and the arduino, and provides a generic way to communicate with an arduino, and is completely independent of the PVC project.

The reason for adding the extra layer is so that it can be re-used on multiple projects, without having to re-invent the communications every time, or to have to copy chunks of code over and maintain it in multiple projects.

I've developed some of the code/functionality for this extra layer in C# already in the web UI prototype which is why the code has a project called "Duinocom". It was originally just part of the PVC project but I decided it's worth isolating it for re-use.

Currently it has 2 features....

1) identify the port that the arduino is on (so users don't need to figure it out and select it, which they shouldn't need to do)

2) send a command and retrieve a response

All that code is here:

https://github.com/Sensorica/PVCharacterization

I also managed to get the "senduino.py" script to automatically detect the arduino port. I don't really understand how it works because I'm not much of a python programmer, I just found some code online which did what I want and embedded it into the script. (I need to find the source for that again because the original developer should really get a credit in the comments).

This extra layer should become its own standalone project/library, in a separate git repository, and be included into the PVC project. That could be achieved by a git module, or a script which pulls the necessary code/libraries into the project from github.

The extra layer should include both the PC side (C#/python) code for talking to the arduino, as well as a C/C++ library that can be included into arduino sketches to handle receiving and responding to commands.

Both the C# and python code can be included in the same library/repo so people can choose which language to use. And people can then port it to other languages as well.

Or we could make separate repositories for each language, but have them use the same APIs, etc. and support all the same functionality.

The more I think about it this extra layer could actually be split again into 2 layers:

1) a simple way to send a line of text to the arduino and retrieve a text response (independent of any command structure), as well as the functionality for detecting the arduino port

2) a communication protocol which allows formatted commands to be sent and interpreted (independent of any specific commands, but providing command structure so people can come up with commands for specific projects)

Part of the reason for splitting it again into 2 layers is so that the core can be used on its own, or so that people can develop their own command structure library to interact with it. It avoids the issue of people being locked into a particular command structure when using the core, because a single command structure may not be suitable for every type of project.

So the layering would look something like...

On the arduino:

a) arduino hardware

b) arduino PVC firmware sketch (or any sketch, when used in another project)

c) arduino communication command library

d) arduino communication core library

On the PC:

e) python/C# communication core library

f) python/C# communication command library

g) PVC driver core (used to send basic PVC commands and return the response)

h) PVC advanced driver libraries (multiple add-on driver libraries for providing additional functionality such as scanning, scripting, etc.)

i) PVC application (for interacting with databases, etc. to save/analyse data)

j) PVC GUI (for user interaction and displaying data)

Those layers may get revised as we actually start developing them, depending on the technical details of getting the code to work. But it's a rough outline.

To non-programmers it might seem like this is adding more complexity. But I'm guessing most people familiar with programming recognize that splitting things up into independent, distinct layers/libraries actually makes each piece of the puzzle simpler, smaller, and more reusable.

The goal is to make each layer have as little code as possible to get the job done. The less code, the less complexity/bugs/etc. and the easier it is for people to maintain.

Tomorrow I'll see if I can work on moving the Duinocom project into its own repository, and figure out how to make the layers work the way I'm thinking.

Part of that will involve developing a very simple example app and example sketch, so people can see how to use the code. The example app and example sketch can be included in the repository along with the actual libraries.

If anyone can think up a better name for that generic communication library let me know. I'll keep calling it Duinocom for now.

[Thomas Vanesse]

That sounds like a reasonable structure even tough I am not fully convinced that such a high level of granularity is actually required considering the size of this project. Said differently, I agree that splitting the modules into smaller submodules can help to increase modularity and ease future maintenance, but I also think that for this particular project (which I consider to be very small), the advantage of this architecture is really limited compared to the added complexity. But that's just an opinion, there is no big deal in splitting the modules into tiny submodules even if they contain 5 lines code, it's just harder to get into the project for a newcomer (or not?).

That said, if everybody agrees to follow the structure proposed by John I would find it useful if each module and submodule could have its own directory in the repo with a README.md inside each of them describing the specs. 

I imagine the following workflow:

1) You decide you want to implement a submodule

2) You implement the submodule (or part of it) and you write unit tests

3) When you have successfully tested your piece of code, you strike the related specification in the README of the submodule and you push your local branch onto origin:<submodule>

4) When a submodule is completely implemented and tested, the branch <submodule> is merged into master

Does it sound good for everyone? Jim, Ahmed?

John, I think that before we go any further in the development process we should consider merging my fork into the official repo and set a clear file structure so that everybody can contribute straight away. For the time being I feel a bit blocked because I don't want to push on my fork while the official repo is evolving in a completely different scheme, and I believe the same problem applies for other project members. Is it OK for you to merge my fork and create the file structure according to your previous message before going any further? That would allow more people to get involved in the development process I think.

Looking forward to hear your feedbacks.

[Ahmed AKL]

Hello,

when developing this project, I think we need to consider few things for each approach to take the appropriate decision:

1- The time required for implementaton

2- The easiness to learn for future users

3- The approach complexity Vs project size (as Thomas mentioned)

I believe modularity can also be achieved using the proposed 4 level architecture (Arduino Firmware, device driver, Application, & GUI) without the need for further layer decomposition.

Each of these levels can be subdivided (if needed) to show different functionalities (e.g. control, communication, etc....)

To some up,  I believe that a simple architecture will save us a lot of integration time and effort, and can achieve the required modularity

What do you think?

--
Go to SENSORICA's project page
http://www.sensorica.co/home/what-we-do/projects/pv-characterization
---
You received this message because you are subscribed to the Google Groups "PV characterization project forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pv-characterization-pr...@googlegroups.com.
To post to this group, send email to pv-characterizat...@googlegroups.com.
Visit this group at http://groups.google.com/group/pv-characterization-project-forum.

To view this discussion on the web visit https://groups.google.com/d/msgid/pv-characterization-project-forum/906d7a27-9bf4-4b24-bbdc-4e5237e9cba5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Thomas Vanesse]

As you said, I'm more in favour of the 4 components structure because the project is small enough for that. Still, I understand the purpose of splitting down the code into smaller submodules and I would be able to .contribute in that case too... Now if two of us believe that the 4 components provide enough modularity, then let's keep going like this.

John, would you agree to keep the architecture (based on 4 components) that was previously setup in milestone 2 and merge the contributions that were made on my fork?

To unsubscribe from this group and stop receiving emails from it, send an email to pv-characterization-project-forum+unsubscribe@googlegroups.com.
To post to this group, send email to pv-characterization-project-fo...@googlegroups.com.

Visit this group at http://groups.google.com/group/pv-characterization-project-forum.

[Tiberius Brastaviceanu]

Thank you all for this work 

I captured this in the Software Working doc. and back linked from there to this discussion. 

I am trying to get a general picture of where we are and where to move next. 

If you want to contribute to the general picture, please edit the doc and coordinate further on this Forum. 

[Ahmed AKL]

Hello John & Thomas,

How are you doing? i hope you had spent a nice vacation in August

Abran's emails have started the engine again :-) 

I'm just wondering if you did any further modifications on the control SW, so we can start working on it again

To unsubscribe from this group and stop receiving emails from it, send an email to pv-characterization-pr...@googlegroups.com.
To post to this group, send email to pv-characterizat...@googlegroups.com.

Visit this group at http://groups.google.com/group/pv-characterization-project-forum.

To view this discussion on the web visit https://groups.google.com/d/msgid/pv-characterization-project-forum/906d7a27-9bf4-4b24-bbdc-4e5237e9cba5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Go to SENSORICA's project page
http://www.sensorica.co/home/what-we-do/projects/pv-characterization
---
You received this message because you are subscribed to the Google Groups "PV characterization project forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pv-characterization-pr...@googlegroups.com.
To post to this group, send email to pv-characterizat...@googlegroups.com.

Visit this group at http://groups.google.com/group/pv-characterization-project-forum.

To view this discussion on the web visit https://groups.google.com/d/msgid/pv-characterization-project-forum/1e6431d5-8d15-4f7b-b8fd-330246af1832%40googlegroups.com.

[Thomas Vanesse]

Hey Ahmed,

I implemented a working, extendable driver on the branch dev of the official repo with a bunch of comments and documentation. Check it out ;)

Tibi, I think there is a misunderstanding regarding the word "driver". When I talk about the driver in a general way, I'm talking about the piece of **software** that allows a computer to use a connected device (the arduino in this case) to send commands and receive data in a predefined format. I did not contribute so much in the **motor driver**, which is a piece of hardware that allows to drive current into the bldc ;)

I'm writing from my smartphone and will update the working doc accordingly.

[Ahmed AKL]

Hello Thomas,

sorry for the delay.... is this is the official repo? 

[Jim Anastassiou]

Yeah that's the official repo, just had a hangout with John  and Abran. We worked on the GUI functions and played with the idea of a common backend with two UI's: A software frontend as discussed and a webapp. This initiative was to involve John more on the dev. It also implements Sensorica's ideology of the LabOnline, something Joshua is interested in as well. For the next 24 hours we decided to each come up with a barebones fronted implementing the core functions. We updated the Software working doc pages 39-43.

To view this discussion on the web visit https://groups.google.com/d/msgid/pv-characterization-project-forum/CAKv7pU8B7ODLOH28v8Csdbis6dVi10LaO4mzt9GjHVCi2VR9Aw%40mail.gmail.com.

[Jim Anastassiou]

Forgot to mention Tibi was present as well. Who's up for a hangout tomorrow after 9pm?