eigengo / lift

...Do you even? Exercise in exercise analysis

For most up-to-date version, head over to https://github.com/muvr/open-muvr.

lift

A demonstration of an application that uses wearable devices (Pebble)—in combination with a mobile app—to submit physical (i.e. accelerometer, compass) and biological (i.e. heart rate) information to a CQRS/ES cluster to be analysed.

The result is automatically constructed exercise log, which includes:

• the kind of exercise (biceps curl, shoulder press, and other such tortures)
• the intensity (light, moderate, hard)—nota bene that intensity != weight

---

It is also an excellent demonstration of large reactive application. It is event-driven: throughout the application, it uses message-passing to provide loose-coupling and asynchrony between components. It is elastic: the users and their exercises—the domain—is sharded across the cluster. It is resilient: its components can recover at the appropriate level, be it single actor, trees of actors or entire JVMs. It also uses event sourcing to ensure that even catastrophic failures and the inevitable bugs can be recovered from. It is responsive: it does not block, and it is capable of distributing the load across the cluster.

It combines near-real-time machine classification needed for immediate exercise feedback, with "offline" model upgrades. Once upgraded, the event-sourced nature of the system allows us to re-apply the new model to the old data, and thus provide the users with better data.

lift's Issues

Issue with how config files handle lists held in environment variables

Currently, production specifies lists of hosts, seed nodes, etc. using comma separated values passed in via environment variables. These are then embedded for use by Lift via config code such as:

akka.cluster.seed-nodes = [ ${?SEED_NODES} ]

The problem here is that values in environment variables are treated as single string values and not as lists of string values.

Explicit classification on real device

The explicit classification does not work as expected when used on the mobile device with the watch sending the data. The selection tickboxes do not hold, and the requests are selected, followed immediately by unselected.

InventoryStore improvements

There are two features that such cluster storage "things" should support:

• support for service discovery (the current Adapter code addresses this requirement)
• support for failure detection.

