Join forces for a universal Hangboard app?

[8cH9azbsFifZ]

I have just found your excellent repo. Currently I am working on a universal hangboard mount for measuring force and velocity. The backend will provide timers, exercises and sets besides the force and velocity measurements.

The exercises will be provided in JSON (?) and could be written in a universal format (i.e. JUG or 2mm) and the board-selection backend can select the respective holds for the selected hangboard (also configured in JSON).

So far I have a working demonstrator for my home setup.

What do you think: should we join forces to create a universal hangboard exercise timer app (if available with force measurements)? :)

Regards: Gerolf

[gitaaron]

Hey Gerolf!

Thanks for contacting me. That sounds like a great idea and I would love to try and work with you somehow. Just to warn you though I am not sure how much time I can commit over the coming 1-2 months as I am in the middle of working on an app for problem grade consensus for home training boards (similar to moon/tension except without the LED lights for now) and would want to finish it before launching a new endeavour.

I think the force/velocity measurements would be an extremely valuable tool and I would love to know more about how it works with the mounting system. In particular I am curious if you are using french cleats so I can mount a bunch of different boards.

Have you seen http://hangbird.app ? You can have a look there to see how I am using this repo out in the wild.

[8cH9azbsFifZ]

Currently my main focus is working on the backend, measurements and exercise logic. I can find only little time during the night times, so it will probably take some weeks until this part is finally working for more than my home set up. For the final version I'm still evaluating whether it should run and raspberry pi with Wi-Fi or Bluetooth low energy. 

When it comes to implementing the frontend in flutter or react native I am still in the early learning phase. My initial plan has been to put all logic and calculations in the backend and implement a very simple front ends for different platforms. 

As a first step I will merge my Hangboard setups into your format. This is a little work as we had more or less exactly the same idea 😁

Depending on how quickly I am able to flutter I will try to use your whole library in the next step. 

[8cH9azbsFifZ]

BTW: I have just checked out your Hangbird app 😁 great work!!!

[gitaaron]

Hi Gerolf,

Thanks again for reaching out! I have a feeling we could accomplish a lot if we joined forces somehow so would love to try and find a way to partner up with you.

I think there is a lot of potential in providing a force/velocity measurement hardware tool. I was planning on introducing support for recruitment and velocity hangs in the near future. To support this I was just planning to add a 'lead up phase' before the hang phase that was configurable between 1-5 seconds. I think having a hardware device that helps me measure my rate of force production over time would be really helpful especially for velocity hangs. For recruitment I would like to know max force. For that I actually purchased a crane scale but it would still be more convenient to have a hardware device to record my results automatically for me.

Have you thought about a business model yet? Do you have any ideas on how we can partner up?

Thanks, Aaron

[gitaaron]

BTW - I am curious what criteria you are using for your design consideration of wifi vs. bluetooth.

[8cH9azbsFifZ]

Hi Aaron,

You are right: there is a big potential in this project. There should be one timer application with measurement capabilities and maybe even an exercise community (like for the moonboard).

The prototype is working now with maximal, average, rate of force development (impulse), hang time and maximal velocity detection. So when it comes to the backend python can be deployed quickly for such an experiment. This is why the logic is contained in python so far. My test setup comprises a Zlagboard EVO modified with load cells and an unmodified Zlagboard Mini with a gyroscope sensor. Another universal mount (which could be used for any hangboard) is halfway assembled. I would say: measurement logics done. BTW: I have some some sensors to test here (i.e. distance sensors).

You get the idea looking at the pictures: https://github.com/8cH9azbsFifZ/hangboard :>

Next step is create more assessment exercises and dynamic calculations for workouts (i.e. given hang intensity, velocity etc). The logic will be prototyped in python once again... The smart board will only be smart if there is some action resulting from the measured values ;)

My initial idea was to put all logic on that raspberry and create a display and control app without any logic (using websockets for state, control and configuration transfers). Why not BLE from the beginning? Because I am not experienced in developing apps. My first experiments with React Native lead me to the conclusion that this technology is not stable or documented enough for getting results quickly. Flutter seems to be different here. Since I started learning to flutter on Sunday I am still struggling on how to implement a good UI :)

Getting BLE to work on the backend side is a simple step from here. At least on the backend side. Even a reimplementation on ESP32 or Arduino would be possible to lower power consumption. BLE would be an enabler for the bigger step: User management, performance records, exercise editor (simpler than JSON :> ). An app like this could be used with or without the sensors depending on what is available to the user ... But all that depends on a good App (this is where I bet you can easily do something).

When it comes to business case: so far it has been fun to learn the new technologies :> Primarily I am a user trying to build what is not there yet. Lets see what happens..

Regards: Gerolf

[gitaaron]

Hi Gerolf,

I just had a look at the 'hangboard manual' you wrote up here - https://8ch9azbsfifz.github.io/hangboard/doc/index.html

