Lessons learned can significantly help future R&I initiatives by providing key information on the results achieved. The table below summarises key lessons learned from national and EU-funded R&I projects.
|Type of lesson learned||Topic||Project name||Deliverable||Brief summary of the lesson learned|
|Financial||Procurement and availability of automation-ready vehicle platforms||MuCCA||MuCCA Project Website||Timely access to a suitable automation-ready vehicle platform has been challenging in the project. Ready to buy solutions are expensive and developing customised solutions within the project requires a lot of resources. Early access to a physical platform during development has proven convenient although simulation has helped on this side to bench test algorithms and part of the hardware|
|Legal & Regulations||Sharing video footage for research purposes should be made easier by providing EU-level practices and worked-examples||L3Pilot||Upcoming L3Pilot D5.2||The legal situation regarding sharing e.g. car front view video files between a research consortium’s partners seems to be a moving target with various views. Therefore, research projects would welcome EU-level practices and legal templates for sharing video from a vehicle within a research consortium, to speed up work and to avoid lengthy legal preparations and different interpretations. The current best practice might be to add video data sharing clauses to the consortium agreement, to reduce the need for bilateral agreements.|
|Technical|| -Automation in close distances|
-Automation in urban scenarios
-Automation in highway scenarios
|AdaptIVe||D1.0 Final Project Results|
|Lessons learned in bullet points in the deliverable.|
|Technical||Human vehicle integration||AdaptIVe|| D1.0 Final Project Results |
|The lessons learned related to Human vehicle integration are further elaborated upon and listed in Chapter 12.1 of AdaptIVe’s D1.0 Final Project results report.|
|Technical||Differences in technology maturity||ADAS&ME||ADAS & ME Final Report||Issues became apparent with differences in maturity of technology available during the testing stage concerning the original plans. Due to this ad-hoc solutions often needed to be developed within a short timeframe before the start of the evaluations (with the use of valuable time and resources detracting from the effective implementation of the evaluations). Improvement in the flexibility of the evaluation framework could have provided some other options.|
|Technical||Key issues with failure of demonstrator vehicles and integrated technology||ADAS&ME||ADAS & ME Final Report||When a demonstrator representative was not present issues often became difficult and time-consuming to resolve, and for integrated technology, issues were difficult without input from relevant partners. This caused numerous instances of delays and/or missed data collection. In response to this, it should have been mandated that a demonstrator representative was available at the evaluation site for the duration of the testing. Also provision of user manuals. |
|Technical||System language issues||ADAS&ME||ADAS & ME Final Report||During the development of both the sensing technology and the vehicle demonstrators, systems were developed with the partner language. This led to issues with the need to recruit participants in the test location with a native level in a foreign language. This was a limitation for the number test participants and on other recruitment criteria (i.e. representative gender balance, driving experience). Consideration should be given to the specification of the testing environment before the development to ensure that content could be tested with an optimal test procedure.|
|Technical||BuildingHigh-accuracy Positioning Solutions||AutoNet2030||D1.3 Public Final Report (Chapter 7.1)||Τhe implemented positioning technology is considered to be very well matching the positioning accuracy requirements of automated driving. Future efforts may include addressing issues related to overhead obstacles or urban canyons.|
|Technical||Building Human Machine Interaction/Interface (HMI) Applications for Connected Vehicles||AutoNet2030|| D1.3 Public Final Report |
|Challenges with the use of Head-up display. The results gave positive feedback on the applicability of an Android device for HMI purposes.|
|Technical||Distributed/semi-decentralized Control of Automated Vehicles||AutoNet2030||D1.3 Public Final Report (Chapter 7.1)||An iterative development framework is needed for distributed control. Cooperative control is highly dependent on perception and communication components.|
|Technical||Integrated Systems for Future Vehicle Automation||AutoNet2030||D1.3 Public Final Report (Chapter 7.1)||When working with standardized interfaces and isolated modules, one must focus on architectural questions and specifications of the interfaces very early in the project.|
|Technical||Perception Layer to Cope with Different Vehicle Platforms||AutoNet2030||D1.3 Public Final Report (Chapter 7.1)||Additional plausibility and consistency checks should be implemented in parallel to the perception in order to handle complexity and safe detection of potential failure states of the whole system.|
|Technical||V2X Communications for Cooperative Automation||AutoNet2030||D1.3 Public Final Report (Chapter 7.1)||Τhe use of tools for monitoring of experiments by means of V2X communication is highly beneficial. Such tools would need to be developed at an early stage of the project.|
|Technical||Extensive long term testing in live traffic||C-ITS Corridor||C-ITS Corridor Website||The gap between theory and the practical reality can only be narrowed by testing, testing and testing in live traffic between international partners. Intensive short term testing is great, extensive long term testing is indispensable in finding the real issues.|
|Technical||GLOSA speed advice||C-ITS Corridor||C-ITS Corridor Website||A maximum speed must be included in the advice speed calculation so that the in-car speed advice does not exceed the maximum speed. If this is missing, the speed advice should not be given. Time synchronization is also crucial for the service.|
|Technical||Hybrid Communication||C-ITS Corridor||C-ITS Corridor Website||ITS G5 and Cellular (short- and long-range communication) work well together. Thanks to the use of exactly the same data and the exact same format over ITS G5 and cellular, no serious integration problems arise in-car. The advantages of the one compared to the other are still not clear. More research will have to be conducted in a much more focused way using solid research questions and using international stable.|
|Technical||Test and validate in live traffic as much as possible||C-ITS Corridor||C-ITS Corridor Website||The learning curve is much steeper when testing developments in live traffic. You will find issues that will not show up in a lab or test circuit setting.|
|Technical||Human Machine Interaction/Interface (HMI)||InterCor||InterCor Final Reports||Human Machine Interface (HMI) design and position mounting influences user acceptance – better integration into vehicle is desirable (e.g. via Android Auto, Apple Car Play) to reduce driver distraction improve observation of warnings (e.g. option for audible warning useful). Using a road with little or no existing ITS services to avoid direct comparisons with existing ITS services would make ‘HMI reaction’ easier to measure.|
|Technical||Features and performance vs. computer power available||MuCCA||MuCCA Project Website||The hardware had an adequate performance for our final demonstration, but probably some struggles would have been found if the full perception system originally expected to implement, and human driver model, were running simultaneously. A performance upgrade is already in progress however.|
|Technical||Procurement and availability of automation-ready vehicle platforms||MuCCA||MuCCA Project Website||Timely access to a suitable automation-ready vehicle platform has been challenging in the project. Ready to buy solutions are expensive and developing customised solutions within the project requires a lot of resources. Early access to a physical platform during development has proven convenient although simulation has helped on this side to bench test algorithms and part of the hardware|
|Technical||Technology readiness and availability||MuCCA||MuCCA Project Website||The project has struggled to find a suitable of-the-self solution for a perception system that met the project requirements in terms of performance (long-range motorway speed), cost and maturity. The sensor market has been evolving quickly but there´s no cost-effective solution yet compared to other sources of data to feed localisation (i.e.: enhanced GPS and comms).|
Have feedback on this section? Let us know!
Please add your feedback in the field below.
Your feedback has been sent!
Thank you for your input.
An error occured...
Please try again later.