🏋️‍♀️ Introducing Atrainable! 🏃‍♀️

Most fitness plans aren't maintainable. Meet Atrainable.

❓ Framing the Problem

Most fitness apps don't account for individual health concerns, such as the impact of the menstrual cycle, while still making sure your hit your goals. This makes "personalised plans" feel less personalised and more unattainable.

💡 Idea Explanation

• Atrainable provides users the ability to work towards a specific fitness goal while allowing them to amend their plan depending on conditions that impact their fitness, such as their menstrual cycle or how they are feeling.

• Users start by defining a specific goal they want to work towards.

• They can then import their health data from alternative apps.

• A fitness plan is then generated using a graph-based AI planning algorithm (explained further below).

• The plan is automatically adjusted as health data changes on a day-by-day basis, meaning users don't feel guilty for not following the exact plan and know their needs are being met.

🔨 Implementation

👾 Backend flow

1. On start up, all the hard coded data files (exercises, health context/menstrual data, goal targets) are loaded into an in-memory database.

2. The setup endpoint receives the user's goal, fitness impact, and duration of desired plan in days.

3. Exercises applicable to the goal are loaded from the database. These exercises have expert-assigned values that correspond to five categories: strength, hypertrophy, fat loss, endurance, mobility. The higher the value of these categories, the higher priority they are.

   1. For example, a weight lifting goal would be high on strength, while Hyrox is high on endurance.

   2. The health context, or the expert-assigned value of each fitness impact, weights each category for each exercise, reducing negatively impacted areas and increasing positively impacted ones.

   3. For example, the menstrual phase of the menstrual cycle will negatively impact endurance, while arthritis would negatively impact mobility.

4. All of this is fed into the planner system. This returns an ordered list of exercises it thinks will best help the user reach their goal in the specific timeframe.

5. The plan for each day can be accessed separately. This triggers a recalculation of the plan to account for daily changes in the health context, which may be gathered from the user's phone data (health connect/Apple health).

