search

rodizio1 / EZ-WifiBroadcast

Affordable Digital HD Video Transmission made easy!
GNU General Public License v2.0
816 stars 200 forks source link

Roadmap / Coordination to ez-wbc 2.0 #163

Closed Yes21 closed 5 years ago

Yes21 commented 5 years ago

Proposition of Roadmap / Coordination

Yes21 commented 5 years ago

1 - Make RD's Image Builder script work to generate a working image. (@RespawnDespair/@user1321) -- WIP --

2 - Transfer the code used to generate this first image from RD's github/projects to bortek's github (in a new branch).(@RespawnDespair/@bortek)

3 - Give the 2.0 version number to RD's Image Builder last version script, and duplicate it to a dev version for next developments.(@RespawnDespair)

4 - Add new features from others images.(@ALL)

bortek commented 5 years ago

This looks excellent @Yes21 . Any reason why it is closed?

Yes21 commented 5 years ago

Here is the first draft for a a technical roadmap for a good coordination of the revival of this great project.

Don't hesitate to criticize it, to not agree it, to gives your remarks, to propose corrections, ...

I've perhaps not good understood some technical steps. The list of proposed new features (I've perhaps missed ones) is not sorted by priority. We can see that later. Let me know if I've forgotten something or somebody.

I will update the previous post as many times as needed, until it's ok for everybody.

Thanks for your returns.

Yes21 commented 5 years ago

@bortek

This looks excellent @Yes21 . Any reason why it is closed?

Because it was not finished :)

RespawnDespair commented 5 years ago

That looks great! I can't find anything obviously wrong with this roadmap!

pilotnbr1 commented 5 years ago

This is excellent! I feel the scope is ambitious yet doable. After everyone comments and assuming this moves forward, whats next? Milestones? Volunteers and assignments?

Yes21 commented 5 years ago

@pilotnbr1

After everyone comments and assuming this moves forward, whats next? Milestones? Volunteers and assignments?

You're right. This first draft is focused on the first steps, which could take a few more time. We have time to think of milestones, volunteers, etc ... It will be perhaps time to use Trello, like proposed by @bortek.

You can, now and here, propose in which new feature you want to involve yourself.

Thanks for your comment :)

careyer commented 5 years ago

Liking the proposition a lot. Thank you very much Yes21.

May I ask to have a look at the proposition about "Compile flags/switches" again at the end of last (closed) threat? https://github.com/bortek/EZ-WifiBroadcast/issues/155#issuecomment-430676265 I think we have to also prepare to see more Add-ons and Extension in the future that might not all fit into a "one size fits all" image. Now is the time that we can prepare for that by considering this in the design of the build pipeline.

Thank you very much :-)

Von meinem iPhone gesendet

Am 17.10.2018 um 19:53 schrieb Luke notifications@github.com:

This is excellent! I feel the scope is ambitious yet doable. After everyone comments and assuming this moves forward, whats next? Milestones? Volunteers and assignments?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

Yes21 commented 5 years ago

@careyer Yes, I've seen it. I wil add it soon.

Yes21 commented 5 years ago

@ALL I want to have your opinion about the name of the next version.

I can suggest : 1.6RC7, 1.7RC1, 2.0RC1, ...

Give your opinion, or suggest anything else.

Thanks for your participation.

cyrilknops commented 5 years ago

@Yes21 I just can't stick to a RC (release candidate) i would say first release 1.6 with the mAh, time, distance osd features and than start development on 1.7 and when you have some major features like the ability to add add-ons, extentions or whatever you want to call them you call it 2.0

Yes21 commented 5 years ago

@cyrilknops Ok, I can understand what you mean. I note that you are for 1.6

pilotnbr1 commented 5 years ago

Yes 1.6 sounds good, keep it ez ;)

bortek commented 5 years ago

I vote for 1.6

careyer commented 5 years ago

Yes, let's finish that thing first: 1.6

Von meinem iPhone gesendet

