The iOS version currently only supports Bluetooth LE connections. (Apple does not make it easy for people to publish apps that make use of regular Bluetooth).

Like the Android version, the app has speech synthesis, and computer vision. (It has the peek-a-boo functionality and also the ball tracking functionality.)

However, the iOS version also doesn’t currently support voice recognition. This is something I’m still trying to figure out a solution for.

I’m still tweaking and testing this version of the app, but I’m planning to release it on the iTunes store soon.

Most of this weekend has been spent updating the code to use the latest versions of all libraries, and also updating the app to the latest version of Unity (5.4).

Things are looking good after the updates.

• OpenCV is now using OpenCV 3 and is working well
• Voice recognition seems to be working well
• Speech synthesis is working fine
• Regular Bluetooth connection is working well

However,

• Bluetooth LE still seems unreliable when using Android 6. (It is working OK most of the time on Android 5.) I am continuing to look at this and am currently looking at redoing this code completely.

I’m hoping to have these maintenance updates completed soon. Then I’ll be working on extending the app. I have a lot of ideas for new functionality and interactions that I want to implement.

I’m excited to finally get an iOS version out soon (finally!). I know quite a few people have been asking for it, so I apologise for taking so long. The iOS version won’t have voice recognition initially, but the other features should be there.

I’m hoping to get these updates completed this week and will upload new versions to Google Play and hopefully also iTunes.

Also, check out his Github page for more details about the app and also the course that he is creating.
https://github.com/tharvey/BlocklyBot/wiki

Really fantastic project!

You can read more about it here:  http://www.cevinius.com/mobbob/#comment-989

I am looking forward to checking it out!

DFRobot does provide example iOS and Android projects. However, as I was making my app with the Unity game engine. I could not use that directly.

So, I ended up going through the example Android and iOS project examples provided by DFRobot to “reverse engineer” information about the Bluno’s pass-though serial service/characteristic.

This post is a write up what I figure out (back when I first started working with the Bluno). This information should be useful for anyone who wants to connect to the Bluno by means other than a standard iOS/Android app.

