Roadmap to 2.0 #93
Comments
|
I've copied this roadmap here, but we now have to adapt it to the new situation ... |
|
Yes we should, also, we should determine the goal again since we are now 'separate' from the main EZWFB project. |
|
The way I perceive all the images out there and moving forward- I feel that the strength of ez 1.6rc6 is its reliability. It is also nicely optimized perhaps the best optimized image for space and low cpu usage. But its not as full featured. OpenHD has some nice cutting edge features (app to set settings and sound) but it might have reliability issues. I havent played with it myself so dont really know. The russian image appears to be the first to offer more wifi adapter support and thus that hardware advantage may be its strength. Dronebridge has become its own animal in terms of heavy python usage, better coding practices, plugin ease, carving out a second pi uart, and a different approach to transferring data between pi. It does seem to also favor Inav FC. I have wondered why it is not more successful attracting users ( too different? Bad press from R?) There just isnt much activity or engagement from seeul8tr. The SVP image has a few nice features too. Encryption being one of the top of my head. All this to say I would hope we can take the best of all these images and make an ultimate image! I think highest priority is hardware support. Everyone is screaming for more adapter support. Support the newest pi. As for the rest of the stuff it would be interesting to make a poll and just ask the various user groups what they want most. Let the customer tell you your job. |
|
Well, that's my master plan:
Basically the best of everything, in the hopes the different projects will merge their efforts into one new project. The image builder would provide all projects with a way of easy upgrades to newer kernels etc. so that's why i see it as the base of it all. With the release of Ardupilot for F4 i see no reason to support other standards than mavlink, so that should reduce effort on that side. |
|
I agree.
What do all of you think about these questions ? |
|
Hey guys,
Just a little bit of info...
The open HD version appears to be working very well. I did have an
incident where I crashed but, I think it was the result of a loose camera
connection and somehow audio transmission was enabled on RPI zero causing a
runaway latency and maxed out CPU.
I have done as much ground testing as I possibly could with various setups
and the only bugs that I can find are as follows:
1. Communication app sometimes requires clicking save several times before
they are sent. (I believe this uses SVPCOMs code for the communication)
2. Raspberry Pi zero boat time seems a little longer than the regular image.
3. Open HD splash screen needs some optimization, some monitors it's half
cut off.
4. The Android app could use some optimizations, I would like to create a
dedicated app that is not mixed with an older version of fpvvr.
***OPEN HD also has the option to choose encrypted RC control. The RPI
zero uses a little more CPU from what I can tell but I am not able to
identify any reduction in control range or any other drawbacks.
Unfortunately we never got the 8812au chipsets to work with our image but
we didn't spend most of our time on that.
Other than the encrypted RC, the only other enhancements are the
synchronized communication program and the gpio trigger which should be
pretty simple ...
Unfortunately, USER1321 informed me that he is stepping away from
development for the foreseeable future. I think that a lot of the Fud and
"drama" with Ez on more than a few occasions and the seemingly endless
quest for bugs and optimizations could have had an impact on his motivation
to continue.
I believe he feels that the project has is is in a good spot and has
accomplished several milestones.
I'm sure he would be happy to provide info or help if you'd like to
integrate any of the open HD code.
It's unfortunate to see how things have split up lately, however the good
news is that every day new people are learning about EZ wifibroadcast and
engaging in the Forum.
I'm quite certain that next spring summer will bring a lot of exposure to
the project and all related branches
|
|
I will now try to answer to my own questions.
And now, let know what you are thinking of it ... |
|
Hey, that sounds good to me :)
I've always supported the idea of a new name just so it is clearly defined
as something "new". Open-HD can be used if you would like. As of right now
it is just a ISO image floating around in our Google Drive. if not that
name, any other name that does not have -"Ez-wifibroadcast" in the title
would be great. I promise, only positive things would come from it.
@Yes21, you have put countless hours into the 88xxAU support because they
are easily accessible. I'm impressed by your motivation and commitment to
that goal.
User 1321 has not really given up or disappeared permanently, I just think
he needed an extended break and needed to focus his efforts on commercial
projects and his livelihood.
The thing is, after nearly one year I am still intrigued by the
possibilities of this project. Probably because it represents RF freedom
and it is a "hack" that almost anybody can achieve.
On a side note, I think there are many interesting things that can be done
with various Wi-Fi card drivers, firmware and EEPROM... Yesterday I came
across this Forum and a thread that's a couple years old but it seems as if
they unlocked several additional features and channels on older Realtek
chipsets. Maybe this is irrelevant but, it seems like this guy (Sysvalo)
really knows his stuff with the wireless drivers.
https://xiaopan.co/forums/threads/unlocked-channels-tx-power-other-mods-for-atheros-intel-realtek.5359/
Let me know what you think...
…On Thu, Dec 6, 2018, 3:29 PM Yes21 ***@***.*** wrote:
@htcohio <https://github.com/htcohio> Happy to see you here again.
I'm sorry to know that @user1321 <https://github.com/user1321> decided to
give up.
The latest dramas did make too many "victims" !
Now we aren't so many, so let's go together ...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#93 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AcSp0lzjxdXIWPiyOGn8Jp0CeK8d4Ln5ks5u2X4sgaJpZM4ZBnLF>
.
|
|
Please don't use anything with "EZ" or "EZ-WifiBroadcast", that name is associated with the original project. |
|
@rodizio1 Agreed, that would only confuse things further. |
|
What is the 8812au status? AWUS1900AC Sseems fine for 5.8 . I've tried investigating 2.4 lost packets but got nowhere. I also could not get svpcom WBC to work in any consistent fashion. The udp stuff is kind of cool but doesnt really do anything any better than a pipe. I started looking at other boards that have hardware encoders. The new banana pi and odroid c2 look good; but we would need a lot of coding to take advantage of any latency reductions by sending lines of data from the camera rather than waiting on blocks to get filled. I just started working again after 6 years off; so my time is limited. |
|
@htcohio sorry to hear that about user1321. Between the two of you guys you were cranking out a lot of features and looked like you were having fun doing it! Thanks for offering the Open-HD name, it does have a nice sound to it. One thing that worries me a bit going forward with this project is that we might inadvertently cause more splits and side projects. If it’s not flexible enough, or enough features, or easy to use, someone with enough knowledge will fill that gap and start making more distribution images. We need to make it simple and easy for the average user to get the image they want but at the same time flexible and open enough to allow the experimenters to build off of the tools here. Bottom line is I would like to cause more of a consolidation of development talent here... |
|
I agree with Open.HD, even if I don't like it very much but ... We also need to change the logo ! |
|
@htcohio What was your latest version number for your Open HD ? |
|
@RespawnDespair @pilotnbr1 @htcohio |
@pilotnbr1,
@pilotnbr1, I believe things will work themselves out naturally over time... I think it all comes down to simplicity and active engagement with the community and newcomers. Everyone here and on RCG have been putting in the time to help others and contribute as best they can, if we just continue to do this, all projects/branches will grow. There is only so much "we" or anybody can control or influence unfortunately. :(
Are you saying you agree on a different name but think it should be something else? Did you have something else in mind maybe? As for the logo, cant wait to see your idea...
Open-HD V0_2_6_1
Sounds good, I am a "Hardware" person, I can't provide any opinion on it as I am not a programmer... Whatever you, Respawn, Pilotnbr1 think is best and most convenient sounds good to me. |
|
create an openhd github account, with google or yahoo email, also openhd@blah.com. That is better than an individual account and you can "transfer" ownership just by giving the new owner the passwords. |
|
|
Hey guys, a couple weeks ago I created an open HD Gmail account. I shared the login information through Telegram. I also have a website url www.open-hd.com It can be structured any way. Just PM me for the login for both if you would like. |
1 - Make RD's Image Builder script work to generate a working image. (@RespawnDespair / @user1321 / @pilotnbr1 / @Yes21 ) -- WIP --
The EZ-WBC code used to create this image is stored in RD's separated repositories link.
If something in these repositories is wrong or missing, it should be corrected in these repositories
until the generated image woks perfectly.(*@RespawnDespair / @user1321 / @pilotnbr1 / @Yes21 )
The news features of this first built image will be :
- done : new kernel( 4.14),
- done : support for RPI3B+ and RPI3A+
- done : Mavlink v2.3 support (up to 24Ch RC, solves a lot of the current v1 problems)
(@careyer/@dino.de)
- RC switchable AirPi-GPIOs (enables physical actions on the aircraft) (@careyer/@dino.de)
- RC switchable Ground Station actions. (e.g. switch OSD on/off, change between screens)
(@careyer/@dino.de)
- done : FLIRone Thermal Camera support. (@careyer/@dino.de/@pilotnbr1)
- done : support for rtl8812/14au (@Yes21/@RespawnDespair) link
- bug fixes: mavlink-routerd, gst-launch, hotspot, DHCP, GPIO pins used for custom profiles.
2 - Transfer the code used to generate this first image from RD's github/projects to ?
Give this branch the 2.0 number version, and make it the master branch.
Duplicate this branch to a dev branch where developers could add new features or bugfixes.
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)
Developers should submit their code and bugfixes to the dev branch,
and to the RD's dev script (if new packages or patches are needed).
Anybody can test the new features in building a dev image using the RD's dev script and the dev
code from dev branch.
When all is working and well tested, the definitive new image can be generated and published.
Then the dev branches of the code and the script can become master branches.
And so on ...
List of proposed new features :
GUI config (@htcohio/@user1321)
GPIO 4 camera switcher (@htcohio/@user1321)
display: total mAh, km, mins (@wowi69) link
OSD enhancements ? (@dposea) link
Compile flags/switches (@careyer/ ?) link
The text was updated successfully, but these errors were encountered: