Greetings!

If any of the info on this website was useful for your projects or made your head spin with creative ideas, and you would like to share a token of your appreciation- a donation would be massively appreciated!

Your donation will go to my Robotics Fund, straight towards more sensors, actuators, books, and journeys. It takes a lot to continue building these robots, and I’m really thankful of everyone who helps encourage me along the way.


USD


CAD

“A wise robot once said to me through Serial.println- that robots teach us about ourselves.”

Buddy 4000 + BLE App (work in progress)

We’ve been long awaiting the days when communicating to our robots from an iOS device would involve less jumping through hoops! BLE on the newer iOS devices is pretty sweet.

Here is a video demo of our app interacting with Buddy 4000 using BLE!

We’ve been working on this off and on for a few months. Actually, half of the core functionality was finished a while ago (sending data from the iOS device to the robot). The BLE module we were using wasn’t configured properly to send data from the robot to the iOS device, and we didn’t have a TI CC debugger needed to re-program the BlueGiga chip so yeah… When we heard that @sectorfej had new modules in his InMojo store, we quickly bought one!

Here is the BLE module (wires are 5V, GND, TX, RX):

ble_buddy_wip 004

There’s a great BGLib library for this module that has all sorts of features packed in to it. There wasn’t much documentation about sending data… Here’s how to do it:

  1. ble112.ble_cmd_attributes_write(20, 0, data_len_var, data_var);

The number 20 is the hard part. We couldn’t figure out where to find the info about this number or anything… so we iterated from 0-49 to find it! You might have to do the same for yours as well. Just keep an eye open on Xcode for when data is received on the app side, and then narrow down the numbers until you find the one that works.

We didn’t show this in the video, but we use sending data from the robot to the app for triggering sounds. Specifically owl and fart sounds. (Yes, this might be the most complex fart app to date). It works better with RoboBrrd, as it has sensors that can be used to trigger the sounds.

Anyway, most of the ‘core functionality’ of the app is involved with this (below) and the communication. We can even make it auto connect to a particular device (as you saw in the video), which makes the experience even more seamless.

ble_buddy_wip 003

Here is how auto-connection is done. We save the UUID and name of the device, then check if we see that specific one:

  1. - (void) connectToDefault {
  2.     // ok, let’s try this
  3.    
  4.     if(connected) return; // already connected don’t do anything
  5.    
  6.     NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
  7.     NSString *givenUUID = [userDefaults objectForKey:defaultDeviceUUIDKey];
  8.     NSString *givenName = [userDefaults objectForKey:defaultDeviceNameKey];
  9.     //CBUUID *zeeUUID = [CBUUID UUIDWithString:givenUUID];
  10.     CFUUIDRef zeeUUID = CFUUIDCreateFromString(kCFAllocatorDefault, (CFStringRef)givenUUID);
  11.    
  12.     int i = 0;
  13.     for(CBPeripheral *periph in allPeripherals) {
  14.        
  15.         if(periph.UUID == zeeUUID) {
  16.             NSLog(@"same UUID");
  17.             if([periph.name isEqualToString:givenName]) {
  18.                 NSLog(@"same name – let’s try to connect");
  19.                 self.peripheral = periph;
  20.                 [bleManager retrievePeripherals:[NSArray arrayWithObject:self.peripheral]];
  21.             }
  22.         }
  23.        
  24.         i++;
  25.     }
  26.    
  27. }