Obviously, the Adapter code could benefit from the addition of failure detection support. In etcd you currently have to implement this using sidekick services that maintain a TTL value on the key. In Consul (see http://consul.io), this is done using health checks (that a user pre-specifies).

//cc @carlpulley

Buffer overflow in SensorDataGroup.decode

The decoding code in SensorDataGroup.decode might cause buffer overflow on receiving damaged or malicious sensor data. Add appropriate length checks.

Multiple sensors

Add the ability for the mobile to include its own accelerometer, gyroscope, GPS and heart rate (via HealthKit) data. Include in the MultiPacket sent to the server. Add configuration that allows the users to set where they keep the phone, defaulting to waist. (Imagine that the user keeps his or her phone in the shorts pocket.)

• Implement proper multi-device sensor data processing
• Add HealthKit heart rate, accelerometer, gyroscope and GPS handlers
• Allow the users to configure the sensor location

Frequency of input data for the classifiers should be synchronized

Classifier algorithms currently rely on data that were taken at the same sampling frequency. While currently all sensors work at 100Hz, this can change in the future.
Re-sampling can be done:

• on the phone: this has the advantage of better scaling and some preprocessing can be easier done on the phone; disadvantage is the possible limitations of the phone hardware.
• server-side: this has the advantage of the possibility to share code with the classifiers, and other Scala code; disadvantage is that it can scale really bad for many simultaneous exercise sessions.

Sensor locations may transmit multiple sensor data types

Each sensor location (e.g. wrist, waist, etc.) may generate multiple types of sensor data (e.g. accelerometer data, rotational data, etc.). The exercise classification code does not currently take this into account (it incorrectly assumes that each sensor will transmit just one type of information).

SensorNet and SensorNetValue need to be generalised so that they can store multiple types of sensor data. The size of this list should remain constant (at least for the current exercising session - though it may vary between different sessions).

These changes will impact the UserExercisesClassifier and ExerciseModel actor receive methods (in particular, the require statements that they have). The logical query model should (hopefully?) be untouched by these proposed changes.

Add licenses

Nice work, could you please indicate the license with it?

Ensure that iOS tests run without first logging in

Ensure that the CurrentLiftUser.userId is not nil when running unit tests.

Verify iPhone sensor data sanity

Check that the acceleration and rotation rates report sane values. The acceleration units are cm/s^2 ("milli Gs"), and we trim at 40m/s^2; when the phone is left without movement, the values should be around 0.

The rotation rate is in mrad/s; given our ranges, we expect fastest rotation to be 4 rotations / second; the maximum value should be 1000π.

i18n for all strings

The server should not store any text to be displayed to the users. Anything to be displayed to the user needs to use some i8n key. See https://github.com/eigengo/lift/blob/master/ios/Lift/Base.lproj/Localizable.strings. For example, exercises should be

"exercise.arms"="Arms";
"exercise.arms.bicepcurl"="Bicep curl";

And so on. We need to hunt down all non-it8n strings and move them to the localizable properties.

Live session classification view

Allow the users to classify the exercises by tapping on the exercise name, then optionally setting the intensity, weight; then allowing the user to end the exercise automatically.

Split build so that long and short running tests are identified

ExerciseModelTest (and the looming CVC4Test) are long running tests. This means that Jenkins may timeout whilst running these tests!

So, we need to be able to identify long running tests so that:

• short running tests can be ran immediately by Jenkins
• longer running tests can be chained by Jenkins and reported back upon at a latter date.

Split live session stats and exercises

The live session (in LiveSessionController) needs to be split into multiple "pages" that the users can swipe between:

• Exercises (detected and currently exercising)
• Session stats

It is possible that further pages will need to be added in the future.

Pebble-ios packet counter differences

After some time the packet counters seem to be misaligned in the pebble and ios app.

Collect lab-conditions labelled data

Record accelerometer data for lab-conditions, single repetitions of the suggested exercises. Save the multipackets that would have been sent to the server.

---

Tasks:

• Implement session data save to file.
• Execute exercises.
• Collect and tag data.

Verify multi sensor data encoding

Verify that the values encoded using the multi-sensors are sane. Check especially in combination with the BLE transmission errors from the watch.

SensorDataGroup view in running session

Provide visual view of the SensorDataGroup in the running session. Follows on from #61

Tidy up iOS sensor encoders

Complete the sensor submission code, integrate with the server code:

• Implement ContinuousSensorDataArray.encode(mutating:) method,
• Submit data to the server in LiveSessionController.deviceSession(session:sensorDataReceivedFrom:atDeviceTime:data:)
• Verify that the accelerometer data encoding in encode_lift_accelerometer_data matches the Pebble code (focus on memory layout)
• Check that that the multi packet is decoded properly on the server (raise another issue if not)

Live session tag view on iPhone/Pebble

Given:

• an exercise session is running

Then:

• the user should see a list of exercises in the Phone app
• the user should see the same list in the Pebble app
• the user should be able to select an exercise she will be doing on the Phone
• the user should be able to do the same on the Pebble watch

---

Given:

• an exercise session is running

When:

• the user chose the current exercise

Then:

• the user should see a simple user interface that allows her to set the intensity of the exercise, and the weights used in the Phone app
• the user should be able to set the weight (intensity optionally) in the Pebble app

---

Given:

• an exercise session is running

When:

• the user chose the current exercise

Then:

• the user should be able to stop the current exercise (but not the exercise session) in both the Phone app and the Pebble app

Need to be able to run multiple localised versions of LiftLocalApp in AWS

As a partial step towards deploying Lift into a production environment, we need to be able to run multiple versions of LiftLocalApp in their own docker containers and as a viable Akka cluster. The general idea idea is that:

• each container will run a single JVM
• each JVM will host a single actor system
• within each actor system we will run the full set of microservices (i.e. exercise, notification and profile)
• each container will need to expose a REST port and an Akka port
• collection of containers should form an Akka Cluster.

MicroserviceApp does not register the API path.

Hi congrats for the awesome project, that I saw presented at scala exchange.

In the MicroserviceApp the pattern used to register:

ClusterInventory(system).set("api", s"http://$hostname:$port?version=${microserviceProps.version}&side=${microserviceProps.cqrs.mkString(",")}")

Is not the same as the one used in the AdapteesActor to parse the address:

val Address = "http://(.*):(\\d+)(.*)\\?version=(.*)&side=(.*)".r

So when the AdapteesActor try to match the URL it is failing. The problem is that the RestApi in BootedNode is defined as function from ExectionContext to Route, it should expose some information regarding the path.

Probably it makes sense to have the path, version and side as part of the RestApi type instead of MicroserviceProps.

What do you think about it?

P.S. I saw the Reference type in Adaptees that is not used, was it intended to be used to define the path?

Remove `akka-stream-testkit-experimental` file ghosting redundencies

Currently, the package akka-stream-testkit-experimental is an empty package. Hence, in order to write Akka reactive streaming tests, we need to explicitly include the relevant (ghost) source files in our project. This will obviously change in due course!

This issue exists to:

• track the package akka-stream-testkit-experimental
• ensure code that is currently ghosted in server/exercise/src/test/scala/akka/stream/testkit/ is deleted once this package is formally "released".

Pebble AppMessages communication data loss in background mode

When running the app in background mode, the device is allowed to into deeper power-saving modes, resulting in approximately 10-15 % BLE packet loss. Find out the root cause of the packet loss, and find approaches to eliminate it.

Though power consumption is a concern, it is more important to achieve less than 2 % BLE packet loss.

Pebble app crash

In some cases the pebble watch app crashes when ending a session. Since I only saw this at session end this might be related with messaging.
Steps to replicate:

1. Start the IOS app.
2. Start an exercise session.
3. After some time stop the session from the IOS app.
   Actual results: sometimes the pebble app crashes, sometimes the pebble app keeps on running.
   Expected results: the pebble app should terminate in a "normal" way.