6. You can simulate this by going into the database (instructions in the HELP file but it's at port 8080 /h2-console, password in the configuration file) to change some of the health context data - in our use case, the phase of the menstrual cycle. After saving the changes, the daily plan endpoint will return both the modified plan and the original plan when it is called.

💻 Frontend

A simple frontend was created to show the API in action and give an idea of what could be displayed to users.

Tech Stack: React, React Router 7 (framework, quick to setup as uses Vite and provides easy routing), shadcn UI (fast and easy to use components), Tailwind (quick to use classes), React Query (easy to talk to the api), React Player (easy to embed YouTube videos).

• An initial setup page is shown first. The idea is that when a user signs up they need to configure their health and lifestyle factors, connect their health data, and set their fitness goal.

  • 

• The next page is displays the daily plan. This is sending a request to the backend's daily plan endpoint with the specified date. You can see future dates of the plan by clicking 'Next Day'.

  • The default suggested exercises are shown next to the modified exercises for the day. The idea is that the user can choose what they feel they're capable of each day - this would then help inform the plan going forward.

    

• Clicking 'Start' navigates to the page for the selected exercise. The idea here is that a guided video or animation would help the user action their fitness plan, with a future addition being more controls to allow for altering the difficulty during the session. The user's health factors may be aggravated by the exercise, so the user should be able to signify this and thus further inform their plan.

  • 

Here are some initial basic designs/wireframes from when we were discussing what we need to display:

✨ Generating the plan

1. The planner is initialised with a pool of exercises, a goal state, and the timeframe in which the user expects to complete the plan.

2. A greedy BFS (breadth first search) algorithm is used to find a sequence of exercises that can generally be considered the best route to from the starting point to the desired state.

   1. It calculates the Euclidean distance from the current state to the goal state, and stores the lowest distance state sequence.

   2. The set of greedy exercises are added to the complete pool of exercises to heuristically inform the next stage.

3. The heuristically-informed pool of exercises are fed to a genetic algorithm that uses the following parameters to inform the final sequence of states: population size, generations, mutation rate, crossover rate, and a penalty for duplicating exercises.

   1. The algorithm works by mimicking natural selection. It generates a random population (set of states) and scores the fitness of each individual state in the population.

   2. It then selects random members of the population to be parents, and combines the two by selecting a section of each parent to become a child.

   3. This child has the chance to be mutated by randomly changing a single value to come from a different member of the population. The child is then added to the next generation.

   4. Multiple generations are populated until the solution converges or the number of created generations reaches a set limit. This results in a heuristically-optimised sequence of exercises to send to the user.

   

Visualisation of how well the suggested solution compares to the target solution

🧠 Why Did We Choose AI Planning?

We considered using an LLM for plan generation, but ultimately decided to go with an AI planning algorithm for a few reasons:

• Transparency. By using graph traversal, you can see exactly what the algorithm is "thinking" at any point.

  • The data used to generate the graph, weights, and paths can be made human readable.

  • The steps can be visualised in an easy-to-understand format.

• Less computational overhead than traditional LLM process, and considering it can be run offline, is better for the environment. 🌳

• It's scalable in the future and can be improved through more advanced traversal approaches, in addition to improving the associated weights and values through a feedback loop.

• AI planning matches well with our requirements:

  • Used to search through a state space to find a path to an end goal, akin to finding best series of exercises to reach a certain fitness goal.

  • In more complex forms it accounts for conditions to be met before a state can be reached, and similarly the effect of a state once it has been actioned. Aligns well with complex accessibility requirements.

  • Although classical planning requires a deterministic state space, our use of genetic algorithms to generate the path allows for a more dynamic approach that adapts to our proposed stochastic space: changing health context.

• Expert opinion can be used to guide the weights and paths in the graph, giving a clear and accountable origin to the source of information.

👍 Positive User Feedback

🆘 Challenges

• One of our software engineer grads accidentally did a bad merge and deleted the entire frontend. She then had to learn how to revert a commit... This challenge was overcome with much banter.

• We tried to integrate an LLM chatbot, but we're on our work laptops and aren't allowed to create new API keys 😔

  • We were pinged by the security team when we tried 😔

• Finding a way to offer the user choice and not force a specific plan option on them. We decided to show both the original and modified plan side by side to let them choose.

• Knowing which approach to take once we had rejected LLMs was hard! AI planning made sense, but its a field all of its own with plenty of complexities and choices in algorithms.

• 3D animations are really hard to put into react in 24 hours. We instead embedded videos from youtube so users still know how to use proper form.

  • None of us had relevant experience and gaining it would take too long.

🏆 Accomplishments

• Kirsten was so QUICK to come up with the initial idea! Immediate strike of inspiration!

  • We then proceeded to work in a collaborative way without disagreements, all having a go at something new 💪

• Reminded of ability to setup an application with speed!

• Learnt what 'hyrox' meant.

• New friends!

• We didn't vibe code.

• Discovered why you definitely shouldn't push straight to main.

• Learnt load of new skills

  • 🧠 Anuradha was well-versed in AI planning algorithms, something the rest of us weren't super familiar with, so we all got to learn the theory behind how they work and were able to see and try bits of the implementation

  • 👩‍💻 Emily was a wizz at frontend and could do it all super quickly, so when we got stuck in with trying to create the screens she was a great help

  • 👩‍🎨 Kirsten powered through the UI/UX design: it was hard but very important...we learned what made different fonts and colour combinations accessible (originally we wanted to go with a bright blue - way too bright)

  • 🖥️ Tara learned to be a full stack engineer and used a lot of the frontend stack for the first time, easily picking it up!

🔜 Next Steps

• Add in the ability to tailor the plan further based on health conditions (e.g. the user can have more control over how much they'd like to increase/decrease the plan difficulty)

• Ability to integrate with other apps that provide health data (e.g. using daylio, a mood tracking app, to adjust for mental health struggles)

• Create a phone app. People are more likely to remember to exercise with notifications and be consistent if it's available in their pocket.

• Extend to more goals and exercises - like running, and other strength or mobility goals.

• Setup a Chatbot to help users who are unsure of what goal they'd like to achieve. 🦾🤖

• More sophisticated planning algorithms (or just parameter tuning to start with). The existing implementations for the planner and algorithms are relatively simple, as befits a hackathon timeframe.

• Machine learning feedback loops to tune parameters based on user feedback .

• The frontend needs to be designed to actually look nice and focus on UX that would not put a user off! You should be able to see your plan quickly and easily and jump into it without any friction that may reduce motivation.

*Sperandei S, Vieira MC, Reis AC. Adherence to physical activity in an unsupervised setting: Explanatory variables for high attrition rates among fitness center members. J Sci Med Sport. 2016 Nov;19(11):916-920. doi: 10.1016/j.jsams.2015.12.522. Epub 2016 Jan 28. PMID: 26874647.