RCB3 C API (for KHR2 and MANOI AT01)
by shsan
Sun Feb 11, 2007 3:22 am
Are you sure that you cannot store the full motion into RAM?
That would allow you to bypass the EEPROM issue.
I thought that the WRITE_TO_EEPROM switch in the option field had to be set in order to save to EEPROM and that if you didnt set it then it would be saved into RAM instead.
I might check that later today because I need to do the same thing.
shsan
That would allow you to bypass the EEPROM issue.
I thought that the WRITE_TO_EEPROM switch in the option field had to be set in order to save to EEPROM and that if you didnt set it then it would be saved into RAM instead.
I might check that later today because I need to do the same thing.
shsan
by PaulP
Sun Feb 11, 2007 3:21 pm
The one thing I am trying to achieve is to be able to read a motion file from the hard-drive and play it directly. This will not only allow for much more complex motions to be made but allow for more involved decision making on the P.C. for example motion detection from video etc.
I'm fairly certain on what I've discovered. I've been monitoring the output of H2H3J and H2H3 to see how they interact.
When sending single slider moves from a POS object, teh command $FEh is issued with a single PH/PL pair.
WHen opening a POS object, the robot will assume the position of the Pose. This is done with $FDh.
Both of these require the initial sending of $Dh and the following command has to arrive within a finite timeout period.
$FEh has no response at all.
$FDh responds with $6h to acknowledge receipt of the command, but no response at the completion of the motion.
As I understand it, (part from the text and part from observing the port data) Options=0 writes to RAM and immediately plays back.
Options=1 writes to EEPROM but can only be used for a complete sequence of motions. This also involves $F6h calls to write the Motion Parameters and text. This ones quite involved and i've not yet mapped the whole process.
Also I don't think its possible to utilise the SET and CMP through RAM though these can be quite easily implemented (and improved) in the P.C. code.
Having said all that, I have managed to parse a .RCB file successfully and pass the motions to RAM. It quite happily executed the lot without falling over. But as I said it is not smooth because of the constant checks to see if the motion has completed.
I'm fairly certain on what I've discovered. I've been monitoring the output of H2H3J and H2H3 to see how they interact.
When sending single slider moves from a POS object, teh command $FEh is issued with a single PH/PL pair.
WHen opening a POS object, the robot will assume the position of the Pose. This is done with $FDh.
Both of these require the initial sending of $Dh and the following command has to arrive within a finite timeout period.
$FEh has no response at all.
$FDh responds with $6h to acknowledge receipt of the command, but no response at the completion of the motion.
As I understand it, (part from the text and part from observing the port data) Options=0 writes to RAM and immediately plays back.
Options=1 writes to EEPROM but can only be used for a complete sequence of motions. This also involves $F6h calls to write the Motion Parameters and text. This ones quite involved and i've not yet mapped the whole process.
Also I don't think its possible to utilise the SET and CMP through RAM though these can be quite easily implemented (and improved) in the P.C. code.
Having said all that, I have managed to parse a .RCB file successfully and pass the motions to RAM. It quite happily executed the lot without falling over. But as I said it is not smooth because of the constant checks to see if the motion has completed.
by shsan
Sun Feb 11, 2007 3:36 pm
I am a bit confused here.
First 0xFE should ACK according to the manual.
Do you mean that by using 0xFD and storing the motion in RAM, it is actually playing it?
In the japanese manual, there is something very vague about that command.
For example, they say that the slot position in the motion has no meaning when storing in RAM.
Also did you try to enable the motion ending notification in the switch bit?
(if you look at my API, you will find which bit it is.)
This is a notification that should send data once the motion is done.
I wonder if it's working when playing from RAM.
First 0xFE should ACK according to the manual.
Do you mean that by using 0xFD and storing the motion in RAM, it is actually playing it?
In the japanese manual, there is something very vague about that command.
For example, they say that the slot position in the motion has no meaning when storing in RAM.
Also did you try to enable the motion ending notification in the switch bit?
(if you look at my API, you will find which bit it is.)
This is a notification that should send data once the motion is done.
I wonder if it's working when playing from RAM.
by PaulP
Sun Feb 11, 2007 7:32 pm
Thats what I've seen from my code and the monitor
0xFE does not ACK.
0xFD is the command that is sent when you double click a POS object to edit it. That is why in sync mode the robot assumes the pose when you double click the POS objects.
0xFD does ACK but doesnt return 0xFF to say motion complete.
I looked at your Motion Ending bit, it is the same as toggling the check box in the top of the options form.
With it switched ON, normal playbacks from EEPROM will send a notification but RAM based ones don't. I've monitored my code and H2H to confirm this.
To be honest, I'm not surprised. The protocol was never designed or intended to be used this way. The remote control unit and the P.C. only need to know when a stored playback has finished. I dont think they envisaged someone trying to do what we are doing.
The RCB comms don't run asynchronous to the servo's. Asking a servo for its position while running will pause the servo momentarily to check and send the reply. This processing time has to be taken away from the job of moving the servo's.
Ideally it would be nice to get Kondo to implement a 0xFF reply at the end of a RAM motion as well but there may be a valid reason why they dont.
0xFE does not ACK.
0xFD is the command that is sent when you double click a POS object to edit it. That is why in sync mode the robot assumes the pose when you double click the POS objects.
0xFD does ACK but doesnt return 0xFF to say motion complete.
I looked at your Motion Ending bit, it is the same as toggling the check box in the top of the options form.
With it switched ON, normal playbacks from EEPROM will send a notification but RAM based ones don't. I've monitored my code and H2H to confirm this.
To be honest, I'm not surprised. The protocol was never designed or intended to be used this way. The remote control unit and the P.C. only need to know when a stored playback has finished. I dont think they envisaged someone trying to do what we are doing.
The RCB comms don't run asynchronous to the servo's. Asking a servo for its position while running will pause the servo momentarily to check and send the reply. This processing time has to be taken away from the job of moving the servo's.
Ideally it would be nice to get Kondo to implement a 0xFF reply at the end of a RAM motion as well but there may be a valid reason why they dont.
by shsan
Mon Feb 12, 2007 9:36 am
I check the 0xFE too and indeed it does not ack when used by the HTH.
But if you ask politely it will
My lib is asking for it and it's returned properly.
Yes the Motion ending bit is the same as the first checkbox on the option page.
Indeed when playing using 0xFD without the EEPROM flag, it does not notify at the end.
And that's a annoying indeed. I guess you could calculate the time the motion should take (or estimate it) then poll less frequently but it's far from ideal.
I have also run into some issues with the notifications. They can be sent at any time. I was hoping to receive them only on 0xD but no they can be sent after the RCB3 receiving a command..
Which makes it more tricky, I was hoping too that the first byte of all possible answers would not conflict with the first byte of the notifications but there is no guarantee at all.
So in my case some commands will fail because the notification is coming.
Even if Kondo was to implement it, there is no guarantee that we could re-flash the RCB3 controllers. Kondo does not provide any tool for that even if I suspect that it's possible.
It's does not seem to have been planned at for interactive control from the PC indeed.
Let's hope that they will take on the challenge and provide a better support next time for that kind of usage.
But if you ask politely it will
My lib is asking for it and it's returned properly.
Yes the Motion ending bit is the same as the first checkbox on the option page.
Indeed when playing using 0xFD without the EEPROM flag, it does not notify at the end.
And that's a annoying indeed. I guess you could calculate the time the motion should take (or estimate it) then poll less frequently but it's far from ideal.
I have also run into some issues with the notifications. They can be sent at any time. I was hoping to receive them only on 0xD but no they can be sent after the RCB3 receiving a command..
Which makes it more tricky, I was hoping too that the first byte of all possible answers would not conflict with the first byte of the notifications but there is no guarantee at all.
So in my case some commands will fail because the notification is coming.
Even if Kondo was to implement it, there is no guarantee that we could re-flash the RCB3 controllers. Kondo does not provide any tool for that even if I suspect that it's possible.
It's does not seem to have been planned at for interactive control from the PC indeed.
Let's hope that they will take on the challenge and provide a better support next time for that kind of usage.
by PaulP
Mon Feb 12, 2007 11:46 am
To get round the notifications problem, I set a flag in PC memory to say what sort of reply I am expecting . That way, if a reply appears that could be interpretted as either a normal reply or a notification I can tell. To verify it, I believe you will find its the only reply thats 32 bytes long.
You are right about the RCB3. Its good but re-flashable at home is hoping. I might pick up the challenge and try what come members thinks is the best route...
Might try the Atmega 128 with an SSC-32. There room in the back and the chest cavity for that plus a wireless radio and a video-sender.....
You are right about the RCB3. Its good but re-flashable at home is hoping. I might pick up the challenge and try what come members thinks is the best route...
Might try the Atmega 128 with an SSC-32. There room in the back and the chest cavity for that plus a wireless radio and a video-sender.....
by shsan
Mon Feb 12, 2007 11:57 am
I already have a similar flag, just need to modify the answer reception.
I was planning to use a Atmega 128 too. At the moment I am still fighting with my BlueSmirf module.
I spent all day trying various things, it's working fine on itself but as soon as I plug it with the RCB3 nothing happens (no matter what I try, inverted signal etc..)
I was planning to use a Atmega 128 too. At the moment I am still fighting with my BlueSmirf module.
I spent all day trying various things, it's working fine on itself but as soon as I plug it with the RCB3 nothing happens (no matter what I try, inverted signal etc..)
by PaulP
Mon Feb 12, 2007 12:40 pm
I've looked at them myself but not certain on which to go for.
Some comments from other members have out me off a bit.
The usual problems are voltage levels (TTL against RS232). I've not yet put a scope on the data line so I'm not sure.
The new USB/RS232 module from Kondo is not an off the shelf product so anything could be going on there. My first instinct would be to make a three wire RS232 lead and test it (AFTER I've stuck the scope on to prove the levels are compatible.) There are so many hybrids and hacks for RS232 its unbelievable.
Another thing could be the voltage levels of the KHR. 10.8V is an unusual voltage..
Might get the scope out of the cupboard later and find out.
Some comments from other members have out me off a bit.
The usual problems are voltage levels (TTL against RS232). I've not yet put a scope on the data line so I'm not sure.
The new USB/RS232 module from Kondo is not an off the shelf product so anything could be going on there. My first instinct would be to make a three wire RS232 lead and test it (AFTER I've stuck the scope on to prove the levels are compatible.) There are so many hybrids and hacks for RS232 its unbelievable.
Another thing could be the voltage levels of the KHR. 10.8V is an unusual voltage..
Might get the scope out of the cupboard later and find out.
by shsan
Mon Feb 12, 2007 12:45 pm
Don't bother with the scope.
I have already put up quite some work on that.
If you want to know what I have found so far check up the page I have made for that.
http://www.lessieux.com/mywiki/index.ph ... tooth_KHR2
I have already put up quite some work on that.
If you want to know what I have found so far check up the page I have made for that.
http://www.lessieux.com/mywiki/index.ph ... tooth_KHR2
by PaulP
Mon Feb 12, 2007 1:44 pm
As you say, quite some work..
The 5V and 3.3V thing is to do with the device being TTL tolerant. It can operate (happily) in a TTL circuit or CMOS.. so thats shouldnt be a problem as you surmised.
If I remember rightly, (if not someone will quickly correct me), normally, RS232 lines float at a High level. +13V = logic 0
so essentially the RS232 is streaming 0's at you. When a start bit arrives the UART will wait for half a bit time and start sampling. Pulse width and Mark/Space gaps can be critical at high speed and i wouldnt expect the RCB to be spot-on.
Going by what you've said, If both are at TTL levels I wouldn't normally expect to have to invert.
One thing I have seen on the RCB is the 10.8V line is incredibly noisy. So your regulated voltage may not be clean enough. but thats a long shot.
Which BlueSmirf module is it you have?
The 5V and 3.3V thing is to do with the device being TTL tolerant. It can operate (happily) in a TTL circuit or CMOS.. so thats shouldnt be a problem as you surmised.
If I remember rightly, (if not someone will quickly correct me), normally, RS232 lines float at a High level. +13V = logic 0
so essentially the RS232 is streaming 0's at you. When a start bit arrives the UART will wait for half a bit time and start sampling. Pulse width and Mark/Space gaps can be critical at high speed and i wouldnt expect the RCB to be spot-on.
Going by what you've said, If both are at TTL levels I wouldn't normally expect to have to invert.
One thing I have seen on the RCB is the 10.8V line is incredibly noisy. So your regulated voltage may not be clean enough. but thats a long shot.
Which BlueSmirf module is it you have?
by shsan
Mon Feb 12, 2007 1:51 pm
I have the following module.
http://www.sparkfun.com/commerce/produc ... cts_id=582
All my experiments are done with the DM-330MV generator and from what I have seen on the scope it's quite clean.
My guess is that they are both TTL but no idea why it's not working. It might be something to do with the power coming from the Inverter or something like that but I would not expect any problem there either since both the RCB and the BlueSmirf have transistors behind the connection...
The BlueSmirf states quite clearly that it's expecting inverted signals too...
http://www.sparkfun.com/commerce/produc ... cts_id=582
All my experiments are done with the DM-330MV generator and from what I have seen on the scope it's quite clean.
My guess is that they are both TTL but no idea why it's not working. It might be something to do with the power coming from the Inverter or something like that but I would not expect any problem there either since both the RCB and the BlueSmirf have transistors behind the connection...
The BlueSmirf states quite clearly that it's expecting inverted signals too...
by PaulP
Mon Feb 12, 2007 2:19 pm
Just had a scan thru the PDF datasheet for it. It seems an impressive little toy.
My one concern was if it expected auto-baudrate detection, these usually require the sending of a specific character, space /chr(32) is a common one but it doesnt seem to be that type of device. Setting the baudrate from the config should remove any of those issues....
As you say, It should work.....
Might get one to join in the fun, meanwhile, I intend to look at the serial on this Kondo device and see if it gives me any ideas as I was looking at a WIFI device that could be fun. Get the thing on the network....
My one concern was if it expected auto-baudrate detection, these usually require the sending of a specific character, space /chr(32) is a common one but it doesnt seem to be that type of device. Setting the baudrate from the config should remove any of those issues....
As you say, It should work.....
Might get one to join in the fun, meanwhile, I intend to look at the serial on this Kondo device and see if it gives me any ideas as I was looking at a WIFI device that could be fun. Get the thing on the network....
by slashsplat
Mon Feb 12, 2007 2:43 pm
I have the USB/232 wireless module form KONDO for my MANOI. Have not yet been able to get it to work...PaulP wrote:... The new USB/RS232 module from Kondo is not an off the shelf product so anything could be going on there.
I love standards, there are so many to choose from!PaulP wrote:There are so many hybrids and hacks for RS232 its unbelievable.
<i>Ira Chandler</i> /* slashsplat */
<b>http://BotConnect.com</b>
home of the American MANOI Users Group
<b>http://BotConnect.com</b>
home of the American MANOI Users Group
