Sorry to hear that. We know it can be frustrating to encounter blocking issues in the early stages of your setup. Rest assure that we are taking measures to solve much of the inconveniences that you describe as we speak. Since our goal is to provide a flexible and open motion capture framework it's a challenge for us to foresee all the possible problems that our users might stumble upon when using it in their particular configuration.
Jump connect the pi to an actually wall power supply instead of using the portable power bank, when doing so it would only fail one or two times and seemingly be fine
For example in this case the problems might be related to a power issue, as you correctly assumed. But apart from the power bank and wall power supply, the cable itself might be the issue, or even the wall power supply itself (some of them come labeled at a certain current, but they actually deliver less). We try our best to better guide you guys in choosing the correct power supply, but it's not easy given the wide availability of wallwarts, powerbanks and cables out there.
Even the ufficial raspberry forum is flooded with random problems that might have raised from a non ideal power situation: https://forums.raspberrypi.com/search.php?keywords=underpower
It would be much easier for us to deal with a closed product, where we can easily reconstruct what the user is doing. But it's just not what we do.
We are of course taking measurements to solve many of the issues that you and other people from our community such as @Tkthlntc are reporting. But as it normally happens in early stages of open source project the perceived pace of the development might seem slower than expected. To sum up the current strategy we are carring on:
The blender addon is currently our main and most flexible client. But it's hard to keep stable because of the way the blender python API is structured. We want the addon to be there for advanced users, or people who would take advantage of having a 100% Blender workflow. But other simpler clients should be available for regular users.
We are extending the remote console to be this main, entry-level client. Apart from the changes in the frontend we are currently finishing two big additions to the system core which will enable the easy implementation of mocap clients and were required to expand the remote console. These two additions are an armture abstraction inside the core, where to run key processing routines such as the pose-calibration, and websocket support for payload transmission. You can check the state of this developments on the notochord-module repository
So we need to balance the effort we put on the everyday fixes (such as updating the documentation) and these mid-term developments which will represent the real game-changer in terms of UX. Together of course with many other dev tracks aimed at making the capture smoother and more accurate (such as raising the sensor read-rate, improving the sensor fusion algorithm, enabling live magnetic disturbances correction, implementing positional displacement, etc)
Motion capture is a complex discipline, and at this point of the development small improvements require a non negligible effort, but we are working hard to give everyone a stable, accurate and robust mocap framework. And of course we plan to maintain backwards compatibility, so you will be able to use the hardware that you have right now with all the exiting features that are coming!