Sometimes specific BLE modules have certain service UUIDs and characteristic UUIDs that you can only send data to. We’ve never experienced a problem with ‘spamming’ everything (yet), but we built in this feature just in case. This is when data is being sent from the app to the robot.

  1. CBUUID *uuidService;
  2.     CBUUID *uuidChar;
  3.    
  4.     int ss = [selectedShield intValue];
  5.    
  6.     switch (ss) {
  7.         case 0: {
  8.             // any
  9.             uuidService = [CBUUID UUIDWithString:roboBrrdServiceUUID];
  10.             uuidChar = [CBUUID UUIDWithString:roboBrrdCharacteristicTXUUID];
  11.         }
  12.             break;
  13.         case 1: {
  14.             // kst
  15.             uuidService = [CBUUID UUIDWithString:kstServiceUUID];
  16.             uuidChar = [CBUUID UUIDWithString:kstCharacteristicTXUUID];
  17.         }
  18.             break;
  19.         case 2: {
  20.             // dr kroll
  21.             uuidService = [CBUUID UUIDWithString:drkrollServiceUUID];
  22.             uuidChar = [CBUUID UUIDWithString:drkrollCharacteristicTXUUID];
  23.         }
  24.             break;
  25.         case 3: {
  26.             // redbear
  27.             uuidService = [CBUUID UUIDWithString:redbearServiceUUID];
  28.             uuidChar = [CBUUID UUIDWithString:redbearCharacteristicTXUUID];
  29.         }
  30.             break;
  31.         default:
  32.             break;
  33.     }
  34.    
  35.    
  36.     for(CBService *aService in self.peripheral.services) {
  37.         if([aService.UUID isEqual:uuidService] || ss == 0) {
  38.             for(CBCharacteristic *aCharacteristic in aService.characteristics) {
  39.                 if([aCharacteristic.UUID isEqual:uuidChar] || ss == 0) {
  40.                     [self.peripheral writeValue:sendData forCharacteristic:aCharacteristic type:CBCharacteristicWriteWithResponse];
  41.                 }
  42.             }
  43.         }
  44.     }

This also allows us to do certain actions for different shields. While going through the example code for the RedBear BLE shield, we noticed it needed a ‘reset’ (or something). We haven’t tested this yet, but hopefully it will make the RedBear one work:

  1. if([selectedShield intValue] == 3) { // redbear shield is weird
  2.        
  3.         CBUUID *uuidService = [CBUUID UUIDWithString:redbearServiceUUID];
  4.         CBUUID *uuidChar = [CBUUID UUIDWithString:redbearResetRXUUID];
  5.         unsigned char bytes[] = {0×01};
  6.         NSData *d = [[NSData alloc] initWithBytes:bytes length:1];
  7.        
  8.         for(CBService *aService in self.peripheral.services) {
  9.             if([aService.UUID isEqual:uuidService]) {
  10.                 for(CBCharacteristic *aCharacteristic in aService.characteristics) {
  11.                     if([aCharacteristic.UUID isEqual:uuidChar]) {
  12.                         [self.peripheral writeValue:d forCharacteristic:aCharacteristic type:CBCharacteristicWriteWithResponse];
  13.                     }
  14.                 }
  15.             }
  16.         }
  17.        
  18.     }

The above is called whenever data is received by the app- eg:

  1. peripheral:didUpdateValueForCharacteristic:error:

When it is all working, it’s really fun to interact with the robot in this way!

ble_buddy_wip 002

There are still some wonky things that happen. For example, if you send too much data- or if you send it at the same time. Sometimes we don’t even know what we did and it will just disconnect (though thanks to our code, it re-connects quickly and without interrupting the user). This happens infrequently, so it might be odd cases.

Special thanks to @macisv, who at SecondConf last year taught me lots about BLE and let me experiment with it! And of course @sectorfej for making this great module that we used :)

Now for the hard part: completing and releasing it. It’s kind of weird, even though we are using this quite often… we have kind of come to dislike this interaction (of pressing and holding buttons) because it’s quite boring. So we’re not sure yet if this one will be finished, or if we’ll be trying something else, perhaps with more gestures and such.

ble_buddy_wip 001

More fun coding ahead! :D

2 CommentsLeave a Comment


  • Sridhar Rajagopal

    6 months ago

    Hi,

    Thanks for your article! It is well written and informative. I came upon your page when looking for more details of ble112.ble_cmd_attributes_write(handle, offset, data_len_var, data_var). It helped me get past my stump and know where to look. Here’s what I found, which I thought would be interesting to you:

    The number 20 is actually the GATT_HANDLE_C_TX_DATA (defined in the bglib_stub_slave example). The characteristics and their corresponding IDs are defined in the gatt.xml for the ble112. I found a website that explained how to convert the ID of the characteristic into a handle, so understanding the connection between the two, I figured GATT_HANDLE_C_TX_DATA was the handle, which your “20″ first hinted at!)

    Cheers,
    Sridhar

  • Sridhar Rajagopal

    6 months ago

    Another lesson I learned – the uart serial link can easily get overwhelmed if the data is sent too often – and if that happens, communication just hangs as it is a blocking call. I found I could easily send data once every second. Just be careful if you go to sub-second frequency! :-)

Leave a CommentPlease be polite. We appreciate that.

Your Comment