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!

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

PopPet’s app is now on Google Play:

https://play.google.com/store/apps/details?id=com.cevinius.PopPet

Also, the Arduino code to use with the app is now on GitHub:

https://github.com/cevinius/PopPet

This should make these easier for everyone to find and install! Have fun!

PopPet is a robot kit developed by Jaidyn Edwards. In collaboration with Jaidyn, I’ve been working on an app for use with PopPet. This app was designed for use with PopPet 2.0, but I’ve been testing it with my modded Kickstarter PopPet.

You can find out more about PopPet here: http://www.poppettherobot.com/

The app lets you:
– Drive PopPet around (app works like a remote control)
– Give PopPet voice commands
– Tell PopPet to drive around autonomously and explore

The artwork in the app was created by Jaidyn Edwards.

Jaidyn will be demonstrating this and PopPet 2.0 at the “Adelaide Mini Maker Faire” (in Australia) this weekend (Sun 1 Nov, 2015). So, go check it out if you can!

Where to Get the Code

You can get the Arduino code from GitHub:
https://github.com/cevinius/PopPet

You can get the app itself from Google Play:
https://play.google.com/store/apps/details?id=com.cevinius.PopPet

Some Technical Details

The app is based on the stuff I did with my MobBob and Sphero Companion projects, so it shares some similar features.

Arduino Code

For anyone familiar with how MobBob works, MobBob’s Arduino code accepts text-based commands over bluetooth. For example, the command to walk forward 1 step looks like this <FW,1>.

To support PopPet (and other wheeled robots!), I wrote a new Arduino program that accepts a new wheel-based command set:

<DW,#,#> – Drive Wheels where the parameters are motor speeds for each wheel

<LW,#> – Set the speed of the left wheel only

<RW,#> – Set the speed of the right wheel only

I’ve also added commands for some of PopPet’s Ultrasonic Sensor:

<UA,#> – Turns the Ultrasonic Sensor on/off

<US> – Requests an ultrasonic sensor reading.

And I’ve also added a command for the explore mode.

<XA,#> – Turns explore mode on/off

While explore mode is activated, PopPet will send the following response codes to let the app know what’s going on:

<XO> – Encountered an obstacle
<XC> – Changing direction just for fun (got bored going straight)

Initially, I didn’t put the explore mode in the Arduino code. I first tried to do it all on the app. The app would receive regular sensor readings, and then adjust PopPet’s course.

After some testing, I found that doing it that way had too much lag… Sometimes PopPet would hit the wall before he received the commands to back up and turn. I’m pretty confident the lag can be reduced by tweaking some of my delays between sending/receiving commands. (I’m probably overly paranoid about not spamming the serial port with commands… I think it can handle much more than what I’m throwing at it.) If I play with these settings, an app-side explore mode should work fine.

However, I decided to change tactics and put the explore mode into the Arduino-side code. This has a few advantages:

• PopPet can continue to explore even if you turn off your phone (after you’ve started the explore mode)
• The app is freed from driving and can do other stuff! While in Explore Mode, PopPet sends status codes <XO> and <XC> to the app to let it know what’s going on. Since the app isn’t busy driving PopPet, it has time to handle these status codes and react. In the current version, I have PopPet occasionally saying something (E.g. “Something’s in my way”, etc) in response to these codes. I found this can be a bit annoying, so I also added an option to turn off the explore mode narration!

Because this command set is pretty generic, it should be applicable to most differential drive robots… So, this Arduino code and the App should work with other differential drive robots!

If you are using a Dagu Mini Driver as the microcontroller, you can probably run my code as is and it’ll work… If you are using a different microcontroller and motor-controller, you may need to make some small changes to the pins, etc.

You’ll also need to have a bluetooth module connected to your microcontroller!

Android App

The Android app is based off a similar code-base to my other apps. I’ve tested with Nexus 5, Nexus 6 and a Samsung S6. It should work with other phones too.

You need to have the phone language sent to English for the voice recognition to work. Also, if voice recognition is not working, check if voice recognition is working in Google Now’s voice search. (If it’s working there, it should work in the app.)

Further Work

This project was done for Jaidyn’s PopPet, and the artwork matches PopPet’s web page, etc.

However, since the Arduino code and App are compatible with most differential drive robots, I will be releasing a non-PopPet-specific version of the app at some point (when people request it, or when I need it for my own projects… whichever comes first).

This work provides an easy way for robot builders to add a remote control and voice recognition to their robots!

Have fun!

As always, feel free to post comments if you have any questions or would like more information!