Closed shakram02 closed 7 years ago
First of all, thank you! I've been looking for this annoying bug for weeks but only had like 1 hour here or there to study it due to the large number of kickstarter orders I have to fill!
The bug you found could easily occur if a bit of static occurred on the bluetooth communication channel after the V1 was read but before the length was read. I did notice in the past during demonstrations that environments that were very bluetooth-noisy were having more random hangups than cleaner environments. One difficulty I had in reproducing this error was that my home, where I do most of my debugging, is too "clean" so this kind of problem doesn't show up much there. Maybe I can figure out some way to make my airwaves dirtier so I can do stress testing on the state machine better.
A better fix In looking at your patch, it is not 100% correct, although it will do the job. It would be better to reset the state to P_WAITING_FOR_HEADER so the rest of the bad packet is flushed away. By simply doing a "break" in the error case, you'll have the state machine keep reading bytes until it finds one less than or equal to 48 which it will take as the length. The resulting packet is sure to be bad (it will be a mish mosh of bytes from the middle of the transmission), and it'll probably also consume part of the next good packet too.
And another fix While reviewing the state machine, I also found one other case where an error was not causing the state machine to go back into P_WAITING_FOR_HEADER as well. This would, in extremely rare cases, when just the right combination of static was in the air, cause the robot to sit there and error chirp continuously until rebooted. Because this error only occurred very rarely, like once every several hours of usage for me, it was just hard to debug.
I am going to unit test both these fixes and will post an update hopefully later today.
And your app People have been calling for an app so best of luck to you! Let me know when its ready to be beta tested and I would be glad to help out.
Full disclosure: we do have plans for our own app, but it's several months away. The more the merrier I say, there are many different ways an app to control this hexapod could be designed, and it's always better for users to have a choice.
It's super strange yes that the bluetooth isn't stable, When I try with a tiny bluetooth code it works like a charm, when I try using the robot's code it goes crazy, I'm not really sure why that happens? I'm aware that android does buffer data, but when I add about 10ms delay when receiving packets are received in a complete manner. What do you think? ( I'm not sure if HC05 provides reliable data transfer, but I never worried about that in any of my previous projects )
Hey guys, Thank you for making you awesome robot open source.
I've found a small but annoying bug, I'm developing an Android app (early stages) that replaces the game pad if you're interested. Sometimes the Arduino went just irresponsive.
Meat and butter
Tracking what happens I found that sometimes the bluetooth packet arrives in pieces, And eventually make the packet length invalid (i.e larger than 48), which makes writes that are out of the legitimate memory locations.