User interactive response

Closing. Reopen if necessary.

Would I need a rpi to get started with this issue?

Haptic driver chip like DRV2605L (TI) has waveform library (by Immersion) on it, and the cost of chip incuds license fee.
i.e. If you use this chip, there is no license issue.

For DRV2605L has several DYI breakout boards are avaiblle.

e.g

https://www.sparkfun.com/products/14538

You can connect ERM or LRA motor to this, and connect this to the host via I2C.

Then, on host, you can control it via I2C commands, or device drivers (Linux kernel has it.)

The app may rather choose to use middleware that bridges between such kernel driver and aplication library.
(So that the app do not have to have device specific code)

Linux seems to have FF (force feedback) framework.
I doubt if it is flexible enough, though.

For simple haptic feedbacs.

Looked into two graphics toolkits.
Whatever haptic device we use, these are the low-level libraries that needs device integration.

1) html5

• Vibrate API

• Chromium support this only for Android (for the other platforms it is just stub)

https://bugs.chromium.org/p/chromium/issues/detail?id=442132

2) Qt

• QtFeedback package has QFeedbackHapticsEffect

• Current qtfeedback code has plugins for the following:

immersion

meegotouch
mmk (multimedia)

https://github.com/qt/qtfeedback

AI: chromium integration
AI: QtFeedback integration

For the seed of the discussion:

1) Vibration feedbacks

For simple vibration feedbacks projects like below:

TI reference
http://www.ti.com/lit/ug/tidu968/tidu968.pdf

DIY project (using pizezo actuator)
http://www.instructables.com/id/Arduino-DRV-2667-Haptic-Piezo-Driver-Control/

I can see the stack should be as following:

(software)
Host application (communicate to host middleware) gives high-level commands to middleware.
Host middleware (communicate to host driver) translates high-level commands to low-level commands.
Host driver software (communicates to driver chip by i2c) gives low-level commands to the driver chip.

(hardware)
Driver chip (connected to actuator) drives the actuator.
Actuator (attached/integrated to the display) gives vibration.

Low-level commands are just I2C command calls.

I imagine there are touch displays pre-configured with actuators for this purpose.
Or, alternatively, it is not too complex to do some DIY.

In case vibrating with actuator (through such driver chip) is a common practice, doing demos using DIY module like above is not very far from the actual product design.

2) APIs

For high-level APs, I can see things like below.

For short-term, AGL demos should try taking advantage of these APIs to avoid re-inventing.
(But I imagine Qt/Web library must be integrated with some work to the above hardwares.)

Qt:

https://doc-snapshots.qt.io/qt-mobility/qml-feedback-api.html
https://doc-snapshots.qt.io/qt-mobility/qtfeedback.html

I can see HTML based APIs exisits.
I am not sure if these are otheres.

W3C/WHATWG:

https://www.w3.org/TR/vibration/
https://notifications.spec.whatwg.org/

3) Types of feedbacks

Scope clarification may be needed, since feedback/interaction may contain wider meanings.

3-1) Types

Vibration is just one of the types of feecbacks.

• Sound (traditional "beep" sound.)

• Flash (the screen blinks so that hearing impared driverfs can have feedbacks.)

• ...?

It could be arguard that it would be natural that UX provides the options to give sound or visual feedbacks instead or together with the vibration. From application point of view, it do not have to think it as "vibration", but "button-press-feedback".

(Qt API above looks like designed so that it is not "vibration" API, but genral "feeback" API.)

3-2) Other than simple (buttun-press) feedbacks

There may be other tactile feedbacks other than button-press feedback (vibrate immediately after button press).

e.g. knob/commander (like iDrive) vibrates when the cusor is on the button on the screen.
e.g. ultrasonic vibration giving the end-user "feel" of buttons.

I imaging giving a solution to "how can I identify button locations while my eyes are not on scfreen" is also a very important topic in automotive UX, which may need to be addressed in UX demo.

(BTW, No cursor/pointer type input device as standard part of the demo? I thought meters or hedunits on large luxuary cars are out of the reach of drivers' hands, so knobs/commander devices were preferred.)

4) Legal issues

Do we have patent issues when we do demos like this?

• What IPs exist and covering which technology / use-case?

• Only demo is OK? Do we need to acknowlege, or need some license even for demo?

• Any patent pool?