Yeah I have seen a few videos on youtube with programs with voice control. Im just contemplating whether use a learning system as there will be only a few commands, excluding the controlling of the music side, to get a much more accurate system, and do this for a few users if possible. Or I have seen a few which dont really need the learning system but still seem to be pretty good depending on the mic you use. I dont like the windows voice recognition at all. Was definitely gonna use an alternative.
The rationale for AMB is simple. When you develop a platform for developers, you don't want them to have to learn weird standards like OBD2/ELM327 or the plethora of CAN protocols that are different from vehicle to vehicle. You want them to only have to learn one API and not to have to care about what vehicle their app is running in, the underlying network details, etc. AMB makes the underlying hardware and protocol differences opaque to the developer. He doesn't have to care if it's OBD2, an arduino, CAN, OpenXC or anything else. He just writes his app to the AMB API and he's done.
The challenge will be for the automaker or hardware integrator. He'll have to setup AMB in such a way that it just works.
Former author of LinuxICE, nghost, nobdy.
Current author of Automotive Message Broker (AMB).
Works on Tizen IVI. Does not represent anyone or anything but himself.
Last edited by UnusuallyGenius; 08-22-2013 at 02:18 PM.
this is promising. I suggest not going with the pi as that board is limited for the money. maybe look into the pcduino that is morepowerful and can easily interface with arduino ide (anaolg inputs is a plus) and would open the scope of what you're doing by having readily available libraries and a huge community.
Maybe I'm in the minority, but I beg to differ.
A big majority of what has been listed is already offered even in a Kia (no offense to Kia, I'm just comparing to luxury makes like BMW, Mercedes, Audi etc). Just what are we trying to achieve??
Reviving this thread looking for an update. I got tied up with my classes and life and forgot about this thread. I am going to make a new thread about this but I want to get with tripzero about his framework and find out what is going on with BennY.
After months of thinking about stuff I have decided to start coding a new system. I will go into more details in another thread but in short I want to make a high level Vehicle Bus Communicator. What I will be building will start out as windows based and written in C# and .NET . When done I will look at integrating it for Linux using Mono and for Android using a different setup. Maybe Dot42 or something similar. Under windows it will basically show the car as a device addressable by a software package that recognizes it.
In essence the idea is to build a system that won't care where the data is coming from but will allow a programmer to use a simple program to get all of the information it wants. The system will take care of handling if the communication is a ODBII or an ODBI or a totally custom system. Basically once a plugin has been made this system will be able to take advantage of it. I am calling this OpenVBUS for Open Vehicle Bus. So in my truck I can use ODBII and access pretty much everything in the truck. In my older ODBI car I could add the same controls with additional hardware added. This software won't care and you will be able to upgrade vehicles that don't have the support currently and be able to include a new driver and away you go.
I like that you guys aren't trying to reinvent the wheel (honestly no pun intended) too much. At the beginning of the thread it seemed like you might be going that direction and failing under the incredible scale of the project. However it seems you've done well to tie in some of the important aspects with already established projects. And by enabling people to create their own profiles with a simplified scripting language for their specific vehicle, you'll offload a lot of the work (that you would be unable to do anyway without access to the car) that needs to be done to reach that "universal" goal.
I'm interested to see where this goes. Might even be able to help.
anyone who has an raspberry, and a iOS/Android 4+ Device, and wants to test some stuff in a few weeks, should mail me following details:
about the smartphone/tablet:
manufactor/model (cpu speed, display size/resolution, memory size, system version (like android 4.2 or iOS7), connectivity like bt/wlan/gps)
about the pi:
hardware revision (a, b, b+)
connected IOs (and what is connected)
available usb devices (Spacenavigator/Powermate/WiFi/Bluetooth/sound-card/etc...)
requirements, as i have limited time, you have to know how to:
get the image to the sdcard with dd
get logfiles from pi to pc and upload them
not necessary but would be great and help a lot is:
remote ssh access to the pi to check problems out (no teamviewer!, just ssh as i have limited bandwidth, you can use the screen-tool to watch whats happening)
some ethernet/wlan bridge for the pi. could be just some old accesspoint.
i may get my pi next week, so i can start to create the image. (if you have good ideas what has to be in the image, just mail me, distribution isn't choosen yet, but i will try gentoo first)
Last edited by BennY-; 07-23-2014 at 02:06 PM.