Support Rover's Bluetooth Connection

[rirze]

See if existing SerialDevice can support such functionality. Original Issue now relocated to #14

Support sending commands over to Mirobot's rover bluetooth module. (Regular BT, not BT LE.)

[JorisvanDamTUD]

Not sure if this would already be capable of working, but I made some attempts anyways to connect with my rover/mirobot over (serial-over)bluetooth using this library. But perhaps the (odd) behaviour of the serial interface I describe below can be helpful in getting the BT functionality in mirobot-py working.

Short summary: bluetooth controlling the rover (and arm) over a standard TTY terminal works, with many quirks however, see below

control with mirobotpy library not yet, probably due to unexpected messages coming back from the grbl firmware on the rover shield and/or serial interface problems (e.g. exceptions due to 'expected letter command'). I suspect these throws the exceptions in the pyserial lib, which make py code stop.

Here are some findings:
A) serial terminal

• I can connect to¬ the BT module (on the rovershield) with PuTTY, over a serial over Bluetooth com port (win10 laptop)
• rover commands via PuTTY to the Rover work (e.g. ‘W8’and ‘W0’ for forward stop)
• However, communication with the rover/arm/shield seems to be interfered by either buggy grbl firmware or serial communication errors: very often a command like $H reponds in ‘error: Expected command letter” or ‘error: Bad number format’
• Command ‘?’ returns the status as usual, but is always truncated‘ <Alarm,Angle(ABCDXYZ):0.000,0.000,0.000,0.000,0.000,0.000,0.000,Cartesian coordinate(XYZ RxRyRz):202.000,0.000,181.000,0.000,0.000,0.000,Pump v’
• Gcode command for arm movements do not work, all throw a ‘Expected command letter’ error
  B) Android serial terminal app
• same results
  n.b. after connection start, the rover always first send acknowledges ‘error: Expected command letter” followed directly by ‘error: Bad number format’

C) Test with mirobot-py lib:

• Attempt to connect results in:
  [COM13] [DEBUG] Attempting to open serial port COM13
  [COM13] [DEBUG] Succeeded in opening serial port COM13
  [COM13] [ERROR] 'utf-8' codec can't decode byte 0xfa in position 0: invalid start byte
  Traceback (most recent call last):
  File "c:\downloads\mirobot-py\mirobot\serial_device.py", line 99, in listen_to_device
  msg = str(msg.strip(), 'utf-8')
  UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfa in position 0: invalid start byte
  [COM13] [DEBUG] Attempting to close serial port COM13
  [COM13] [DEBUG] Succeeded in closing serial port COM13

Process finished with exit code -1

Code used:
#!/usr/bin/env python3
from mirobot import Mirobot
import time
with Mirobot(portname="COM13",debug=True,wait=True) as m:
#time.sleep(10)
m.home_simultaneous()

[rirze]

Thank you for the detailed report!

I will definitely pour over this more in the next few days. While I originally opened this ticket for dealing with the arm over Bluetooth, including the rover functionality might be related as well.

Initial thoughts:

1. I don't have a rover, so much of the stuff I've implemented is theoretical on how this stuff stitches together.

2. I'm still unsure if the rover interface is a separate serial interface from the mirobot. If they are separate, then I need to rewrite the code (from your report, it seems like they are?).

3. You've mentioned command inputs are inconsistent-- could you clarify for me? Does it work sometimes or not at all?

4. If you get the same results from the Android app, then I'm not sure there's a way to get this behavior implemented presently. Generally, my guiding principle for this library has been to build on fundamental actions that can be performed with the Mirobot. If WKlata hasn't shown a way to perform these basic operations consistently, I'm not confident I'll be able to reverse-engineer a solution.

5. That status string is definitely concerning-- I'll have to consider that when dealing with rover operations.

6. The one thing I can do is look into the decoding error and see if there's some clever handling I can do to mitigate this.

Will reach back soon.

[JorisvanDamTUD]

Here are already some of my answers, see below:

1. don't have a rover: I understand, so I really appreciated your efforts. I can do testing offcourse, as Im really hoping to get the wireless operation and rover python coding working (because only cable tethered rover operation doesnt make much sense :) )

2. separate serial interface?: I think the system was designed to work as followed: bt on rover shield receives all commands for both rover and arm, rovershield operates the wheels if commands are for rover (eg. W8 or W0). For all other commands the firmware on rovershield forwards these commands to arm. over the 2-wire rxtx cable and extenderbox. I will ask Wlkata to publish rover firmware and details on interface. So, my conclusion now is there are not separate interfaces for rover and arm, but rover board is the master that forwards to arm.

3. Are command inputs are inconsistent?: for non rover commandsn i have had several occassions on which a $H command (send to the rover bt) does make the robot do homeing, but it only works after many repeated resends. So this would only work by resending $H command several times, the first couple of resends will result in errors ("exspected number" or the other error) and then suddenly the next resend will work, and the arm homes.

There seemed to be no structure in number of resends I had to do (sometime 3x, sometime 5x).

Possible explaination: It seemed to me that due my first sending $H, the rover grbl firmware gets into some kind of specific 'input state' in which it expects (and wait for) a specific input, but doesnt receive this as it gets the $H again. After several resends, the firmware then goes into the 'normal' state and can interpret $H correctly. But this is just a guess.
The reason that none of the 'M20 G21 .....' commands work could be that these commands have to be preceded with some unknown character or code. Or spaces should be replaced by underscores or whatever.

Getting the firmware from Wlkata hopefully will clear this all up. Ive looked at the arm firmware, and that based on standard CNC/GRBL code and much of this code is still in the Mirobot firmware and might lead to these unexapected behaviour.

[rirze]

Alright, so one step at a time:

I've uploaded a new commit that hopefully fixes the EncodingError-- let me know if you get past that error and see the same failures as you'd expect from the Android app.

[JorisvanDamTUD]

Thanks, the newest commit indeed seems to solve the problem with the encoding error, when using mirobot-py to serial interface. The python mirobot-py lib output now resembles the sequence on Android:
[COM13] [DEBUG] Attempting to open serial port COM13
[COM13] [DEBUG] Succeeded in opening serial port COM13
[COM13] [DEBUG] [RECV] error: Expected command letter
[COM13] [ERROR] Expected command letter
[COM13] [DEBUG] Attempting to close serial port COM13
[COM13] [DEBUG] Succeeded in closing serial port COM13

So, one step done!

[rirze]

Ok, that's good to hear!

Now we have a baseline-- this library is producing the same results as WKlata's existing functionality.

Correct me if I'm wrong: The next step is wait for WKlata's solution to this problem or release of rover firmware. Is there anything else I can do to alleviate this issue?

[JorisvanDamTUD]

To investigate the sequence that seems to trigger the errors some more, I looked at the message stream with Realterm and captured the output. After making the connection (bt over serial to the rover) output is:
"5-5-2020 16:55:55",error: Expected command letter
"5-5-2020 16:55:55",ok
"5-5-2020 16:55:55",error: Bad number format
"5-5-2020 16:55:55",ok
"5-5-2020 16:55:55",ok
(timestamps are added by Realterm)

I also did a hex output (text after the '>>' is my translation, to better understand sequence)
"5-5-2020 17:01:02",6F6B0D0A >> ok
"5-5-2020 17:01:02",6572726F723A20457870656374656420636F6D6D616E64206C65747465720D0A >> error: Expected command letter
"5-5-2020 17:01:02",6F6B0D0A >> ok
"5-5-2020 17:01:02",6572726F723A20426164206E756D62657220666F726D61740D0A >> error: Bad number format
"5-5-2020 17:01:02",6F6B0D0A >> ok
"5-5-2020 17:01:02",6F6B0D0A >> ok
"5-5-2020 17:01:07",6572726F723A20457870656374656420636F6D6D616E64206C65747465720D0A >> error: Expected command letter
"5-5-2020 17:01:07",6F6B0D0A >> ok
"5-5-2020 17:01:07",6572726F723A20426164206E756D62657220666F726D61740D0A >> >> error: Bad number format
"5-5-2020 17:01:07",6F6B0D0A >> ok
"5-5-2020 17:01:07",6F6B0D0A >> ok

n.b. the hex-ouput seems to have some more output lines , and also an additional 'ok' at startup. Not sure if this difference is due to two separate capture sessions (can t do them simultaneously) or some decoding issue in Realterm

Will do some more testing later

[JorisvanDamTUD]

:)) LOL i think i figured it out.....

I decided to just do a bit of 'brute force' attempt....... I figured there probably had to be some kind of preceding character that the firmware expects. So i just opened another tty terminal and just wacked every key on my key board followed by Enter for a while.

The "~' plus enter is always followed by 'ok'. so, following up on this, I tried to input some Gcode command, but this time without space. so '~M20G91X10'

And that works!! Arm is moving

So I think the trick is to just have every command send to rover/arm begin with an '~' followed by the commands, but without the spaces. Offcourse the latter being quite a pain I suspects, as this is different from normal/direct arm command sequence.

[rirze]

I have so many questions.... but first, nice find!

To clarify, ~M20G91X10 works but ~M20 G91 X10 doesn't? I can change this, but .. I don't like the lack of readability.

If you can make sure this consistently works with all sorts of other commands, I can rig something together in the library to make this behavior possible.