This project sounds really exciting!

It is great that you are willing to use flutter for the front-end. It is a fairly steep learning curve but I personally think it is worth it. I feel like I am a lot more productive with it over react-native. If you have any questions at all regarding flutter then I would be happy to try and help.

It is also really great you are developing this out in the open. I think people would appreciate the transparency. Have you thought about productizing it as well? I think there could be a lot of people out there that would be interested in this but not want to DIY all the hardware. I would imagine a lot of people do not own a soldering iron. :)

I would love to join forces with you as I have a feeling we could accomplish a lot together. What if you provided me with an API to talk with the hardware mount you are developing and I added it to the hangbird app? I suggest that because it could be the simplest way for us to get started working together but I am open to other ideas.

Thanks, Aaron

p.s. the 'distance' sensor sounds interesting - are you thinking a device the athlete attaches to their harness or something?

p.p.s the reason I ask about bluetooth vs wifi is I don't have a lot of experience with this so would love to learn more about your learnings. A lot of the apps I have used in the past have seemed to be really buggy when it comes to connecting BLE. I was wondering if it has to do with the nature of the bluetooth protocol and if there is a way to overcome it. I was also wondering if it is more so a range issue. If that is the case then I guess it might not be an issue if the phone is mounted close enough to the hangboard. I would also imagine BLE would be necessary if you are planning to power it with batteries (probably would be more ideal for something mounted over a doorway). Although perhaps you could simply add a power on switch to conserve batteries while the device is not in use.

[gitaaron]

Hi Gerolf,

I just had another thought that might be helpful for you if you did decide that you would like to create an app on your own. If learning Flutter is a sticking point for you and you are more comfortable in react (or react-native) you could always consume the SVG and JSON that this project generated.

If you have a look here - https://github.com/gitaaron/boards/tree/main/boards/boards_metadata you can see the raw JSON

All the SVG that the example and app uses is here - https://github.com/gitaaron/boards/tree/main/boards/board_svg

Hope this helps!

Aaron

[8cH9azbsFifZ]

Hi Aaron,

Here a brief status update.

1. Flutter demonstrator working with live load curve now. Obviously the colors are terrible and there are still performance issues with my websockets and JSON implementations. (FIXME and REDESIGN).
2. SVG in flutter? Currently I made a shortcut using generated PNG due to dependency problems. My plan is to use your library :) (FIXME)
3. API: I would love to use MQTT or RabbitMQ (or something else) for improved stability. I was able to get a hello world running in flutter, yesterday finally. The main difficulty for me was: how to implement a state correctly in flutter? So the next step will be to migrate the communication to MQTT. Work in progress… This middleware choice has the advantage that we could later on switch to different hardware devices and keep the protocol stable. Following your proposal I started with the interface of the load sensor at first. (REDESIGN) 3a. API: Maybe use protobuf for type safety? As soon as I am sure what commands one will really need I will be happy to describe and implement an API, that your app could use.
4. Hardware: personally I have little experience creating a product as simple as putting these sensors together. I’m not so sure how expensive it would be due to the overhead costs. And probably you’re right: most of the people out there don’t have a soldering iron aura the confidence to use one at least. Once the software works we should consider this ;)
5. BLE: in my first experiments some years ago I have used Bluetooth low energy as a replacement for Bluetooth UART. Why? Because if you want to implement some hardware talking to Apple devices you have to be certified for Bluetooth. Too expensive… While my Morse code experiments we are running very stable there have been a lot of issues with our Moonboard implementation. First of all there is a big range dependency even in one room. Then, when it comes to Linux and raspberry Pi, we had a longer journey to find a stable communication stack.
6. APP: we could choose both ways as a first step. Once the API is extracted you can use it in your app and for development I can continue my struggle with flutter and implement a testing app.

Within the next days I will finish the first API to the load sensors and send you the reference for review.

Regards Gerolf

[gitaaron]

Hi Gerolf,

Thanks for your update! Please see my responses with the same number below.

1. I would love to see it working in action. Can you shoot a video or take some screenshots? I am guessing you might sort the performance issues out when you get to the other points. Just a thought though - are you sending all the data you capture from the hardware device or are you filtering out the noise before you send it over the wire?

2. Sorry to hear about the dependency issue. If you want to post an error message I can have a look. It is probably because I need to migrate this project to the latest version of flutter (with null safety).

3. Where are you thinking the middleware will sit? Are you planning to have the hardware talk directly to the phone or having it go through a server in the cloud? My concern with the latter would be if you decide to take the server down there would be no way for users to continue using the device with the app. I am sure you mean well but if it is possible it is probably in your interest to not have to worry about running a server somewhere in the cloud. Or were you thinking of running a webserver on the raspberry pi? Funny you mention protobufs. I just came across this library. Not sure how useful you will find it for this project but thought you might find it interesting (if you hadn't heard of it already) - https://grpc.io/ .

4. Perhaps I can be your first customer? :)