Am 18.10.2018 um 07:35 schrieb Bortek notifications@github.com:

I vote for 1.6

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

RespawnDespair commented 5 years ago

Might i add the possibility of tracking everything right here on Github? https://github.com/bortek/EZ-WifiBroadcast/projects and then create an new project.

For example i did the same for my repository: https://github.com/RespawnDespair/wifibroadcast-image-builder/projects/1

careyer commented 5 years ago

@RespawnDespair : I think this is an excellent idea! Go ahead and do so (if @bortek does not veto)

RespawnDespair commented 5 years ago

@Yes21 could do this for this repository, i don't want to mingle here as well. I have the image builder to worry about for now 😄

Yes21 commented 5 years ago

According to the majority, the next version will be 1.6.

Yes21 commented 5 years ago

@RespawnDespair

@Yes21 could do this for this repository, i don't want to mingle here as well. I have the image builder to worry about for now smile

I just did it. Will see later how to add tasks ...

RespawnDespair commented 5 years ago

I have taken the liberty of adding some default columns and added my task with a reference to the image-builder project. Feel free to add more notes/issues.

bortek commented 5 years ago

I didn't there was projects tab on Git. This is excellent, we can then create cards here, no need for Trello. 👍

Yes21 commented 5 years ago

It seems that we can learn many things from each others. That's the good thing of collaboration or cocreation ! Look at the fantastic amount of work that has been done in one week ... That' GREAT :+1:

neurons9 commented 5 years ago

I have implemented the point 3 for myself. OSD with 3 screens on a rc channel, listening on SERVO_OUTPUT_RAW ( #36 ). I do not know where I could commit the changed code. Furthermore, I have created a fancier icon font ... img_9207

Yes21 commented 5 years ago

@zenuavsolutions Welcome to you ! and thanks for sharing ... We need contributors for this project.

You could create a pull request here, but you should firstly coordinate your efforts with @careyer , because he already has code for the same function ...

Ps : Your ground station seems awsome !! Could you tell us more about it ?

careyer commented 5 years ago

@zenuavsolutions : Your GCS looks awesome. Indeed the changes from dino.de already include "Ground Switches" and "AirSwitches".

With "GroundSwitches" you can trigger arbitrary functions at the GCS. (what is best: it does not occupy any precious RC-Channel because it can read switches from e.g. Taranis that are not assined to a RC-function - Taranis has up to 32 switches ;-). What can you do with that?

With "AirSwitches" you can either drive GPIOs at the AirPi (hardware actions) or trigger e.g. a script (software actions). Again this does not occupy any precious RC-Channels ;-)

Can you contribute some information about your GCS to the wiki maybe? What can be very interesting though is how your 2nd and 3rd OSD screen looks like. do you have a radar map or something like this?

P.S: Nice Kopter die du da baust ;-)

Yes21 commented 5 years ago

Should I add these to items as 1.6 new features :

? (@RespawnDespair did already add them on his todo list for 1.6)

careyer commented 5 years ago

@All : Okay guys! We are approching (with big steps) our first stable wifibroadcast-image-builder generated "official build". Thank you for everybody who is working and testing hard on this!!! You guys rock!

Once we have this stable build we should agree on a concept on how to handle further AddOns/Improvements

I have long time been thinking about this and lets face it: Over time more and more AddOns/Improvements are going to come and while some might happily live in co-exitance with each other, others might not be compatbile with one another. So we need to find a way to allow for that.

Here is my suggestion: First we need to categorize these Improvmentes and I suggest two categories here: "Core" and "Addon".

Core: These Improvements should be part of any EZ-WBC build since they add basic/core functionality. Examples are:

Addon: These are functionalities that enhance the core product by special functions that might not be used or wanted by everybody. This can have various reasons:

  1. The user might not be interested in it (no usecase)
  2. the user might not have the mandatory hardware (e.g. FLIR or 4Camera-Switcher);
  3. or one AddOn might be incompatible with the other (e.g AirSwitches and 4Camera-Switcher, both make use of the limited Air GPIOs).