(I’m writing this to answer Pablo’s question: http://www.cevinius.com/2015/09/19/detailed-mobbob-build-instructions/#comment-987. Let me know if this helps. I connecting using Bluetooth LE.)

At the time, I was brand new to Bluetooth comms and didn’t even really know how Bluetooth LE differed from regular Bluetooth.

The examples provided by DFRobot were based about using Bluetooth LE “GATT”.

After studying the supplied Android/iOS code, reading up on GATT, and some trial/error, I figured out how to use the Bluno’s GATT Services/Characteristics for doing serial communication.

The service and characteristic to use for serial comms is:

Service UUID :  0000dfb0-0000-1000-8000-00805f9b34fb
Characteristic UUID : 0000dfb1-0000-1000-8000-00805f9b34fb

Note, the above UUID were reported back by Android when I queried the Bluno. When I queried it from iOS, the Service/Characteristic were identified by:

Service : DFB0
Characteristic  : DFB1

That should be the main pieces of information you need to start talking to the Bluno!

Sorry it took so long, but I’ve uploaded some new MobBob parts to Thingiverse.

Nexus 6 Phone Holder:
This part is a phone holder designed for the Nexus 6 (that accounts for its curved back).

http://www.thingiverse.com/thing:1566146

It looks giant next to the Nexus 5 version!

Bluno Beetle Backpack:
This set of parts form a “backpack” that fits onto the V2 mounting points that is designed specifically to fit a Bluno Beetle.

http://www.thingiverse.com/thing:1566136

Let me know if you try these parts out for yourself! Have fun!

Kevin

Now that I’m settled into the new place, I’ll be doing app updates and designing new robots again.

I have been working on some hardware updates to MobBob and I’ll post details (and STLs) soon!! Here’s a sneak peak of this update… This MobBob iteration has a Nexus 6 phone holder (Phablet!) and with a newly designed case for the Bluno Beetle to keep the wires hidden away and tidied up!

What I found was that the app would sometimes have difficulty connecting to MobBob. And even after it manages to connect, the connection would be lost after one or two animations.

“Dana Hom” posted in the blog comments about a similar issue, so I thought I’d post how I solved it in case it’s helpful to other MobBob builders!

It turns out, the problems went away after I used the Bluno Beetle’s AT command “AT+SETTING=DEFAULT” (The DFRobot website has detailed instructions on how to do this: Link)

I’m guessing that either the Bluno Bluetooth settings were never initialised properly during manufacture, or they got corrupted at some point before reaching me. This command seemed to correctly reset the Bluno’s bluetooth configuration.

Using that command seemed to fix the issues I was having. After doing that I was able to connect and had MobBob walking around my desk for about 10-15 minutes straight without any connection problems.

So, if you are having connection problems, give this a try!

Cliff posted the following question in the comments section:

Dear Cervinus;

I am developing a robot based off of the poppy robot chassis. I am not using the expensive dynamixel motors and am beating my head against the wall trying to learn programing. Sort of cart before the horse issues mostly. I’m switching gears and going to build a simpler biped to learn more.

I like the autonomous aspects of your robot and the voice recognition, vision from camera and usage of smartphone sensors etc in your app. Granted this is an as I learn more question can the app be modified to add more leg servos and arms gripper? Is that all in the arduino code or the android app as well?

Awesome project can’t watch to get started and have my Samsung s4 dance around on the table.

Thanks

Cliff

I started writing a reply in the comments section… but it got fairly long and I started including some information that might be useful for other people who may be thinking about other bodies for MobBob. (E.g. Earlier in the week, I saw a MobBob remix on Thingiverse (created by user Zalophus) with arms!)

So, I decided to turn the answer into a post.

Hi Cliff,

If you are learning programming at the same time, I think a simpler biped is a good choice. I think getting Poppy to walk and balance will be very challenging. (It seems like Poppy’s developers are continuing to work on it too.) A simpler biped like MobBob still takes fair amount of programming, but at least you don’t need to worry about balance that much. It’s mostly about smooth motions.

The way I have divided the code up in MobBob is as follows.

The Arduino receives “high level” commands from the app and handles all the details of movement. For example, its command set includes things like “Take a step forward”, “Take a step to the left”, “Bounce up and down, three times”, etc. The app sends these commands to the arduino, and the Arduino code will smoothly drive the servos to do that animation/action.

(Note: The Arduino code does have a command for moving the servos to specific positions. So in theory, an app could make MobBob move in new sequences that are not in the Arduino code’s command set. However, I think this is a harder way to do things unless the app specifically requires dynamic movement sequences that are composed at run time.)

Because the Arduino code handles the details of movement (e.g. how to move the legs to take a step), the app doesn’t need to worry about those details and can focus on interactions with the user. The app’s job is to handle the vision, voice recognition, touch screen interactions. It then sends commands to the Arduino to get MobBob to move when needed.

(Note: It is also possible for the app to request the Arduino to send back sensor readings (e.g. for a distance sensor connected to the Arduino), but I’m not using this currently.)

This is not the only way to divide up the responsibilities between Arduino and App, but I’ve chosen this way for MobBob as I wanted to make it easier/quicker for people to develop new MobBob apps.

With this architecture, people can develop a new app for MobBob without worrying about the details of how to get MobBob to walk, etc. The app developer only need to focus on AI in the app and how the app should interact with the user.

So… with that background information… I’ll return to your question…

Theoretically, if you have a different bipedal body (e.g. more joints on the legs, moving arms, etc), you could write new Arduino code which understands the same command set as MobBob. (E.g. take a step forward, bounce up and down, etc) If you then use the existing app, when the app sends the Arduino command to take a step forward, the Arduino can interpret that command in its own way and take the step in the way that’s suitable for its new body.

This means it should be possible to use the existing app with other bodies.

If the arm movements are purely for fun, they could be included in some of the existing commands. E.g. the command to “Bounce up and down” can now make him also move his arms up and down at the same time as his legs.

If there is a need for new, specific arm movements (e.g. do a grabbing motion), then the app will need to be updated as it doesn’t currently know about that command.

Of course, when building robots, there are always hiccups… different bodies means different durations for steps, turning different amounts, etc… So, some tweaks to the app will probably be needed…

In my grand vision of “How Cevinius Takes Over the World”… I would like something akin to the MobBob command set and the way of transmitting them (e.g. Bluetooth) to become some sort of “standard”. Then people could create a bunch of different bodies that can understand those commands, and create a bunch of apps that drive the bodies using those commands… With a standard command set in place, these different Apps and Bodies should mix and play together mostly.

It would allow robotics-oriented people to focus on creating cool new bodies (and write Arduino code to drive those).

It would let AI/game/application-oriented people  focus on creating fun, awesome apps for robots.

With a standard in place… you could potentially use an app created by one developer together with the body created by another developer.

However as I said before, there will no doubt be hiccups (i.e. problems to solve) before we can have this Utopia where installing a new robotics apps onto your custom robot is no harder than installing a new phone app onto your specific-model phone… but I think working towards something like this would be fantastic.

Sorry for the long rant… I hope that answers your question? If not, post below and I’ll try again!

Cevinius