Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Open Source Software Transportation Linux

Automotive Grade Linux Released For Open Source Cars 88

Mcusanelli writes: The Linux Foundation and its partners have released the first version of Automotive Grade Linux, the open source platform for use inside connected cars. "AGL is building the industry’s only fully open automotive platform, allowing automakers to leverage a growing software stack based on Linux while retaining the ability to create their own branded user experience. Standardizing on a single platform means the industry can rapidly innovate where it counts to create a safe and reliable connected car experience. Open collaboration within the AGL community means support for multi-architectures and features to bolster the in-vehicle infotainment (IVI) experience." Further details and source code are available from the official website.
This discussion has been archived. No new comments can be posted.

Automotive Grade Linux Released For Open Source Cars

Comments Filter:
  • Is that (Score:1, Offtopic)

    by funwithBSD ( 245349 )

    5w-30?

    Dino or synth?

  • by backslashdot ( 95548 ) on Tuesday July 01, 2014 @02:39PM (#47362955)

    Without usable voice control, this thing is useless. And the only way to make voice control work non-annoyingly is if someone like Google open sources their Google Now speech to text stuff and put the needed patents into the public domain.

    • Or google will grab the source and spin off a new version of Android just for the car makers, including the voice recognition bits, mapping, etc.

      • Or google will grab the source and spin off a new version of Android just for the car makers, including the voice recognition bits, mapping, etc.

        Oh no, they've never done something like that before....

        Next you will tell me that they will sue because their reference design car has rounded corners... Never!

    • by Anonymous Coward

      Or you can spend a few years studying voice recognition technology, write the software and open source it yourself.

    • by aitikin ( 909209 )
      Or someone pays for a license for speech to text implementations. Just because it's Linux, doesn't mean there can't be commercial software on it, commercial licenses available, etc. The kernel should not have non-open source code in it (although, there's ways around this ala nVidia drivers), but other than that, why would it matter that Linux doesn't have open sourced speech to text and patents aren't in the public domain?
      • by zwede ( 1478355 )

        Or someone pays for a license for speech to text implementations. Just because it's Linux, doesn't mean there can't be commercial software on it, commercial licenses available, etc.

        This is what Tesla did. They run Linux (although it's their own, Debian based, flavor) and they licensed voice recognition (Googles, I think). It works really, really well. I have a slight accent and it still gets it right every time.

    • So because an operating system doesn't have voice control, it's useless?
      What part of retaining the ability to create their own branded user experience and Standardizing on a single platform means did you not understand?

      Voice control is at the user experience layer. Unless you expect the Linux community to implement voice control software for every language in the world?
      Cars aren't just sold in English speaking countries, btw.

      Now.. if only I could put Linux on my Japanese import car's navigation system...

    • Without usable voice control, this thing is useless. And the only way to make voice control work non-annoyingly is if someone like Google open sources their Google Now speech to text stuff and put the needed patents into the public domain.

      Then scratch the itch and add the missing piece yourself. Open source should not be about us passively waiting for someone else to always do the hard work so we can just grab the source and run away with it. I see this kind of mentality a lot these days. Suddenly we are not part of the open source community ourselves, but the community is some external creature, a code mill from which we can demand various things. Learn C or C++. Learn how speech recognition works. Begin coding and contributing.

      • I was wondering when that old chestnut would pop-up. Not everyone has the mindset to be a programmer, let alone the time. You're inviting a lot of half assed code to be rejected from the base line if you expect people to just "learn c or c++" then start contributing to a project that probably at least requires knowledge at CS level. This would create an extra burden on any project.

        Believe it or not, some people (actually, most people) just want to buy their device.

  • at least I can compile my own updates as after 1 year the car maker has moved on next years cars and the old one software is left to rot.

    • I'd bet any automaker would end up wtih binary blobs, much like NVidia and their non-open drivers. Which means that yes, you may be able to recompile the kernel, but getting the binary blobs to work may not be so doable...

      Of course, then you have to get your kernel onto the device and get it to boot... sorta like the Tivo issue.

  • by Anonymous Coward on Tuesday July 01, 2014 @02:41PM (#47362971)

    I was editing a config file with VI.

  • by fastgriz ( 1052034 ) on Tuesday July 01, 2014 @02:44PM (#47362999)
    I want an open source platform that doesn't have to be "jail broken" to make it work the way I desire and get rid of the bullshit that marketing snakes decided to inflict upon me.
    • by Selur ( 2745445 )

      needs to be branded and at least partially closed otherwise where should all the code from the NSA go?

    • I want an open source platform that doesn't have to be "jail broken" to make it work the way I desire

      Inspections.

      Insurance.

      Civil and criminal liability.

      The worst that can happen with a jail broken phone is that you will brick it.

      • The worst thing that can happen to an infotainment system is it can mess with the CAN bus...
        If it's a malfunction, all that's going to happen is the car goes in to 'limp home' mode because the other systems can't communicate on the bus.

        If it's malicious, that's another story... [google.co.nz]

      • by AmiMoJo ( 196126 ) *

        This seems to be aimed at infotainment (god I hate that word) systems, rather than the embedded systems that are safety critical.

    • Yup. Them with the "incredible thinking" and the "incredible ideas". You keep using that word. I do not think it means what you think it means.
  • Noooo! (Score:5, Funny)

    by Charliemopps ( 1157495 ) on Tuesday July 01, 2014 @03:06PM (#47363215)

    yum install Brakes-1.10.1-1.1.i386.rpm
    Setting up Install Process
    Parsing package install arguments
    Examining Brakes-1.10.1-1.1.i386.rpm: Brakes-1.10.1-1.1.i386
    Marking Brakes-1.10.1-1.1.i386.rpm to be installed
    Resolving Dependencies
    --> Running transaction check
    ---> Package Brakes.i386 0:1.10.1-1.1 set to be updated
    --> Processing Dependency: Brake_fluid for package: Brakes
    --> Finished Dependency Resolution
    Brakes-1.10.1-1.1.i386 from Brakes-1.10.1-1.1.i386.rpm has depsolving problems
    --> Missing Dependency: Brake_fluid is needed by package Brakes-1.10.1-1.1.i386 (Brakes-1.10.1-1.1.i386.rpm)

    yum install Brake_fluid-1.0.2-5.el5_6.1.i386.rpm
    Setting up Install Process
    Parsing package install arguments
    Examining Brake_fluid-1.0.2-5.el5_6.1.i386.rpm: 1:Brake_fluid-1.0.2-5.el5_6.1.i386
    Marking Brake_fluid-1.0.2-5.el5_6.1.i386.rpm to be installed
    Resolving Dependencies
    --> Running transaction check
    ---> Package Brake_fluid.i386 1:1.0.2-5.el5_6.1 set to be updated
    --> Processing Dependency: /usr/sbin/GM_ASEP_CERT for package: Brake_fluid
    --> Finished Dependency Resolution
    1:Brake_fluid-1.0.2-5.el5_6.1.i386 from Brake_fluid-1.0.2-5.el5_6.1.i386.rpm has depsolving problems
    --> Missing Dependency: /usr/sbin/GM_ASEP_CERT is needed by package 1:Brake_fluid-1.0.2-5.el5_6.1.i386 (Brake_fluid-1.0.2-5.el5_6.1.i386.rpm)

    • Should have used Debian.

      • Ah, but Debian has old software not that bleeding edge new versions of stuff so no disc brakes, only drums

        # apt-get install disc-brakes
        E: Unable to locate package

        # apt-cache search brakes
        drum-brakes - A working automotive brake system although may experience fade as it heats up, recommended for advanced users only
        drum-brakes-resurface - A utility to resurface the drums in an automotive brake system :)

        • Ah, but Debian has old software not that bleeding edge new versions of stuff so no disc brakes, only drums

          Disc brakes are far from 'bleeding edge,' my 1979 Malibu had them.

    • You failed to mention the other dependencies...

      Rotors, Calipers, pads, axle, lugs, peddle, Master Cylinder, fluid reservoir, brake lines (both hard and flexible), brake-lights (that includes the light holders, bulbs, wiring and switch), ABS (which has it's own dependency tree that includes: Basic Brakes, sensors, sensor wiring, sensor interface, pump, pump wiring, pump interface, device drivers for sensor interface and pump interface and ABS software package)

      Ok.. I'll stop now.... That I have a modern bak

    • Just be sure you don't install the Lockheed fluid package into your Girling brakes app; it will lock-up. Literally.
  • Please, people have enough of a time merely DRIVING their car, you can't expect them to recompile it as they hurtle down the highway at 75mph.

  • Yawn.

    I don't really care who supplies the back end to the 'infotainment system' in my vehicle, so long as it works as I expect it to.

    What I really want to see is someone create an open source OS for the vehicle itself, which would be rather useful in many off-road and kit car situations.

    Wake me when someone comes up with a Linux based ECU that lets users manage functions like fuel curves and TPS voltages.

    • The problem was with everyone developing their own proprietary system, by the time they get the vehicles to market it looks horrendously outdated compared to iOS and Android, to say nothing of trying to get developers interested. Standardizing around the same open platform will allow them to get their infotainment systems up to par and keep pace with the rest of the technology world. Not that it matters much for me and my car right now. I never imagined having a six-disc CD changer would seem so behind t
    • Why does your ECU need to run Linux? What's wrong with the dozens of already available aftermarket ECU's?
      Or even software from companies like Hondata that flash new programmable software on OEM ECU's

      • Why does your ECU need to run Linux?

        Well, it doesn't need to, it would just be neat. Open source and all that jazz.

        What's wrong with the dozens of already available aftermarket ECU's?

        Such as? The only one I've ever heard about was the MegaSquirt, and from what I can tell development stagnated a few years back. Are there others? Can you reference them?

        Or even software from companies like Hondata that flash new programmable software on OEM ECU's,

        Power programmers most definitely do not meet the criteria.

        Now, if you look at Hondata's website, the K-series Programmable ECU seems to be close to what I'm talking about... except the fact that it's not street legal and only works on Hondas.

        • Link, Motec, Haltech, Microtech, Chrome, Spoon, Gizzmo, AEM... Sorry, off the top of my head that's only another 8, not 12.

          No aftermarket ECU is going to be legal in places with strict emissions laws. I doubt even modified OEM ECU's would be legal.

          Of course Hondata only works with Honda's, its only programming hardware and software that runs on Honda ECU's.

  • As any Linux user can tell you, the problem's with the drivers.

  • The year of Linux on the dash-top is at hand.
  • Linux is just as crashy as Windows. Sure that means about a 100x decrease in frequency from the 90's, but it's still absurdly buggy and subject to the constant patch cycle bullshit. That said, it's fine as an isolated from the ECU / BCM as an infotainment system. Heck, it can even control the A/C for all I care as long as it never hooks as software into the ECU (a hotline to tell the ECU to engage the A/C clutch is fine).

    Let's keep automotive ECU systems in the stone age with assembly or occasionally QNX.
  • The manufacturers have universally produced garbage UI/UX thus far, this sounds like it'll just be perpetuated.
  • Excuse me while I recompile the kernel for an additional 50 horsepower!

It is better to live rich than to die rich. -- Samuel Johnson

Working...