5. Interested to hear more about the moonboard implementation for the other project I am working on.

6. Sounds good to me! I would be happy to help get you up and running with your app if you have any questions or want to do a screen share let me know.

Looking forward to reading the API reference!

Thanks and take care, Aaron

[8cH9azbsFifZ]

Hi Aaron,

Referencing the numbers once again, here are my quick answers:

1. A video can be found here: https://github.com/8cH9azbsFifZ/hangboard/releases/tag/v0.44. The noise is not sent, it seems to be a problem with python threading (mixed with asyncio websockets module) and too much JSON decoding calls. The MQTT hack seems to be much faster.
2. You are right: null safety has been the issue. I bet once your example shows images again with null safety I could integrate it asap :)
3. MQTT should be in a container on the raspi (works out of the box with docker-compose for example).
4. Yes -> looking forwards to do this (software must work once again after redesign :)

=> API Reference - WIP. Have to re-write the frontend now :>

Regards: Gerolf

[gitaaron]

Hi Gerolf,

I will continue with the numbered responses.

1. Looks great thanks for sharing that link. So is the real time graph force over time?

2. I will start working on porting everything to the latest version of flutter with null safety. It is going to take a bit of work as I forked a few (charting and showcase) libraries along the way so I am not sure how I am going to deal with that. Just to let you know it may take a while - sorry for that.

3. MQTT looks interesting. I don't know much about it but can see how you might want some sort of pub/sub mechanism so that more than one device can subscribe to the mount. You could, for example, have a watch app that buzzes once 80% max effort is reached.

4. I also am looking forward to it and having a look at the API reference!

Thanks, Aaron

[8cH9azbsFifZ]

Hi Aaron,

Ad 1 - correct :)

Ad 2 - very good. In the meantime I will add more functionality to the backend.

Ad 3 & 4 - I am working on a code generation and documentation using AsyncAPI. Your example is correct - more sensors and multiple users are possible.

In the meantime the frontend has been refactored, the fluttered code looks a little better now. I hope to have a new pre release next weekend.

Regards Gerolf

[8cH9azbsFifZ]

Hi Aaron,

The new pre-release is running on cleaner code without performance issues during measurements: https://github.com/8cH9azbsFifZ/hangboard/releases/tag/v0.49

If you start the backend without modifications a simulator with load data will be running.

Currently I am struggling with a "stuttering" sound (i.e. t-t-t-t-t-t-ten). It seems like the files are played back multiple times at once.

A first version of the API documentation can be found here, but it is still very volatile: https://8ch9azbsfifz.github.io/hangboard/api/index.html

Regards: Gerolf

[8cH9azbsFifZ]

Hi Aaron,

• [ ] The stuttering sound issue is solved, intensity calculations and MVC based work out generation is implemented in a first version. Furthermore I have implemented a small persistence in mongo for storing the workout data and doing some posthum calculations. So far the evaluations include calculations of the maximum applied force and the rate of force deployment, as well as intensity calculations. I tried to estimate the resulting force on the finger tendons for a kind of workout overall intensity.  detecting pull ups from the load signal it's not so easy, as the signature of the pull up seems to differ from person to person and the velocity. This means I have to integrate the ultrasonic distance sensor once again for a pull up detection. Overall for my home set up I'm able to do the workouts I currently do :) for better possibility I have included  docker-compose for the backend services. 

If you want to give it a shot I think it would be possible from now on :)

Regards Gerolf

[adrianlzt]

Hey! Sorry @8cH9azbsFifZ, I don't know why I didn't receive any message for your issue in https://github.com/adrianlzt/piclimbing/issues/8

I think we can move here the conversation.

I have been reading the conversation. It's cool to see more people with the same ideas :)

@gitaaron I was doing something similar to @8cH9azbsFifZ here https://github.com/adrianlzt/piclimbing

The idea is similar, adding a force sensor and a linear encoder to be able to measure climbing parameters.

My setup is a little bit different. Using golang as the backend, I really like the one file release method and I was concerned about python maybe not being fast enough.

That backend exposing a GraphQL API to start/stop sensors and get data. I really like how you can define a schema file and then is no doubt how to use the API.

For the frontend I created a web app with Gatsby that was embedded inside of the release file. So just running one binary you got the backend running and the web app exposed.

The app should be run in a RaspiZeroW where the force sensor and linear encoder are connected. The Raspi exposes a wifi network where you should connect to access the webapp.

I don't really like this way much, because, for example, a phone connecting to a wifi is going to try to use it to connect to internet. But for my use case, at home, was way easier to develop and show the stuff in a laptop.