Examples for AddOns are:

For the Addons we should agree on a concept how to let the user choose which functionalities he wants to use. This can either be done with software switches in the wifibroadcast_1.txt config file, e.g. FLIR=N AIRSWITCHES=Y 4CAM-SWICTHER=N WEBCAM=Y

or we could add command line options for the build.sh script by @RespawnDespair . With those command line options the user would be able to choose which addons are compiled into the image, e.g.

./build.sh -AIRSWITCHES -WEBCAM

Any opinions/thoughts on this are welcome! What is your favourite conecpt?

Yes21 commented 5 years ago

@careyer : I agree with your proposition. When I read your "Addons" idea, I'm thinking of the "Plugins" idea of @seeul8er ! I'm almost sure that it's the best way to implement new features that are not involved to be implemented in "Core" ... I'm sad that @seeul8er is working alone on his side, but he's doing great progresses. I'm sure he has a little advance before us in term of concept (except for your image building script ...).

RespawnDespair commented 5 years ago

@ALL The first stable image appears in sight yes, lots of testing and fixing to do, but now i feel closer than ever. I agree we need to rearrange things moving towards the future. Dronebridge does things nicely, although i'm under the impression the plugins there are LUA or Python script only?

For EZ-WFB we need to redesign from the ground up for 1.7, this might seem dramatic, but it really isn't. Right now the code is a bit messy, lot's of features have been implemented by different people in different code styles. Some basic cleanup is needed, change all naming to air/gnd to avoid confusion. Perhaps move to system.d instead of the scripting/tty solution we have now.

Once the basics of this rewrite is done (really, don't be scared, i'm not overcomplicating things) moving forward will be easier. The architecture can be made so it will be possible to have everything in the base image and then easily switch things on and off by config.

Although i've made the image-builder script as easy as possible i still feel it's something 'for us' to create 'offical' images and for advanced users to contribute to the project. So compile flags and the likes would probably alienate a lot of users. The config route as mentioned by @careyer has my absolute preference.

Some of you might know, but i am a software architect by trade, my background is not in Linux/C, but some concepts of my job and experience are not related to OS or programming language. I would like to use my experience to draft a proposal (with the help of the core users here on GitHub) where we can iron out the architecture and flexibility we want to achieve moving forward with this project.

If the above comes across as me bragging, i apologize, this is not my intent, i'm also not hijacking the project, i just want to take a very active role in getting the technical aspects of this project on the right rack so it is possible to maintain quality and concistency while having multiple people contribute.

pilotnbr1 commented 5 years ago

@RespawnDespair you are exactly what what this project needs! The code needs to at least be organized and cleaned up so it’s at least maintainable. Then second big priority is to make it approachable to new devs where it can be expanded upon and improved. You are right that Wolfgang did a lot of things right with Dronebridge, I wish he would have organized wbc with a library before he went off in his own direction. I believe you are right that it is python with dronebridge.

Ideally things would be open enough where ppl can build plugins easily AND contribute that code back to the project so that others can easily use it. Basically plugins that play well with others plugins. What we want to avoid is ppl creating one-off images (they needed a plug in option) that are only good for their one unique application and not compatible with other users code.

Thanks for all your hard work! It’s exciting to watch it come together!

careyer commented 5 years ago

+1 for what Luke just said. @RespawnDespair : AWESOME WORK!!! I am happy to hear that you liked my idea and thoughts. We surely must reorganize things a little. Every smart thoughts that we put into the design now will serve us well in the near future and help getting the project to grow and stay maintainable.

Von meinem iPhone gesendet

Am 02.11.2018 um 00:43 schrieb Luke notifications@github.com:

