Robot Not a Dev? Buy Now
Not a Dev?

Misty Community Forum

How about a category dedicated to coding with the JavaScript SDK?


I’ve mentioned this before, with little success, so I’m off to Plan B.

Please establish a new category just for people who want to discuss Misty’s JavaScritp SDK … as code … not in terms of hey click this … download that … and you gotta Skill that does stuff.

I ask for a separate category, because Misty’s docs seem to me to be either

i) The Choir singing mostly to the Choir assuming everyone else must know the language they’ve developed over thousands of hours, or

ii) developers assuming everyone else are neophytes who don’t need anything more serious than … just click this … download that … press this , and yahoo, Misty does cool things.

But for what it’s worth, it’s difficult to imagine an approach more at odds than those two possibilities are with the goal of making robotics universally accessible to a broad range of people seriinterested in programming.

Regardless … I’ve read “One specific is worth a thousand generalities” so here a question that would fit will in the new category I’d like to see:

This is from docs:

“Get” Data Callbacks

For “get” callback functions, the callback name is by default set to be _<COMMAND> (you can use your own callback name if desired). So, for example, the default callback function for GetDeviceInformation would be _GetDeviceInformation .

Then it shows this code snipit


function StartMySkill() {

function _GetAudioList(callbackData) {
  var audioList = callbackData.Result;
if (audioList.length > 0) {
  var randomInt = Math.floor(Math.random() * audioList.length);
  var currentSound = audioList[randomInt].Name;

Note also that the docs acknowledge somewhere that Misty’s JavaScript SDK is different. And I can attest it is certainly alien to someone who’s accustomed to Java’s Event/Listener architecture.

So here’s the question I would have liked to share under the new category:

What the heck does (you can use your own callback name if desired). mean?

I assume the commands available in the form of Misty. are set by the API. So how, for example, would Misty.GetAudoData() know _WhatsUp() is the function to which the programmer expects it to provide with the callBackData object?

Or more basically, how do I mentally map Java’s Event handling (events fired by the system, or by external input like a button click, or fired by by the programmer) to Misty’s JavaScript architecture?

May I add that a list of all Get Commands would be nice? Actually a complete list of implemented commands would be nicer.

And maybe a simple mention at the start that Misty’s JavaScript SDK get commands do not return data. I mean if that’s what the example is supposed to convey. Because from the example I can only guess instead of returning data, Misty.getSomthing() commands callback their underscored namesakes and feed it a key/value data object. Yes? No?

Lots more areas where the docs could be make clearer … but all of them boil down to the fact that Misty’s JaveScript documentation is so submerged in ho to do “SKILLS” the drafters aren’t able to just focus on the SKD.

Or said another way, so documenters seem in so much of a hurry to get people “doing cool stuff” they aren’t able to focus documentation of the SDK o the SDK.

Something that would be infinitely more useful to people who are starting from scratch to lay down a serious foundation. Not just swap stuff that makes Misty do things … and then tinkering with code to tweak someone else’s code to sort of do what they want (picking up, and propagating, any flaws, and deviation from best practices.)

But maybe it’s only me who would like to master the SDK first.

But if the goal is to attract a mass of serious programmers from outside the robotic’s choir to pick up Misty and take it to levels as yet undreamed, I’m pretty sure the “just do this and Misty does this” approach is the wrong one.

To me that seem most attractive to making Misty an expensive toy, so I’d push harder to get Misty’s SDK more completely documented at a much higher than current level to make it easier for people from alien code to build a foundation in Misty.

Because just like a small vocabulary limits what a human can conceive of to small ideas, a limited knowledge of a language’s API limits a programmer to conceive of doing with it. At least me thinks.

I know that documentation is time consuming, mind numbing, difficult, but unsatisfying, which is why I assume so few people do it well. Like Oracle after it trashed Java. So I know that no matter what the argument, it won’t be done by those who develop things.

Hence my Plan B – a separate category. How about it?

Else Happy Trails Everyone.
I’m off to decoding Misty’s JavaScript SDK

@piikoicoder thanks for your continued sharing of improvement ideas. I think the Misty Development section of the forums would be a great place for some of the kinds of things you mention.

You can ask specific JavaScript questions there and we’re happy to help. If you think something isn’t working right or need additional support in developing with Misty, then the Developer Support section is your best bet.

Most important however is that you share and post and ask questions. We really don’t care where you do it as long as you do it. Moving topics around is easy for us :slight_smile:

Sounds good. Will do.

Also, @Chris has some ideas he will be sharing with you here, @piikoicoder

@piikoicoder I answered the questions I could in this post

You had some good ones I wanted to make sure people in #development saw.