I have a joystick attached to a serial port (I use Ubuntu, so the port is /dev/ttyUSB0).
A simple utility, such as Cutecom, picks up the data without problem at the specified baud rate for the port (115200).
The data is sent at a rate of 20Hz.
The data is sent in the form that matches the following LUA pattern "F[+-]?%d%d[+-]?%d%d" and terminated with '\n'
In a threaded script, I have in the ThreadFunction, simSerialRead(joystick, ....)
The data is received, correctly parsed and numbers are correctly stored in the simulation.
However, there is something like a ten second delay between data being sent from the joystick and being picked up inside threaded function.
I think the problem arises because so much data is being fed to the simulation, but the simulation is processing each data line.
Is there some way of filtering the Serial line?
There is no way of emptying the stream.
I tried to close and open the Serial port at the beginning and the end of the treaded function, but that does not seem to work.
Here is a sample scene (I already posted on the forum in the question about Graph data, but this is a separate question, so I opened a new topic.) http://pastebin.com/Dkn1M1gT
Reducing large Serial delay
Re: Reducing large Serial delay
Problem was partially solved by reducing the data rate from 20Hz to 10Hz, thus allowing simulation to keep up with data.
But more generally, a mechanism to sample is needed (or if it exists, please let me know).
But more generally, a mechanism to sample is needed (or if it exists, please let me know).
Re: Reducing large Serial delay
Hello,
why don't you keep reading data as long as there is data available? So basically, in each simulation step, read all the data you can get. And process all of it.
Cheers
why don't you keep reading data as long as there is data available? So basically, in each simulation step, read all the data you can get. And process all of it.
Cheers
Re: Reducing large Serial delay
Just consuming data did not work.
I was moving the joystick and it would take ten seconds (I joke not, I counted them) before the simulation recognised the change in data.
So, I would have the joystick at neutral, for example. Then I would push forwards. The data corresponding to the change would appear in the simulation after 10 seconds.
When I say 'in the simulation', I put an simAddStatusBarMessage in the threadfunction to print when the data was received. It took many seconds. The delay was unacceptable.
So I reduced the data rate in the joystick from 20 Hz (that is sending a datum 20 times a second) to 10 Hz. Then the response in the simulation was delayed, but acceptable.
If you say that all the data could be consumed, please indicate how. I sent you the scene with the code I was using. Since I am very new to VREP, and to LUA, I am sure that I have missed something.
I was moving the joystick and it would take ten seconds (I joke not, I counted them) before the simulation recognised the change in data.
So, I would have the joystick at neutral, for example. Then I would push forwards. The data corresponding to the change would appear in the simulation after 10 seconds.
When I say 'in the simulation', I put an simAddStatusBarMessage in the threadfunction to print when the data was received. It took many seconds. The delay was unacceptable.
So I reduced the data rate in the joystick from 20 Hz (that is sending a datum 20 times a second) to 10 Hz. Then the response in the simulation was delayed, but acceptable.
If you say that all the data could be consumed, please indicate how. I sent you the scene with the code I was using. Since I am very new to VREP, and to LUA, I am sure that I have missed something.
Re: Reducing large Serial delay
Hello again on this topic.
I thought I had solved this problem, but now it seems not.
For some reason I am getting data from the simSerialRead function that is not be sent by the joystick. Also this appears to be random and can depend on whether I have edited a script.
It seems as if something is not being initialised properly. How can I inspect the C code or trace variables to find out what the problem is?
Do I have to recompile the whole of VREP or is there a way of looking at specific libraries? From the literature, it seems that LUA is very closely integrated with C, but I am starting with LUA in order to use VREP. Some pointers about how to start looking for the problem would be useful.
Regards,
Richard
I thought I had solved this problem, but now it seems not.
For some reason I am getting data from the simSerialRead function that is not be sent by the joystick. Also this appears to be random and can depend on whether I have edited a script.
It seems as if something is not being initialised properly. How can I inspect the C code or trace variables to find out what the problem is?
Do I have to recompile the whole of VREP or is there a way of looking at specific libraries? From the literature, it seems that LUA is very closely integrated with C, but I am starting with LUA in order to use VREP. Some pointers about how to start looking for the problem would be useful.
Regards,
Richard
Re: Reducing large Serial delay
Richard,
what platform are you running on? Also, you can try to use an alternate serial port routine via setting the variable useAlternateSerialPortRoutines in the file system/usrset.txt.
Another option would be to use an extension module for Lua, supporting serial port communication, e.g. this one.
Finally, you might also be doing something wrong in how you handle/use scripts. Posting your scene would help.
Cheers
what platform are you running on? Also, you can try to use an alternate serial port routine via setting the variable useAlternateSerialPortRoutines in the file system/usrset.txt.
Another option would be to use an extension module for Lua, supporting serial port communication, e.g. this one.
Finally, you might also be doing something wrong in how you handle/use scripts. Posting your scene would help.
Cheers
Re: Reducing large Serial delay
Hi, Thanks for the response.
I said in the first post for this thread, I use Ubuntu - that's Linux.
Just saw you couldn't get pastebin to work. Here is the scene in dropbox https://www.dropbox.com/s/0ole5spt9u2ln ... e.ttt?dl=0
However, this scene works!!!!! As I said above. I just realised that I edited the scene a bit, thinking I had the 'end' to the while in the wrong place. But if I move it lower, I get the same problems. So, what is happening here is that the while loop (with the simSerialRead) empties the stream, and only the last valid datum is used for the averaging.
I experimented a great deal, and ran into timing issues that I am finding difficult to understand completely. This code works now.
As usual, I need to keep working at the problem and reading as much as possible around it. Sorry for all my questions. VREP is a great piece of software. I want to get my project working in it perfectly.
Thanks for the alternative LUA links.
Do I understand from this that useAlternateSerialPortRoutines only affects the underlying code, but the API names, that is simSerialRead etc remain the same?
I said in the first post for this thread, I use Ubuntu - that's Linux.
Just saw you couldn't get pastebin to work. Here is the scene in dropbox https://www.dropbox.com/s/0ole5spt9u2ln ... e.ttt?dl=0
However, this scene works!!!!! As I said above. I just realised that I edited the scene a bit, thinking I had the 'end' to the while in the wrong place. But if I move it lower, I get the same problems. So, what is happening here is that the while loop (with the simSerialRead) empties the stream, and only the last valid datum is used for the averaging.
I experimented a great deal, and ran into timing issues that I am finding difficult to understand completely. This code works now.
As usual, I need to keep working at the problem and reading as much as possible around it. Sorry for all my questions. VREP is a great piece of software. I want to get my project working in it perfectly.
Thanks for the alternative LUA links.
Do I understand from this that useAlternateSerialPortRoutines only affects the underlying code, but the API names, that is simSerialRead etc remain the same?
Re: Reducing large Serial delay
Yes that is correct, the API names remain the same, only the underlying serial port routines will be different.
Cheers
Cheers
[Solved] Re: Reducing large Serial delay
My problem arises from both the hardware/firmware of my joystick, and also interfacing with the simulation software.
a) It is important to have a way of absorbing all the data being sent, or to reduce the data rate of the physical device to the speed of the simulation.
b) Joysticks do not move back exactly to neutral (zero x,y), and the poorer quality the worse the difference. To overcome this, we set the joystick to calibrate itself when the port is opened. The problem was that the simulation software appeared to show that the simulation was running BEFORE the port to the joystick was opened (about 3 seconds). So naturally, the user begins to move the joystick. The degree of movement at the time the port is opened is taken as by the joystick firmware as the neutral position, so when the joystick springs back to the physical neutral position, the firmware adds on significant bias.
The solution is create a message to the user that the simulation has started only after the port has been opened.
It would be useful to have a function in the API, eg. portHandle=simSerialReopen(portHandle) that closes and reopens the Serial port, discarding any data. The new portHandle number might be -1 if the operation fails.
a) It is important to have a way of absorbing all the data being sent, or to reduce the data rate of the physical device to the speed of the simulation.
b) Joysticks do not move back exactly to neutral (zero x,y), and the poorer quality the worse the difference. To overcome this, we set the joystick to calibrate itself when the port is opened. The problem was that the simulation software appeared to show that the simulation was running BEFORE the port to the joystick was opened (about 3 seconds). So naturally, the user begins to move the joystick. The degree of movement at the time the port is opened is taken as by the joystick firmware as the neutral position, so when the joystick springs back to the physical neutral position, the firmware adds on significant bias.
The solution is create a message to the user that the simulation has started only after the port has been opened.
It would be useful to have a function in the API, eg. portHandle=simSerialReopen(portHandle) that closes and reopens the Serial port, discarding any data. The new portHandle number might be -1 if the operation fails.