RCB3 C API (for KHR2 and MANOI AT01)

[shsan]

Hi guys,

I have done my first successful test with my C API for the RCB3.
It's only 2 functions right now but the communication system is working.
I will implement the rest during next week.

I will do a release of it by next Saturday or Sunday.
If someone is interested in doing some beta testing in the meantime please contact me.

I will try to make it as clear and simple as possible but there are some area where you will still need some knowledge about the RCB3 manual.

All tests will be done with a KHR2 since I don't have a AT01.

Shsan

[edmen]

nice work!, send me what you have ill be happy to beta test it

[shsan]

Edmen,

I'll do that soon.

[PaulP]

Seems there are a few people working on an API, each with there own agenda. I've been playing myself with the serial commands in VB.NET 2005 on the .NET Framework 2.

Is there any mileage in discussing what each hopes to achieve from their API and try and standardise the calls across the different languages?

Also, am I right in thinking that as KHR-2, KHR-2HV, KHR-1HV and Manoi use the RCB3 or a derivative, that anything that gets written would be useable on all of them? or are there some differences that would need to be catered for between the robots?

[Robotique]

Microsoft have provided an API for the KHR-1 (the original) in their Robotics Studio SDK, which is written in C#. Check it out here http://msdn.microsoft.com/robotics/.

Has anyone used this yet?

[PaulP]

Yes, its incredibly simplistic and difficult to implement...

Firstly, it just tells you to read the readme.html when it comes to setting up the hardware...

All that tells you is that there are 2 commands

PlayMotion and SetServoPosition and that it is mapped to the default configuration of KHR-1 servo channels.

There is no provision for changing the channels to suit KHR-2 and all the successors.

Its not a true API. All they have implemented is a small section of the serial protocol for the KHR-1 board which also doesnt work with the successors.

Unfortunately, if you check the partnership list, all the other robots have a true API written by the manufacturers already in place with MS. In this way they have provided a better interface. The Lego Mindstorms API interface is stunning. You can actually run the robot round the room simply by dragging on a virtual Roller Ball on the screen.

I have asked if there is an intention to implement more and the response I got was basically No until someone (the manufacturer) writes an API and makes a request.

[shsan]

PaulP,

What I am currently doing is a low level API mapping directly to the RCB3 commands so yes I hope it will work fine with the KHR2, KHR1-HV and Manoi.
There are small differences between them but that can be managed internally and the external API does no t need to change.

Also I am using simple types for all the calls so normally writing a wrapper for any other language should be easy.

As for standardization, well if we write wrappers they would all be the same but it's difficult to standardize things across different projects on different timescale.

As for the Microsoft SDK, I could do the same interface in C# but it would still be a low level API so don't expect to drag anything around with the mouse unless you write a higher level layer for that.

And what Microsoft implemented anyway was the RCB1 protocol and it's not compatible with the RCB3. And since the protocol is not compatible it's not really Microsoft fault here.
Well I guess they could produce the API with what we have right now, hell I am doing it !

Anyway, mine will be ready this week so you will be able to judge by yourself if that's what you need or not.
Any help to do wrappers for VB or C#(I might do it myself) would be very welcome.

[PaulP]

Hi shsan

Most of what you said I had surmised but your comments have reinforced my thinking a bit.

My main aim is to achieve what you are doing and to save duplication of effort. Get one good low level API going that encompasses most of what people need and leave the fancy stuff for the high level language. As you have written in C it should have no real speed overheads which makes it ideal.

Most of my experience is in VB6 writing wrappers for Medical VTR control and Serial Controlled Film Viewing equipment. I've got about 2 years under my belt of doing the same in .NET.

Wrappers can be works of art or absolute nightmares dependent upon the lower level API.

In VB6 they were reasonable, in .NET they can be incredibly slow due to the Framework overhead etc. Supposedly, Framework 3 should be better on interops. Who knows, Framework 1 didnt even support serial ports now under 2.0 they have one of the best implementations I have worked with.

I also appreciate the MS problem. If companies arent very forthcoming then what can they do. I was surprised to see Kondo on the list at all so thats definitely a plus..

I havent given up on it yet. I'm currently trying to delve into the code and see where the KHR-1 specific code lies and see if I cant at least mod it to talk to the RCB3 instead... Now that will test my patience let alone my brains...

Anyway, keep up the good (hard) work. If there's anything I can look at let me know. I think most people would agree that someones got to get this going and it sounds like youre nearly there.

God do I waffle...

[PaulP]

shsan

Which version of the Protocol document are you working to?

The version I have says that the command $FEh should be acknowledged by an ACK of $06h. This is not happening also when a motion is completed it should send back $FFh notification with EF1-EF6 data. Again this isnt happening.

At this moment I can't tell whether its because its the RCB3 and not the RCB3J as installed on the 2HV

Unless the ACKs appear, then I cannot tell that a motion has completed before sending the next one.

[alexj212]

I have implemented about 50% of the protocol in c#. I havent done the rest mainly because of time. But I find it is very fast. I dont see any speed issues, and I like dot net, but I am a java developer by day.

I will be publishing a test app shortly, If you are interested in beta testing or coding an app on top of it let me know. I am headed out of town, but will be back in a week. Then I will post up a api exerciser that i wrote, I can poll the servos, execute motions, read analog values etc.

Alex

[shsan]

PaulP,

I am using the Japanese version of the documentation (the first released by Kondo).
Is there any other official one?

It also says that the FE command should acknowledge with ACK.

As for the notification, you need to turn it on in the Switch, it's not automatic I think.

I'll check that later this week-end.
shsan

[PaulP]

I have turned on the notification but have found that only applies to the completion of a stored motion. The individual movement commands as sent from the sliders do not ACK. The problem this causes me is that I cannot tell one movement has completed before sending the next.

I tried sending $Dh which I hoped would indicate that receiver was ready for the next command but motions are overridable so it replies ok and just starts the second command before finishing the first.

One thing I did consider was to write to a motion then execute it. The continuity depends on the turn-round time from write to read

The document I am working to is an english translation but there are errors that I suspect come from the original document not the tanslation.

[shsan]

First regarding the English documentation, if it's the one I think it is (the one I did then you have probably 80% changes that it's an issue with the translation and not with the original (that being said, I have found some issues with the Japanese one too).

It's quite possible that they did not intend the command FE to be used for that purpose and therefore there might be no mechanism to check if the servo has completed the move.

Yes writing to a motion in RAM seems to be the best choice, I would say.

And regarding the ACK, I think it would be done on reception of the command not on completion so it would not help you anyway.

shsan

[PaulP]

True the ACK is to acknowledge the command has been received.

Im about to play with storing a motion then playing it followed by a second store and play to see what the overheads are in comms and memory writing delays.

I'll let you know if its a possibility

[PaulP]

I have run into a problem that I'm not sure can be solved with the current setup of the RCB3.

The only movement completion replies are sent when a stored motion is played.
As someone else on this forum pointed out, there is a finite limit to the number of times you can write to the memory locations and play them.

This is in the order of a million or so which normally wouldn't present a problem.

If you intend to write real-time code that constructs a pose and sends it then executes it, this number could get used up very quickly.

The sliders function on the POS objects uses a RAM based motion which doesnt suffer the same problem but unfortunately doesnt send a motion complete message.

The only option is to send a position request at intervals and wait until the pose matches what you've sent. This bit I've done.

Unfortunately again, the continuous polling causes the RCB to stop moving the servos for a millisec or two and this causes a rather unsmooth motion.

If anyone can see something I've missed or can suggest a better way, can they please comment