Some observations ...
The Ball component has a flag that will set it to return its center X and Y, useful to avoid having to subtract the Ball radius for reporting its position.
If you would like to disconnect on error:
Recommendation to leave Clock1 Timer disabled until it is needed:
also a more feasible Timer Interval
Avoiding BT errors in the Clock1 Timer:
Turning on the Clock Timer when Ball TouchUp:
(All blocks are draggable into the Blocks Editor workspace.)
I have run out of speed recommendations.
Here's one more idea on bit manipulation:
The bitwise or math block can combine bit masks without risk of collision overflow, so it is better than the math '+' block for 'or' operations.
I may not be understanding when the '.Touchup' event occurs, but I have the impression that it occurs when your finger is lifted from the screen.
I understand that this is different from "holding" your finger (without moving) on the screen and not triggering a ".Dragged" event for the object.
I'm hoping to come up with a way to send the position while not triggering a ".Dragged" and also not a ".Touchup".
The ".Touchup" will return the ball to the center and mean that there is no byte to send over the bluetooth connection.
The goal is to send the ball position after the ".Dragged" and until the ".Touchup". It should be sent every ~20 milliseconds unless it is "00000000".
You have given me some very valuable suggestions that I will add to the app.
Thank you.
I'll spend some time experimenting with a 'Clock.enable' in the '.Dragged' and a 'Clock.disable' in the '.Touchup'.
Thanks again
Hello Russell
Something you are up against with the Clock Timer is that it using the standard OS timer - low priority and therefore not entirely accurate. If your App is only for your use, you may be able to optimise it to suit your requirements, but if you intend to distribute the App, different phones could differ in performance levels.
Why does your remote control have to send a value so fast? I assume there is more than one value, for different commands. Can you tell us more about your project on the hardware side? Are you using a microcontroller?
Our colleague Anke has developed an extension to yield better timer accuracy:
The app may have a small audience. There is an Arduino robot project call "Your Arduino Balancing Robot" by Joop Brokking. http://www.brokking.net/yabr_main.html I'm building on that design. It uses a second Arduino with a WII nunchuck as the controller. I'm hoping to replace the use of the nunchuck with a smart phone app.
The code on the robot Arduino expects to receive an "action byte" about every 20 milliseconds. The byte uses each of the first 4 bits for 'left','right','forward',and 'reverse'. When the bits are '0000' then the Arduino code slowly brings the robot to a standing stop. The longer any other combination of the bits is received the faster the robot goes. By 'longer' I mean that the same code is received every 20 millisec for a period of time.
Obviously the Arduino code could be redesigned to continuously act until a new byte was received from this app but it would be a big change to that code.
I hope that this provides a reasonable amount of background as to what I'm working on. The app may already have been built - but I couldn't find it.
OK, so if the signal is sent within a range of 15 to 25 milliseconds, that should be OK. You would want to hold a button down, but control the signal send with a timer, so when the button is released, the timer should be disabled. Note, "Timer Always Fires" should be permanently disabled, it's there to allow the timer to continue to work when the App is not displayed on screen, which does not fit your scenario.
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:
https://groups.google.com/d/msg/mitappinventortest/II_RlElGddU/J0q_E-2rAwAJ
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.
See my Website:
https://www.professorcad.co.uk/appinventorsnippets#GetErrorInfo
https://www.professorcad.co.uk/appinventortips#TipsBluetooth
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.
Hi Russell.
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 ??
Regards Antony.