There were some questions about this elsewhere, and I figured it would be good to break out the discussion into its own thread.
(Tagging @Stev as the person who asked about this).
I don’t have any experience using BLE on a Raspberry Pi, so I’m not sure how much work is involved, but it would be a cool supplement to the existing Python SDK. The SDK really only requires a TTY that will pass a stream of bytes to and from the robot. I have done this with our in-house USB BLE dongle for R&D purposes, but I had to basically set up the connection first, then hand the TTY to the SDK.
Next week I could put together some background info on RVR’s BLE connection to help anyone who’s interested.
Cool. Would also be interesting to know if we have some UART/message port equivalent on the GATT level, so that we could also access that from iOS or similar.
I am not sure if iOS meanwhile has support for SSP on the basic layer. Would be nice if we could have access direct app level support without Apple’s MFi programm and without having to put some HW controller in between as a BT to UART broker.
Not sure how the edu app handles the command connection, but if there something (code) to share there…
Well I was going to put together some information about BLE connections, but then @btelman96 posted a link to his GitHub for an Android app that controls RVR over BLE. RVR and telepresence setup That could be a good option to look at for a starting point. Once you establish the connection, any data written to the API characteristic will be handled exactly the same as if it came in through the UART (aside from some address tracking that allows us to route responses back to the original sender of a command). That’s what @btelman96 is using.
Hopefully that gives you what you need. You’re definitely much more knowledgeable than I am about the iOS side of things, I’m purely on the embedded side (and more on the motor control and sensors side of that than BLE communications)
Actually I wanted to control the RVR via BLE without a Pi but used the Pi SDK (referenced above as the current SDK implementation for the new firmware) to look at the methods calls.
So I got stuck there…
Is the pure BLE path/spec documented somewhere or do I have to re-engineer from an older SDK?
Any detail on that one? I found a GATT service, not sure about its characteristics, though.
Hey @Stev. The UIUDs are as follows:
- API v2 Service: 00010001-574f-4f20-5370-6865726f2121
- API Characteristic: 00010002-574f-4f20-5370-6865726f2121
The characteristic supports Write Request and Write Command for sending data to the bot and Notification for receiving. In most cases, Write Command should be fine (and much faster). Notification must be explicitly enabled after connection by sending a 1 to the API characteristic’s Client Characteristic Configuration Descriptor (UUID 0x2902 under the API characteristic).
The API packet specification is published at sdk.sphero.com/docs/api_spec/general_api. We have not yet published individual command specs, but several people have figured those out by reading through the other SDKs. The Python SDK in particular is a pretty good source; it’s the most complete and up to date.
thanks, that should do the trick. I started with the Python SDK and digged through to the bottom. With this info on top (or below), and the System Manual @Sphero_JimK linked in RVR Firmware + Python SDK Update Now Available the picture looks quite complete. One never figures out those hidden enable flags
Will give it a try.
Thanks again to both of you
Hello…i would like to add little here with my experience. In the event that you plan working principally with an independent Raspberry-Pi and RVR, this will be a decent method to pick up understanding, without the overhead of learning the subtleties of offbeat programming. The name onlooker alludes to the product plan guideline executed in that rendition of the SDK. Basically, RVR is the “onlooker” of the information being composed and perused from sequential port, and dispatches “occasions” that your code is tuning in for, normally as callback capacities alluded to as “handlers”.