Majinga Simulator Update: linked to RCB with the OCX control

[javi]

Thanks to the OCX provided by iñaki, I've updated the simulator to
talk to the RCB. You can download the new (VERY BETA) simulator from
here.
USE IT AT YOUR OWN RISK! YOU CAN DAMAGE THE ROBOT OR HURT YOURSELF.

You also need iñaki's library, and have to register the ocx (with
regsvr32) for the simulator to work. The use of the connection with the
RCB is currently very simple:

To connect to the RCB click the "Open" button. The RCB has to be
connected to COM1 (will be fixed in a future version, if you need to change
it edit the file RCB.VBS and change line 9,const Port=1, to the port number
you need).

The "Test connection" button gets the Id of the RCB. It's used
only to check the communication with the RCB.

The "Synchronize" check box toggles synching the simulator positions
with the robot positions. When checked, any change in the simulator is
sent to the RCB (also when replaying movements)

The "Sync" button synchronizes the robot with the simulator position,
regardless of the "Synchronize" check box value.

The "Read motors" button synchronizes the simulator with the robot
position.

The "Home Pos" button reads the home position of the robot and synchronizes
it in the simulator.


As a beta, there are still some issues:

- Sometimes the ocx hangs the explorer window when talking to
the RCB for the first time. Just close the explorer and load it again.
(iñaki could you take a look at it?, it also happens using the
vbs example that's in the docs)

- There is no direct match between robot position and simulator position
(the robot position is adjusted to match the simulator, although it works,
it has to be checked more carefully)

- When you position a servo out of range, the simulator warns you,
but you can choose to ignore it, USE IT AT YOUR OWN RISK!

- When in sync mode, due to the delay in sending each position,
the forces acting on the KHR1 robot surely will be different than
if the movement was done as a pre-recorded scenario, so probably the
robot will fall down when moving the legs or feet more than a few degrees.

- Right now it's not possible to record the movements as motions
or scenarios directly from the simulator. Save the movement file and
use Hearttoheart software to download it to the RCB.

Future improvements (no deadline, but will be done when I have time):
- Get the COM port from a text box
- Add a "teaching" mode
- Manage motions in the RCB
- Manage scenarios in the RCB

[inaki]

Hi Javi.
I am testing your software.
Until now I have been unable to find the 'ocx hangs when starting' error.
Would you give me some more clues about how to reproduce this error ?

Your software is great. It has been a pleasure to see the picture and the robot move at the same time!

I have had two errors. When setting X coordinates for the right arm I got the following error: Line 196 Object required: 'cellObject(...)'.

Also, I have found the 'SYNC' button does not work sometimes.

Besides this, when working with CSV files stored on this and pressing PLAY, with the Synchronize flag set, the robot moves very slowly, somewhat like 'by steps'.

I can provide you with the source code for the OCX if you think it can help you.

[javi]

Hello Iñaki, thanks for your comments.

Until now I have been unable to find the 'ocx hangs when starting' error.
Would you give me some more clues about how to reproduce this error ?

I'm sorry I have no idea what the problem can be. Just opening the port, getting the RBC Id and closing, sometimes work, sometimes doesn't. If it's working for you maybe it has to do with my PC. I'm going to trace the serial comms to see what's happening

Your software is great. It has been a pleasure to see the picture and the robot move at the same time!

Thanks.

I have had two errors. When setting X coordinates for the right arm I got the following error: Line 196 Object required: 'cellObject(...)'.
Also, I have found the 'SYNC' button does not work sometimes.

Ok, to the bug list.

Besides this, when working with CSV files stored on this and pressing PLAY, with the Synchronize flag set, the robot moves very slowly, somewhat like 'by steps'.

As I said, it's a beta. The simulator synchronizes the speed with the plugin for 3D representation, and I have to look deeper in this part of the code to speed things up.

I can provide you with the source code for the OCX if you think it can help you.

Thanks, but I don't have the tools to debug it. On the other side, I'll be very happy to have the .dll code (as I asked once,:wink: to port to an embedded board to make the robot autonomous )

[javi]

I've updated the simulator link to the RCB. The new V2 is here. I've corrected the known bugs and improved the interface between the simulator and the RCB. There is a short help (RCB link help) explaining how it works.

Iñaki, I've traced the OCX comms, and the control hangs (when it does) just after sending the first command to the RCB (it blocks in the write comm function). I traced also HeartToHeart, and there is a slight difference in the way it communicates with the RCB: the initialisation adds some break chars your dll doesn't, and before all write commands, it purges the serial line. If you want I have some logs (by portmon) of both programs.

[inaki]

Javi,
I have been unable to reproduce the problem although I have been testing it connecting(and disconnecting) in a row one thousand times.

The escape characters Hearttoheart sends are for controlling the DTR line. I do the same but some time after.
I also purge the buffers prior to receive the first data packet. Anyway neither setting the DTR line nor purging the buffer is necessary to stablish a connection. That means that RCBStart whould work. Actually the only communication setting that is necessary to connect is the COM configuration.

Other than the DTR peculiar behaviour the KHR/RCB does not have anything special.

I think the problem might be the worker threads that are created to deal with input data. Please, check the following: how much CPU takes iExplorer when you observe the deadlock ? Use the task manager for example to see this. Is it above 90% ?

[javi]

Hi Iñaki.
No, the iexplorer process is not using the CPU (the task manager shows it at 0% CPU, 36MB memory, 10MB before loading the simulator).

I'm sorry maybe I didn't explained myself right, I can always open the com port, and is the first reading operation that hangs the ocx.

I've uploaded the comms log to the file section so you have all the info. When it hangs, the log is always the same.

It also contains the HeartToHeart log (which I suppose you already have done, in order to write the dll), so you can see the differences I said.

[inaki]

Is you port an integrated COM port on the motherboard or is it an adaptor plugged on the USB ?

The only reason I can find it is failing on a read command is because there is no DTR signal so the sender does not send the answer back. Anyway, even in that case there is a timeout that should work.

Here is a good picture if the initialization process. Important steps are shown with full parameters. Minor steps are not shown or are just commented.

//NOte: error control not shown

//Open COM Port

hCom = CreateFile(...);

//Init internal synhronizers
InitializeCriticalSection(&CSCola);

//Setup COM queues
SetupComm( hCom, 4096, 4096); //Colas de entrada y de salida

//Setup COM masks
PurgeComm( hCom, PURGE_TXABORT | PURGE_TXCLEAR ) ;
PurgeComm( hCom, PURGE_RXABORT | PURGE_RXCLEAR ) ;
SetCommMask( hCom, EV_RXCHAR | EV_ERR | EV_BREAK ) ; //0xC1

//Setup timeouts
CommTimeOuts.ReadIntervalTimeout = 0xFFFFFFFF; //0xFFFFFFFF ;
CommTimeOuts.ReadTotalTimeoutMultiplier = 0 ; //0
CommTimeOuts.ReadTotalTimeoutConstant = 1000; //1000 ;
CommTimeOuts.WriteTotalTimeoutMultiplier = 2 * CBR_9600/CBR_115200 ;
CommTimeOuts.WriteTotalTimeoutConstant = 0 ;
SetCommTimeouts( hCom, &CommTimeOuts ) ;

//Setup COM configuration parameters

dcb.DCBlength =0x0000001C; /* sizeof(DCB) */
dcb.BaudRate =CBR_115200; /* Baudrate at which running */
dcb.fBinary =1; /* Binary Mode (skip EOF check) */
dcb.fParity =1; //
dcb.fOutxCtsFlow =0; /* CTS handshaking on output */
dcb.fOutxDsrFlow =0; /* DSR handshaking on output */
dcb.fDtrControl =DTR_CONTROL_ENABLE; /* DTR Flow control */
dcb.fDsrSensitivity =0; /* DSR Sensitivity */
dcb.fTXContinueOnXoff =0; /* Continue TX when Xoff sent */
dcb.fOutX =0; /* Enable output X-ON/X-OFF */
dcb.fInX =0; /* Enable input X-ON/X-OFF */
dcb.fErrorChar =0; /* Enable Err Replacement */
dcb.fNull =0; /* Enable Null stripping */
dcb.fRtsControl =RTS_CONTROL_ENABLE; /* Rts Flow control */
dcb.fAbortOnError =0; /* Abort all reads and writes on Error */
dcb.fDummy2 =0; /* Reserved */
dcb.wReserved =0; /* Not currently used */
dcb.XonLim =0x800; /* Transmit X-ON threshold */
dcb.XoffLim =0x200; /* Transmit X-OFF threshold */
dcb.ByteSize =8; /* Number of bits/byte, 4-8 */
dcb.Parity =NOPARITY; /* 0-4=None,Odd,Even,Mark,Space NOPARITY, ODDPARITY,EVENPARITY,MARKPARITY,SPACEPARITY */
dcb.StopBits =ONESTOPBIT; /* 0,1,2 = 1, 1.5, 2 */
dcb.XonChar =0x11; /* Tx and Rx X-ON character */
dcb.XoffChar =0x13; /* Tx and Rx X-OFF character */
dcb.ErrorChar =0; /* Error replacement char */
dcb.EofChar =0; /* End of Input character */
dcb.EvtChar =0; /* Received Event character */
dcb.wReserved1 =0; /* Fill for now. */


SetCommState(hCom, &dcb);

//Create events for overlapped I/O

...

//Create a thread for event gathering

CreateThread(....);

//Wait a second for initialization

Sleep(1000);

//Clear DTR flag; necessary to read data back from the RCB

EscapeCommFunction(hCom, CLRDTR);
SetCommMask( hCom , EV_RXCHAR );

//Fill up internal configuration data

...

//Check connection using RCB_GetID
if(!RCB_GetID((HANDLE)ptrCfg, &id) || (id == 0xFF))
;

//Flush internal data queues
...

//END

}