@RespawnDespair you are exactly what what this project needs! The code needs to at least be organized and cleaned up so it’s at least maintainable. Then second big priority is to make it approachable to new devs where it can be expanded upon and improved. You are right that Wolfgang did a lot of things right with Dronebridge, I wish he would have organized wbc with a library before he went off in his own direction. I believe you are right that it is python with dronebridge.

Ideally things would be open enough where ppl can build plugins easily AND contribute that code back to the project so that others can easily use it. Basically plugins that play well with others plugins. What we want to avoid is ppl creating one-off images (they needed a plug in option) that are only good for their one unique application and not compatible with other users code.

Thanks for all your hard work! It’s exciting to watch it come together!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

bortek commented 5 years ago

Very good proposal careyer and good idea with restructuring of the code RespawnDespair, this is indeed necessarily.

Regarding addonns I personally would prefer option1 for switching on/off the addonn. From user perspective this is mich easier than keeping editing ling command line. Moreover having some sort of gui where users klick and bock on/off the features which result in a downloadable file (with all options) that than just need to be copied to boot partition. It's an extra component to maintain, but perhaps makes a life of non advanced user easier. Something to consider inntge future.

@yes21 feel free to do update task list with ideas from this discussion.

If we can benefit by moving some startup scripts to systemd then yes. This would at least be cleaner and more aligned with modern way of doing things.

pilotnbr1 commented 5 years ago

Getting off on a tangent but I remembered everything used to be systemd and then when Rodizio switched it to .profile. A quick search revealed this quote from Rodizio

“I deliberately put everything into .profile because it allows to easily have everything running in the foreground (on the different ttys) and everything is in one place. With systemd, a lot of different services would run in the background and everything is cluttered over many scripts which have many redundant parts and are hard to maintain and keep in sync.

The other reason is, I think for our purposes, systemd (and a full linux distribution like Raspbian) is just unnecessary bloat. Rangarid has already started a buildroot image for wifibroadcast, there we don't need all this systemd and init stuff. We can just run everything from inittab for example, without the need for systemd or a system-v style init system at all.”

personally I found systemd easier (maybe because that’s what I was used to). I think the difference was really just a preference for Rodizio and had little to do with performance and reliability.

RespawnDespair commented 5 years ago

@pilotnbr1 I remember also, i agree with his explanation, not with the current implementation. The .profile script is a hardly readable goliath. Separating it into separate scripts is not much better (as i have done). When implemented properly system.d will make things easier to understand, not more difficult.

As to using buildroot, this was what i did before doing the image-builder. The downside at the time was that it targets exactly 1 architecture. You'd have different images for Pi0, Pi2, Pi3 etc. At the time we wanted a 'one size fits all' image. Maybe in the future we will reconsider and make platform specific images. For myself i have more insight into what actually 'makes' EZ-WFB work, so revisiting the buildroot might be possible.

As we gather more people in the project with specific experience (you yourself seem very knowledgeable in regards to Linux) we open possibilities to redesign parts of the system. Rodizio ran this as a one-man-show and he did an amazing job, but i feel the project needs the input and experience of more than one person to truly deliver on its promise.

I'd love to get together (virtually) with the core group and discuss such subjects...

rodizio1 commented 5 years ago

Regarding the version: I'd strongly vote against calling it 1.6. This would not reflect the actual development. "Release candidate" means something like "almost done/final", usually the last release before a final release. Between RC and final there should be only small changes like cosmetic fixes or small bugfixes.

The roadmap however shows that the release is based on a not much tested image builder which still seems to have many issues and there is a completely new Raspbian release as well as completely new Kernel and Raspberry firmware being used. These are very large and major changes, that should be released as 1.7beta1 or something like that first, then later as 1.7 final.

Regarding systemd: It won't make things simpler, it will make them more complex because it's an additional piece of software. After all, systemd is (among other things) a daemon for starting programs/daemons, the bash script code would still be there, just with the difference that the .profile would be split into several different scripts that would be run by systemd. Like RespawnDespair has already noticed, splitting the .profile script into seperate scripts doesn't really simplify things, and with the additional systemd configuration required it will get even more complex.

