Feature Request: iOS Compatible Bluetooth
Opened this issue · 14 comments
Hey,
As an adjunct to issue #23. I have located an iOS compatible BLE 4.0 board:
https://www.itead.cc/serial-port-ble-module-master-slave-hm-10.html
Multiple Ebay sellers have them for less than $2.50 per piece. It kinda seems like a no brainer to add to any major redesign of the shield. The price (retail) differences of adding BLE on the Audrino side is many times (>10x) this cost.
Beyond the obvious benefits of the average iOS device (computing power, ease of use, install base) as it relates to running GC, having any GC host with a reliable wireless connection + (eventual) spindle control would, in my opinion, add a considerable safety factor to the machine that needs to be considered. (in the context of the ongoing spindle control discussion)
Thinking beyond the firmware, and into an iOS version of GC, take a look at the ARKit and consider how MaslowCNC/GC could "relatively easily" gain Computer Vision, and incorporate camera based safety and accuracy protocols.
Note that the first comment on the product page talks about having bought one of those from eBay and gotten a “knockoff with limited functionality with firmware“.
This unit, while more expensive, is readily available and well supported.
As the BLE module uses the same Tx and Rx lines as the normal USB serial connection, a provision to select between the two - pin jumper or switch - might be useful/necessary.
As a BLE connection is less reliable than a wired serial one, it might be a good idea to link this enhancement to an enhancement for adding stand-alone operation with the gcode stored on-board the Maslow.
Transferring a gcode file and monitoring the machine status seems reasonable to expect from a BLE connection.
I've just committed to purchasing a 'test rig', maslow shield + audrino + BLE module i linked above. I'll report results as soon as I have em and can get em talking. with my goal of getting an iOS build of GC up and running via BLE.
Wish me luck!
Good luck!
Best of luck!
Update:
I've got my testing rig partially together and am continuing research. I have a MaslowShield, KeyeStudio Mega board, and for Bluetooth I selected a [MakerFocus DX-BT16 Bluetooth module](. They're seemingly plentiful, should work fine via BLE to iOS, whereas a number of others seemingly do not, despite advertising they do.
Cables and a breadboard are still a day or 2 away from arrival, and I'm continuing my research on the MacOS/iOS side of things.
This appears to be the best candidate for integration between the exisiting code and BLE code as it can keep as much as possible within python. It doesn't specify iOS compatibility, but CoreBluetooth (Apple's BLE Framework) should hold over between MacOS and iOS,
When building for iOS it appears that python libraries are all packaged into the iOS app (via https://github.com/kivy/kivy-ios) so I'm hoping for a little luck and that this won't be super complex to achieve.
More as I have it.
I think in OS X you’ll be able to talk to the Bluetooth serial port without any other drivers, once it’s been paired. The groundcontrol app should offer to connect to that serial port in its menu available ports.
that's clearly the case with pre-BLE devices as they used the Serial Port Protocol standard (which btw, is unavailable to iOS), but I'm not sure it is the case with BLE (>4.0 devices). iOS needs explicit UUID definitions that may or may not be (i simply don't know) automatically identified by MacOS.
Update: I have all the hardware finally and have started by writing an include for the firmware, "ble.h", to configure the BLE module (and add other BLE chipsets easily).
It then mirrors the USB 'Serial' port and hopefully will not be a problem for GC.
I figure that I'll add a toggle/selector for enabling the BLE module in GC once I get there, but for now I want to make the Arduino respond on either USB or BLE. I should have it all cleaned up and integrated into a Firmware-BLE branch tomorrow.
Moving on to new MacOS and iOS forks of GroundControl:
I can currently see the BLE module using BLE sniffer apps on both MacOS and iOS, but I cannot see them in the SystemPrefs/Settings apps. This might be a MFi (made for mac/ios) licensing thing, and the app will have to manage that stuff, I dunno yet.
For MacOS, I have successfully installed pyobjc and can see a big long list of apple's CoreFrameworks (inc CoreBluetooth) in pip (/usr/local/bin/pip). I hope to have an initial BLE enabled MacOS build of GC next week sometime.
For iOS, the Kivy-ios packager wants its own python that it inserts into the iOS app and I haven't figured out how to add packages to kivy-ios's python build yet. Kivy-ios needs to build for various architectures from there, so it's a showstopper if I can't get pyobjc (and the apple CoreFrameworks) into the kivy-ios python. If I can, and it works (there's no documentation I've found that says so either way at this point) we're probably good to go.
GCwants to see data received from the firmware every 200ms or so, or it decides it has lost the link.
On the Mega, will you be using the same rx/tx lines that the USB serial connection uses?
yeah, timing and Baud rates were a question that I was going to wrestle with shortly. Currently GC sets the Serial speed to 57600, iOS and Android want 115200.. I figured some timing issues might pop up if i force the firmware to the faster rate.
As for the pins I'm using, I can use 0 and 1, but i think its a better idea to use other pins, I have them currently on pins Maslow would use as I'm just making sure I have the variables and strings all correct to easily re-configure and reset the bluetooth module. I was going to move them to an unused set, i was thinking 50 and 51. so I didn't use up anything already in use.
It's not optimal that the firmware currently uses all 3 of the Mega's added Serial ports for the motor controllers, but from what I see its not a big deal right as it relates to adding BLE. I have read though, that it's possible to send multiple control signals via a single pair of pins. Perhaps that's worth looking into for the next shield revision, It'd be good imho to free up those serial pins.
Back to the link-connection-timeout stuff, I'm sure it'd be possible for the firmware to kick out data at a rate that maintains the BLE link, or instruct GC to expect how the BLE link prefers to behave. I think it's telling that GC drops the link often enough with a wired connection, those issues should be solved independently of adding BLE. But i'm not a 'real' dev so I don't really know for sure. =)
I think the 200ms timeout is arbitrary, but it could be confusing if it was kicking in.
Before you get too far, I would recommend testing how reliable the bluetooth connection is when a router is running. DC motors produce a lot of broadband RF noise and the bluetooth connection may or may not work.