Concerning the GUI design, I see you are mimicking a joystick. You might like to test using only buttons, easier to setup.
Y'all provided a lot of things to think about and I was able to rebuild the app using much of what was proposed.
It now is functional with the exception of random bluetooth connection issues.
Here is the app now:
If you know of ways to trap and recover from the BlueTooth errors I'd like to learn more about them. I've not invested any time find and read posts on this so I need to do this.
Here are two blocks you can drag into your Blocks Workspace to address errors ...
I left them empty (blithe) to ignore errors.
A more scrupulous approach would be to have them log errors.
Sample logging procedures:
Terrific - I appreciate this. I've added blocks and left them blank as you implied was sufficient to simply eliminate the messages.
... the errors may have something to do with the short time interval, you could, as an experiment, make the intervals ten times larger just to see. If that is a "cure", you can then tweak the interval down again until you arrive at the optimum. If it is a timing issue, then yes, you can get away with ignoring the errors on your device, but if someone uses your App on their phone and their phone processes more slowly than yours - the App will fail.
It could be that the Bluetooth module is too close to either the processor or a motor, both of which can cause interference.
Another possibility - does it work OK at first and then the errors become more frequent? If so, it is very likely that the Bluetooth module is getting too hot - it might be too close to a source of heat but that source probably needs cooling for it's own survival.
You have some interesting points.
I guess I'm not committed to spending much more time on it.
I am interested in setting up something on the Arduino side to measure the frequency at which the HC05 is receiving the bytes. I just learned that the robot is needing the byte refreshed no less than every 100milliseconds to have fluid movement. I had set a goal of 20millisec but in reality it can be a much longer interval. It will be helpful to be able to measure the frequency that the Arduino is getting the bytes and then see if other smart phones are in that ball park.
Would the BlueTooth connection be more stable if there was some sort of a "stay-awake" activity?
Well, the App keeps everything awake by default, given the time interval. It is often the case that the connection has not actually been lost but the signal is too poor. You can set up a Screen Error Block and use it to ignore the errors that would be identified as a potential loss of connection. If you can have the Arduino Sketch Loop at 100 milliseconds, and the App Interval at, say, 120, you should be good to go. See if you can improve the hardware too - I forgot to mention that if you use any metal materials for the robot body, they must not be between the Bluetooth module and the smartphone (i.e. in the signal path) as that degrades the signal considerably.
Note that classic Bluetooth does not have a built-in way to indicate a disconnection. We discover the connection may be lost when data sending/receiving fails.
Is there a way to eliminate extra Join 'sockets' when they are no longer needed?
I'm am interested in your 'Get Error Info' snippet for 'Screen 1' that you shared.
I was able to get the snippet into my project and clear the 'Warnings' caused by having a duplicate '.ErrorOccured' handler.
I then added the 'ErrorInfo' routine to the '.BluetoothError' handler. I was able to delete the properties from the 'Join' sockets that were not needed but found that I cannot figure out how to eliminate the open 'sockets' that are left.
The little Blue Symbol on the Block allows you to add and remove sockets.
I'd been wandering about the significance of that emblem, but had not noticed that it opened up.
Did you get this working for the Balancing robot by Joop.
I have built the same robot and it balances well.
I as yet have not got the control working.
Would you be willing to share it ??