Centralizing OpenAuto/etc Development Efforts

[WardBenjamin]

The Android Auto projects (OpenAuto, IntelligentAuto, Crankshaft, Headunit-Desktop, etc) have been picking up some steam again. @icecube45 and I have been talking about OpenAuto for the last week or two, and it's become increasingly apparent that the decentralization of these projects, and the decisions made by the original OpenAuto maintainer, have been causing some problems.

I brought this up with Emil Borconi (borconi, who has published some critical aasdk changes), Huan Truong (htruong, original/past OpenCarDev developer), and Marc Hillesheim (hawkeyexp, past OpenCarDev maintainer), and all of them have moved on to other projects or to commercializing Android Auto software, like Michael Szwaj did for OpenAuto Pro.

I'd like to loop in @rsjudka and @abraha2d, who seem to be the current developers and maintainers for these projects with the Intelligent Auto and OpenCarDev/Crankshaft projects for this discussion. I'd also like to loop in @icecube45 and @robert5974 who have been reasonably active around these projects recently

Here's a few links with some more details, for anyone who might later read this: https://www.reddit.com/r/crankshaft/comments/femw0q/openauto_extension_project_intelligentauto/

https://github.com/opencardev/aasdk/pull/6

What can be done? Right now, Crankshaft is broken and seems like it will be for the forseeable future. It seems silly to maintain that project when so much excellent work has been done for this fork. In my opinion, OpenAuto needs to have one active, authoritative place to submit pull requests, at the very least.

[robert5974]

I've had a similar thought and it's the most reasonable thing in the world. I'll help where I can, I don't currently code from scratch but I'm good at troubleshooting and design. I look forward to the collaboration on headunit sw

[rsjudka]

Well to be honest I don't know much about the other projects that exist... but I can definitely see how there are a bunch of different features added to aasdk/OpenAuto that just go missing over time.