Also (like I have already mentioned), systemd is just unnecessary bloat for our application. We don't need to start a lot of different daemons and also we don't need all the additional functionality (like logging for example) it provides. It just adds complexity, adds another dependency (i.e. another piece of software that can have bugs, that can change it's behaviour in unintended ways for our application, can break our application due to syntax/config changes, will make it less portable to other systems, etc. etc).

What's also not nice about it is, that some functionality cannot be easily and cleanly (or not at all) disabled, I remember disabling logging and other stuff was a pain, I had to delete stuff because it couldn't be cleanly disabled. Another issue with systemd is: It causes a long delay (5 or more seconds) on the Pi1/0 right before the login screen for some reason, without systemd, bootup would be much faster on a Pi1/0.

In short: Really, don't use it.

RespawnDespair commented 5 years ago

@rodizio1 I'd love to chat with you on this subject. The massive/lengthy .profile script is also difficult to understand and maintain. I thought splitting it would make it easier, but no... I remember you wanting to strip al unneeded things from the image (buildroot is still an option) so yes, system.d would be a bloat... We need to come up with something that is readable, maintainable and fast...

Edit: Also yes, using 1.6 might just add to the already exisiting confusion. 1.7 Beta might be better.

rodizio1 commented 5 years ago

Yeah, chat might be a good idea. Do you have something setup already?

RespawnDespair commented 5 years ago

I just made a gitter chatroom, never tried this before: https://gitter.im/EZ-Wifibroadcast/Lobby?utm_source=share-link&utm_medium=link&utm_campaign=share-link

Yes21 commented 5 years ago

@rodizio1

I'd strongly vote against calling it 1.6. This would not reflect the actual development. "Release candidate" means something like "almost done/final", usually the last release before a final release. Between RC and final there should be only small changes like cosmetic fixes or small bugfixes.

My first propositions were here.

But the majority did choose 1.6 ...

If you accept that 1.6 will never exist, so I vote for 1.7 (with betas before stable).

RespawnDespair commented 5 years ago

I think 1.7 would be better, or to completely separate the efforts 2.0 even. With beta-1 as the first official release. We changed the kernel, drivers, code, almost everything is different from 1.6RC6...

careyer commented 5 years ago

Yes, Rodizios' considerations are absolutely legit. 1.7b1 or 2.0b1 would be more appropriate.

Von meinem iPhone gesendet

Am 04.11.2018 um 15:26 schrieb Jelle Tigchelaar notifications@github.com:

I think 1.7 would be better, or to completely separate the efforts 2.0 even. With beta-1 as the first official release. We changed the kernel, drivers, code, almost everything is different from 1.6RC6...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Yes21 commented 5 years ago

I'm now for 2.0beta1, because that's now a new life cycle for EZ-WBC !

Yes21 commented 5 years ago

@ALL What's your choice between 1.7(beta1) and 2.0(beta1) ?

bortek commented 5 years ago

It's not that important if you ask me but if I would choose between the options you listed I would select 2.0b1 since there are so many changes going on right now. We were trying to build what was supposed to be 1.6RC6 but will end up a lot further :) ....when we have it stable.

careyer commented 5 years ago

+1 2.0b1

Am 05.11.2018 um 20:43 schrieb Bortek notifications@github.com:

It's not that important if you ask me but if I would choose between the options you listed I would select 2.0b1 since there are so many changes going on right now. We were trying to build what was supposed to be 1.6RC6 but will end up a lot further :) ....when we have it stable.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bortek/EZ-WifiBroadcast/issues/163#issuecomment-436009056, or mute the thread https://github.com/notifications/unsubscribe-auth/AF3v29lKw5PS6JPHYJUHxAwFecY8KHJpks5usJTEgaJpZM4XkDok.

Yes21 commented 5 years ago

Ok, let's go for 2.0 beta1 Thanks