About the sensors, I have a S-type load cell. I'm not sure if it is more or less precise than then ones you are using @8cH9azbsFifZ. I bought it after seeing Tyler Nelson using it and have seen it also in the tindeq and with Pedro Bergua.

One thing to take into account is that temperature and humidity affect the values. I was calibrating it always before using it. But then you start to think if your home balance is well calibrated or the other one... Now I have three different balances and it's hard to say which one is the real value (this balance also looks like a S-type load cell.

Another problem is how fast to take the force measurements. HX711 is limited to 80 SPS IIRC, that I'm not sure it's enough to measure RFD correctly.

I haven't checked the detail of how do you get readings. I used the kernel driver, to improve speed and found a really strange behaviour than even the driver developer didn't understand (kernel in debug mode was returning faster results).

About the distance sensor. I played also with different ideas, ultrasonic , video recognition, but there were not accurate enough. Then I found this project of building a linear encoder using a 3d printer. I get it to work, but still, very fragile and getting stuck sometimes.

A few months ago I decided to buy a real linear encoder and found this one for 100€ in AliExpress. Today I was playing with it to try to check if the speed values are correct (connecting it directly to a ESP32), it's hard :sweat_smile:

I think the hardware is the same used by Chronojump. This enterprise sell hardware and software (opensource) to measure speed and force for sport related training.

About the backend, yes JSON encoding/decoding is very computing expensive (references 1, 2, 3 16:45).

Sorry for the unorganized response. I just wanted to comment many things :D. Let's keep talking :)

[gitaaron]

Hey guys,

Thanks very much for getting in touch with me and sorry for my delayed response. I would really like to work with you as I have a feeling we could accomplish something really great if we put our minds together. However, I still don't know how much time I can put into this project over the coming months.

That said, here are my thoughts for what they are worth in response to your latest messages -

It seems like the three of us have a lot of similar ideas when it comes to hangboard training.

Are you guys interested in collaborating on an open source project or something we can productize? I would propose we start out with the former as it will be a lot easier to get started collaborating.

In terms of an open source hardware project that provides a sensor for measuring maximum force and rate of force development. In the future if we considered productizing this I believe the open API would be a selling point.

I also cloned the repo you shared, Gerolf, but unfortunately I am having major space issues on my old computer (related to trying to move to the latest flutter release). I had to remove docker a while ago to free up space so it will be a while before I am able to run the code you have shared thus far.

I had a look at the API you shared and I would recommend not including anything hangboard specific. The reason is you might consider not limiting such a hardware device to hangboard training solely.

For example, if you could make the form factor work with any ‘no hang’ (similar to strain gauge) then one could use it to measure overcoming isometric dead lifts. Ideally it could also work with a fixed board (ideally with a french cleat) as I could see the versatility being a selling point. Even if they were two different devices with the same underlying technology, the open API might be attractive to developers / researchers from a wide array of disciplines.

Nice meeting you, @adrianlzt and thanks for your message also! It sounds like you have put a lot of thought and have a lot of experience in the hardware arena. If you guys want to take point on the hardware device I could probably fairly easily add it as an add on to the app I already have out there (hangbird). I could purchase the hardware you suggest and also give feedback on the API from the consumer’s perspective (just a thought).

Thanks and looking forward to hearing back from you, Aaron

[gitaaron]

Hi Gerolf,

FYI - I just updated this project with a new version to work with null safety. Hopefully this fixes your dependency issue.

Thanks, Aaron

[gitaaron]

Just wanted to share another idea with you both - an open database similar to apple health kit / google fit. Perhaps based on IPFS? I have no clue how that would work as I don't know much about it, although, it is something I would like to learn about.

I could see there being utility for researchers in such a project. The main problem I would foresee in such a project (besides learning IPFS) is ensuring data quality. Not quite sure how that is solved although that could possibly be a separate project.

Eg/ a different project for climber identity that requires a video for each send

[gitaaron]

Hey Gerolf, ( @8cH9azbsFifZ )

I see you are active on the open source moonboard project. I mentioned earlier that I am working on a community board app.

You can download the demo from the landing page here -

http://dabatcrag.com

I would love to chat with you sometime about the project. I am thinking about integrating it with the app so the app can work with any moonboard LED system. I am also thinking about creating my own open source project from scratch that works off of WIFI instead of BLE as I think there will be less connectivity issues.

Both of yours and Adrian's (@adrianlzt ) thoughts on the subject are much appreciated.

[8cH9azbsFifZ]

I had a similar idea. The DBUS seems unstable to me. Maybe WiFi with MQTT backend?

[gitaaron]

Sounds cool! Any advice on getting started is much appreciated as I am completely new to the hardware side of things.

Also, what are your thoughts on a laser system from behind the climber?

Downside is I wouldn't see the lit up hold while climbing. Upside is it might be easier to install (especially for home walls) and it would work with any hold / board configuration.