otcshare / automotive-message-broker Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
License: Other
Internal testing (ambd -c /etc/ambd/examples/testsourceconfig -d5) fails with:
60.562 | Testing Core::setSupported...
**
testplugin.cpp:87:bool TestPlugin::testCoreSetSupported(): assertion failed: ((routingEngine->getPropertyInfo(TestProptertyName1, uuid()).isValid() == true))
Aborted
since this commit 7165af0 some performance tweaks to core and dbussignaller
automotive-message-broker-master/lib/listplusplus.h:30:85: error: parameter declared ‘auto’
return std::any_of(iteratable.begin(), iteratable.end(), [value, &comparator](auto i) { return comparator(value, i); });
CANBus Triple: https://github.com/CANBus-Triple/ is an open-hardware device that can read (and write) CAN bus messages. Comes with a standard OBD-type connector by default. The ability to read from it with AMB would be immensely valuable.
Some files are installed but not packaged into any rpm packages.
Because of this reason, below error occurs when building rpm packages.
[ 158s] error: Installed (but unpackaged) file(s) found:
[ 158s] /etc/init.d/ambd
[ 158s] /usr/lib/debug/usr/lib/libamb-json-protocol.so.debug
[ 158s] /usr/lib/libamb-json-protocol.so
[ 158s]
[ 158s]
[ 158s] RPM build errors:
[ 158s] Installed (but unpackaged) file(s) found:
[ 158s] /etc/init.d/ambd
[ 158s] /usr/lib/debug/usr/lib/libamb-json-protocol.so.debug
[ 158s] /usr/lib/libamb-json-protocol.so
IMO, this is definitely a bug and should be fixed.
Recently, I'm studying the "automotive-message-broker", the branch is 0.13, I can't find the define of "VehicleCommonDataType" in amb.in.fidl, the source code:
interface IgnitionTime : VehicleCommonDataType {
/*!
* \brief MUST return time at ignition on
*/
attribute UInt64 ignitionOnTime readonly
/*!
* \brief MUST return time at ignition off
*/
attribute UInt64 ignitionOffTime readonly
}
Can you tell me where the "VehicleCommonDataType" is define, and can you generate the code(Java or C++) from this fidl?
Currently support is missing for inertial measurement units (IMU). Roll/pitch/yaw data can be vital for offroad vehicles. In addition, IMU-provided orientation and velocity information has separate important use cases -- such as keeping the navigation map oriented correctly in the absence of GPS lock.
Generated c++ codes by json2amb use 'auto' specifier and this specifier requires '-std=c++14' or '-std=gnu++14' option for gcc. However, generated CMakeLists.txt has '-std=gnu++0x' option. Because of this reason, below errors occur.
/usr/local/include/amb/listplusplus.h:30:80: error: use of ‘auto’ in lambda parameter declaration only available with -std=c++14 or -std=gnu++14
return std::any_of(iteratable.begin(), iteratable.end(), [value, &comparator](auto i) { return comparator(value
^
/usr/local/include/amb/listplusplus.h: In function ‘bool contains(const T&, V)’:
/usr/local/include/amb/listplusplus.h:36:40: error: use of ‘auto’ in lambda parameter declaration only available with -std=c++14 or -std=gnu++14
return contains(iteratable, value, [](auto a, auto b) { return a == b; });
^
/usr/local/include/amb/listplusplus.h:36:48: error: use of ‘auto’ in lambda parameter declaration only available with -std=c++14 or -std=gnu++14
return contains(iteratable, value, [](auto a, auto b) { return a == b; });
make -j4 fails. but make -j1 works
Generated pkgconfig files(i.e. *.pc) have the wrong path as below.
Because of this reason, include files are not found when building AMB plugin module.
$ cat /usr/local/lib/pkgconfig/amb-plugins-common.pc
prefix=/usr/local
exec_prefix=${prefix}
libdir=lib
includedir=include/amb
Generated CMakeLists.txt by AmbSignalMapper is always install the shared object into fixed path (i.e. lib/automotive-message-broker) even though it is built for 64bits environment. This is mainly because generated CMakeLists.txt uses fixed installation path like that.
install(TARGETS ambtmpl_plugin LIBRARY DESTINATION "lib/automotive-message-broker")
virtual std::liststd::string sourcesForProperty(VehicleProperty::Property property) = 0;
ambd/core.cpp:
std::liststd::string Core::sourcesForProperty(VehicleProperty::Property property)
{
std::liststd::string l;
for(auto itr = mSources.begin(); itr != mSources.end(); itr++)
{
AbstractSource* src = *itr;
PropertyList s = src->supported();
if(ListPlusPlus<VehicleProperty::Property>(&s).contains(property))
{
l.push_back(src->uuid());
}
}
return l;
}
virtual std::liststd::string getSourcesForProperty(VehicleProperty::Property) = 0;
ambd/core.cpp:
std::list Core::getSourcesForProperty(VehicleProperty::Property property)
{
std::liststd::string list;
for(auto itr = mSources.begin(); itr != mSources.end(); itr++)
{
AbstractSource* src = *itr;
PropertyList supportedProperties = src->supported();
if(ListPlusPlus<VehicleProperty::Property>(&supportedProperties).contains(property))
{
list.push_back(src->uuid());
}
}
return list;
}
Sometimes we see NMEA protocol messages with GLONASS indicators. AMB should be capable of parsing GLONASS protocol messages... An example protocol message is shown below;
$GNRMC,073121.00,A,5544.7049,N,03743.7405,E,000.02626,301.4,190312,,,A*47
When running 'ambctl listen' command, below error occurs.
$ ambctl listen VehicleSpeed
File "/usr/local/bin/ambctl", line 567, in <module>
processCommand(args.command, args.commandArgs, False)
File "/usr/local/bin/ambctl", line 218, in processCommand
traceback.print_stack()
In order to generate plugin from JSON file, below error occurs when executing json2amb script.
$ json2amb -d SamsungCAN.json
Undefined subroutine &main::readFileContent called at /usr/local/bin/json2amb line 111.
In my opinion, that would be definitely a bug.
It would be useful to be able to send messages to discrete heads-up-display units (HUDs), like the Garmin HUD and Garmin HUD+. The former, at least, uses straightforward Bluetooth messages:
http://hackaday.com/2014/03/30/controlling-the-garmin-hud-with-bluetooth/
But it has several forms of output: nav data, speed, and several form of alert, so tying it directly into one application would not work. There appear to be at least a few other similar HUD manufacturers out there, to.
Debian packaging seems to be broken. It's at least missing compat file. I created one with "9" in it, but build still fails.
I'll try to fix this and possibly make a pull request. Tested on Ubuntu 14.10.
~/src/automotive-message-broker$ dpkg-buildpackage -rfakeroot -b
dpkg-buildpackage: source package automotive-message-broker
dpkg-buildpackage: source version 0.13.803
dpkg-buildpackage: source distribution utopic
dpkg-buildpackage: source changed by Kevron Rees <[email protected]>
dpkg-buildpackage: host architecture amd64
dpkg-source --before-build automotive-message-broker
dpkg-source: warning: unknown information field 'Version' in input data in package's section of control info file
dpkg-source: warning: unknown information field 'Version' in input data in package's section of control info file
dpkg-source: warning: unknown information field 'Version' in input data in package's section of control info file
dpkg-source: warning: unknown information field 'Version' in input data in package's section of control info file
dpkg-source: warning: unknown information field 'Version' in input data in package's section of control info file
dpkg-source: warning: unknown information field 'Version' in input data in package's section of control info file
dpkg-source: warning: unknown information field 'Version' in input data in package's section of control info file
fakeroot debian/rules clean
test -x debian/rules
rmdir obj-x86_64-linux-gnu
rmdir: failed to remove ‘obj-x86_64-linux-gnu’: No such file or directory
/usr/share/cdbs/1/rules/buildcore.mk:46: recipe for target 'cleanbuilddir' failed
make: [cleanbuilddir] Error 1 (ignored)
rm -f debian/stamp-makefile-build debian/stamp-makefile-install
/usr/bin/make -C obj-x86_64-linux-gnu -k clean
make[1]: *** obj-x86_64-linux-gnu: No such file or directory. Stop.
/usr/share/cdbs/1/class/makefile.mk:55: recipe for target 'makefile-clean' failed
make: [makefile-clean] Error 2 (ignored)
rm -rf obj-x86_64-linux-gnu
dh_clean
rm -f debian/*.debhelper.log
rm -f debian/files
find . \( \( -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
-o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
-o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
-o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} + \) -o \
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} + \) \)
rm -f *-stamp
debian/rules build
make: Nothing to be done for 'build'.
fakeroot debian/rules binary
make: Nothing to be done for 'binary'.
dpkg-genchanges -b >../automotive-message-broker_0.13.803_amd64.changes
dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute
dpkg-buildpackage: error: dpkg-genchanges gave error exit status 2
Plugins may need to report "no-value" for property when timeouts or other data losses occur. IVI software should be able to indicate that, for example, outside temperature sensor failed.
Current design doesn't allow setting of NULL because of static typecast in boost::any.
Even better way would be implementing something similar to Value-Time-Quality according to OPC (newer OPC UA) standard. It is proven by years of use in safety-critical projects.
Actually, OPC does something very similar to AMB and I, personally, would merge IEC 62541 OPC UA specs into our AMB implementation. Occam's razor. OPC UA has good binary and XML protocols. Data definition mechanisms are flexible enough to easily accommodate automotive concepts. OPC is designed to have high throughput and low latencies.
There is a hunt for open-source OPC UA implementation so AMB can get new contributors.
References:
[1] https://wikis.web.cern.ch/wikis/download/attachments/14778584/PVSS+usage+of+the+OPC+Item+Quality+Flag.pdf
[2] https://partners.iconics.com/%2FTech-Support%2FGENESIS64%2FGenesis64%2FApplication-Note%2FV10-7%2FICONICS-OPC-UA-Quality-Codes.aspx
[3] https://github.com/acplt/open62541/wiki/List-of-Open-Source-OPC-UA-Implementations
void Core::updateSupported(PropertyList added, PropertyList removed)
{
/// add the newly supported to master list
for(PropertyList::iterator itr = added.begin(); itr != added.end(); itr++)
{
if(ListPlusPlus<VehicleProperty::Property>(&added).contains(*itr))
{
mMasterPropertyList.push_back(*itr);
}
}
Should be there mMasterPropertyList instead of added ???
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.