My philosophy when starting this project was to only use aasdk/OpenAuto as libraries, which seems to be a different approach than what others have been doing (I really only left the UI pieces in my fork for completeness, I don't use them at all). Maybe that's the approach we should be taking? That way anyone who wants to use the core of OpenAuto doesn't pull in whatever non-AA features get added.

I wouldn't mind maintaining whatever common repo is decided on, I have no plans on monetizing this hah

[abraha2d]

My philosophy when starting this project was to only use aasdk/OpenAuto as libraries... That way anyone who wants to use the core of OpenAuto doesn't pull in whatever non-AA features get added.

I definitely agree with this sentiment. Modularity is a very good thing.

I'd be interested in helping out. I haven't really done much work with crankshaft/openauto in general, other than apply some fixes and use it, but recently I have been trying to dig deeper and understand how the whole thing works.

[rsjudka]

@abraha2d have you used this project at all? If so, is there anything in crankshaft that should be ported into this project? I get the feeling that the wiki for crankshaft is a bit outdated so its really hard to gauge all that features it currently has.

One thing that a lot of people have been asking for from this project is to incorporate it into a single image, like crankshaft, so they can just load it on their pi and run it. How feasible do you think that is? I haven't really done anything like that before but it seems to be a bit "bloated" (at least how crankshaft does it).

[abraha2d]

I compiled and ran this project yesterday on a semi-fresh install of Raspbian Buster, but haven't had much time to play around with it. Off the top of my head, one thing that Crankshaft has that's pretty useful is the ability to connect over WiFi (using the AA developer head unit server on the phone). But I see you're planning on adding that, so that's that.

On the "single image" idea: I think it might be better to set up an apt repository, so people can start with a Raspbian install and add the android auto components on top. Maybe one package for just openauto/intelligent-auto, and another for handling all the system integration (change splash screen, set openauto to start on boot, etc etc).

[robert5974]

That could be a way to go. I've been recording the steps to get this working on a Raspbian lite image. If interested I'll share that with you.

[WardBenjamin]

I've been recording the steps to get this working

I'd definitely be interested in this; clear instructions are also something we should maintain. I'll be installing IntelligentAuto (with Cole's fixes) in the next day or two and seeing how it compares to the OpenAuto/Crankshaft bastardization I had working a few months ago when I last tried this.... I'll try to keep a list of everything that I do as well.

I think it might be better to set up an apt repository

I agree with Kevin - maintaining at least OpenAuto and AASDK as a .deb package would be a solid way to tie everything together, and it's a lot less hassle than maintaining a whole image like Crankshaft does. I'm not sure how well the system integration package would work out, but it's definitely worth a try.

I wouldn't mind maintaining whatever common repo is decided on

With your and @abraha2d's blessing, I'd like to go ahead and get everything moved over into a new organization - let me know if you think maintaining OpenCarDev is the way to go, but a clean-ish break from the Crankshaft project is the better route, in my opinion.

With that done, the OpenCarDev/Crankshaft OpenAuto/AASDK forks can either be retargeted to the new repository, or the old repository can have a new default branch with only a note pointing to the new repository, so that they can be condensed without removing any code. Unfortunately, there's nothing to be done with Szwaj's original repository, other than maybe opening a "PR."

[rsjudka]

I think it might be better to set up an apt repository

Maybe we start simple and just do releases... then we can work out how we build the aasdk/OpenAuto libraries (im thinking maybe as dynamic libraries) so that way the apt repository can include the entire project while also allowing other applications to link in aasdk/OpenAuto.

If we were to start with the releases, I figure we would have the following flavors: aasdk

• x64
• arm

OpenAuto

• x64
• arm
• arm w/ omx (really only for the raspberry pi)

IntelligentAuto

• x64
• arm

a clean-ish break from the Crankshaft project is the better route, in my opinion.

I agree, maybe this would be a good opportunity to come up with a better name for this project also :p

Unrelated, i think it would be cool if we could get rid of the raspberry pi specific stuff (basically the omx stuff) and instead use a hardware-accelerated qt video backend (not sure how easy this would be but would greatly simplify OpenAuto). So this would probs require a lot of effort lol

[WardBenjamin]

good opportunity to come up with a better name for this project also

My (very brief) foray into reverse-engineering the monstrosity that is OpenAuto was named Fusecast. That doesn't exactly provoke the "Android Auto" vibe, but maybe it doesn't need to.

get rid of the raspberry pi specific stuff

That would be nice... Here are some more or less useful related issue threads:

https://github.com/opencardev/crankshaft/issues/401 https://github.com/opencardev/crankshaft/issues/79 https://github.com/opencardev/crankshaft/issues/396

If we were to start with the releases, I figure we would have the following flavors:

I agree, this sounds like a good goal.

[rsjudka]

Fusecast

I dig it, or maybe even just fuse? I originally was calling the UI dash, maybe if we wanted to be closer to "Android Auto / Open Auto" we could go with openDash?

Here are some more or less useful related issue threads

Yeah I did figure there would be some interestest in using non-pi SBCs. If we're lucky, there might be working video backends supported by Qt that can do hardware acceleration. If not, I think we would want to rewrite the videoService to use something like openMax or openGl, which are more generic graphics libraries than the pi-only il client.

I guess we should figure out where a good break would be for \~release 1.0\~ and then work on updating the build process for that.

[jcwenger]

I've been digging into headunit/openauto/aasdk/crankshaft for the past couple weeks.

I've pulled a prebuild crankshaft image, put it in dev mode, installed enough apt packages to build, and have built aasdk/taglib/ilclient/openauto, from source. I've run the autoapp image out of that build. I've done some work on the cmake find_libraries and have fixes for some annoyances like system headers screaming warnings constantly ( array with zero subscript warnings, anyone? )

aasdk feels solid, but needs an active maintainer.

crankshaft I'm not sure about. It's a huge amount of scripting, but there are aspects of the philosophy I don't like. systemd dependency is good for getting going quickly, but I'm not sure about the boot speed. I'd made a buildroot based OS image and it boots fast but it's missing too much stuff Most of crankshaft's boot delay is spent standing up USB, so maybe that's unavoidable. But for the short term, staying with crankshaft as an OS framework as a starting point feels like it makes sense from a development speed perspective. There seem to be a huge amount of functions that are farmed out to systemd services. For exmaple, day/night setting is a systemd service call. Maybe good from the perspective of modularizing things like backlight brightness setting to get a clean API independent of board and BSP, but I have some performance misgivings of farming it out to shell scripting instead of code.

Trying to get from any of the existing projects to a true board-independent project scares the crap out of me. I see four developers up there and if there are four boards, there's a huge amount of abstraction layer work there. Getting from current state to a complete set of abstraction layer APIs will be very hard to do incrementally. Doing it as a big-bang replacement with four developers will be a difficult transition. Not saying it's wrong to do. Just hard. I like the idea of the OMX stuff being moved to a Qt Video Decoder subclass.

I also think it's time for f1x to come out of the namespace and directory structure.

I'm definitely interested in the project and I'm interested in aligning with a group of people who are moving together. I wonder about the idea of opening up a single project repo (named as a project and not as an individual developer) and assigning a couple maintainers to handle pull requests. If we have five developers, having a second set of eyes to look at a patchset and review prior to merge starts to make sense.

Thoughts?

[WardBenjamin]

Hey there @jcwenger, thanks for the thoughtful response, I agree with a lot of what you said.

I've been swamped over the last few weeks but I've been keeping up with reading issues, and I've been really impressed at the work @rsjudka has putting into these projects over that time. I expect to have some more time to put into IA/OA/AASDK/etc (a few hours a week, at least) in the near future once I'm finished with some of my obligations.

AASDK is not exactly an easy project to work with, and a big part of it is just the protocol buffer definitions which are unmaintainable. If Google chooses to break compatibility, the whole project goes down until someone can figure those out again. It definitely needs a maintainer.

I'm of the opinion that Crankshaft should be dropped. There's a lot of baggage there, and I feel like IntelligentAuto is slowly coming to feature parity with and overcoming the Crankshaft featureset. If people want to keep working on it than more power to them, but I do think the project is too platform-dependent, and the less shell scripting we can have the better.

Making IA and dependencies platform-independent is definitely going to be an issue. Raspberry Pi makes some things too easy, and relying on those is going to be a problem down the line for maintaining multiple platforms, even if they share a general architecture and distribution. Like you said, it's going to be hard, but I do think it should be a long-term goal of the project.

I agree that it's time for f1x to come out of the project as much as is reasonable. I've been in favor of having a single project repository, or at least an organization, to cover these projects - it's nice to keep at least AASDK separate such that people can use it for other projects, but if everything was merged it may help to reduce the maintenance burden.

@rsjudka re: naming - We probably don't want to conflict with other big projects, and FUSE is already more or less taken by Filesystem in Userspace. openDash is worth considering!

[jcwenger]

The biggest thing that concerns me with intelligentAudio is the dependency on X and other applications (bluez for pairing). Raw EGL feels like it should be able to get started up faster. Boot time, for me, is second most important after functionality.

The big question is whether Dash is the only application. If I'm wanting a Pi and touchscreen in my car and be able to run different apps, X makes sense. I start it up and select Dash as an application, one of many. But that's not the model I think I want. I want it to boot as rapidly as possible, and do one thing very well -- Which pushes me to a more embedded style, with EGL. That said, I don't have any data or comparisons on EGL startup vs X startup, just a feeling. In the same vein with embedded -- I think the huge amount of configurabilty in crankshaft is a huge negative. I don't want user-settable options for twelve different types of pairing, wiring, video, etc etc etc. Eight pages of settings menus is too many. All of that should be baked in at build time, not by the user at runtime.

AASDK -- Agreed. If google chooses to break compatibility, life is terrible. But. Having a maintainer won't fix that. Google will do what they do. AASDK is reverse engineered from a closed API and it's going to be brittle around updates. That's just the nature of the game. What can we do to mitigate that, other than having a centralized repo with several people who can share responsibility to accept pull requests? Agreed, we need to get into a better release cycle on that.

I'm hearing -- let me know if this is all your intent -- that the intention is to split the UI out of OpenAuto. Essentially, to use OA as the application framework, but to have the specific user interface be separate? If so, I have a feeling that flipping the concept and treating UI literally as a loadable plugin, is a model to consider.

[rsjudka]

have fixes for some annoyances like system headers screaming warnings constantly ( array with zero subscript warnings, anyone? )

You are a hero! Always told myself to fix it but never got around it it lol

I'm of the opinion that Crankshaft should be dropped

I agree. I've asked around and it doesn't seem like ia is missing any more major features from Crankshaft that people cared about. We'll still need to workout the system config tho since ia doesn't do any of that (and it shouldn't since its the application) but I think keeping Crankshaft out of this effort is the way to go.

The biggest thing that concerns me with intelligentAudio is the dependency on X and other applications (bluez for pairing)

I understand the sentiment here and I'm trying to remove dependencies for alot of the "external applications" (like use alsalib instead of calling amixer - i just got lazy here lol), but the 2 you mentioned seem to be more on the "required" side of things.

• bluez: this is the official Linux bluetooth stack and even qt uses it for the Linux backend. Is it just that you dont need to use bluetooth so dont care if its there or not? It seems easy enough to have features "enabled/disabled" depending on your system, but infinitely harder to reinvent the wheel and write your own bluetooth interface.
• x: now this one I kinda get, but at the end of the day arent you still going to need some sort of window system (unless you really want to go all out and handle all the input devices and what not)? I know Qt has their own for embedded Linux which can be configured to use openGl, but I'm wondering if the performance improvements will be worth it to replace x (with some googling it seems x takes about 1 second to launch). As with my other comment tho, the x dependency is something that can "disabled" if you dont want it in the application at all.

@jcwenger you've definitely made a lot of good points and would love to discuss further about your opinions and what I could do to help implement what you need in ia. Maybe this would be a good time to open up that slack channel i never got around to doing :p

the intention is to split the UI out of OpenAuto

Yes, and it basically is like that now. ia is not in OpenAuto at all, I've just left the original UI of OpenAuto in the repo because I wanted to minimize the changes I made to it.

[rsjudka]

https://join.slack.com/t/opendsh/shared_invite/zt-e4r2nqsk-yhOh8zx6v2qbAEItOad_KA

feel free to join, called it openDsh (openDash was taken on github lol) but we can always rename later

[matt2005]

I was just thinking why my fork of crankshaft had become the go to repo because I fixed a few issues. Is opendsh the new project? I've just spent a few months building a pipeline to build crankshaft and have just found this.

[rsjudka]

i wouldnt say opendsh is related to crankshaft really (well we did fork its aasdk and openauto repos but don't have any "crankshaft" elements in there) but i do believe it is one of the few actively developed car UI projects!

[matt2005]

i'm currently bringing the opencardev repos up to date based off my own repos. I'm thinking it might be a better approach to spend the time developing here. @rsjudka I really just don't want to waste my time and i just want to see a better project in the end.

[rsjudka]

if that includes the aasdk and openauto repos id be happy to get those changes too :)

unfortunately i cant say much about crankshaft, but we're pretty active over at the opnDsh slack channel!

[matt2005]

Looking at opendsh it looks pretty good. I'm working on a Prebuilt image so more people can start using it.

[matt2005]

@rsjudka the slack link no longer works is there a new one?

[icecube45]

Seems they expire every 30 days or so

https://join.slack.com/t/opendsh/shared_invite/zt-fcf38qpg-jjqFoP8v0z2tJJMYiteZHQ

@matt2005