my local environment is a bit of a mess. but here's some java code that is sure to blow up and give you issues talking to an arduino runing mrlcomm v.29
String port = "COM31"; Arduino ard = (Arduino)Runtime.createAndStart("ard", "Arduino"); ard.connect(port); for (int i = 0 ; i < 10000; i++) { ard.sendMsg(ArduinoMsgCodec.GET_VERSION); } System.out.println("Done..");
WHOOOHOO ! I get errors when
WHOOOHOO !
I get errors when I use your script
currently using Windows 7 64 with Arduino IDE 1.0.5 and Mega
Which to me makes sense...
NEWS FLASH
I've been infected !
I backed out all my changes, but now I get errors all the time, curious...
The 'change' point is when I commented out the logging - after that this was the first time I was able to get errors, and now they won't stopp even when I uncomment logging in the loop
You can see the main thread logging interleved with the listener thread for the Arduino
I did 4 runs at 10K
Some interesting links (and
Some interesting links (and possible experiments)
The sources of error
Hi Greg
The error are caused because the arduino is doing too much things to be able to read the serial input
setting the baudrate to 38400 have improve things for me, but lowering it to 19200 get worse
so slowering the data input to the arduino help... but arduino can support much more than 38400.
So for me it's because the arduino do not spend enough time to read the serial input, the main loop of MRLComm takes too much time to run, and by the time it came back to read more data the input buffer of the arduino overflow and lose data. More servo and pin are connected, quicker it overflow so that's why mega script have more trouble to run
I have try to modify the main loop so it updates servo and pins to run every two loops, but keep processing the messages every loop... and the error all disapear
So the solution to get rid the error is to have the arduino have more time to read serial, either by cutting time on the main loop execution or making it read more message from MRL before updating the servos/pins
Christian
edit: I have run my inMoov script with my modified MRLComm to update servo every two loops and got no error initializing it, but on a mega with nothing plug in it... I will try later today with my full inMoov
get yer motor running
So as it turns out.. throttling the messages into the arduino serial port can avoid these errors. we've added a small delay after each sendMsg call to make sure the arduino has a chance to process the mrl message. That being said, this isn't a 100% fix. Reality is, we shouldn't be writing to the arduino if it's not able to accept new data on it's serial port. It's a fairly small uart buffer (I think only 64 bytes) ...
So... we have something that is mostly worky now.. but i suspect that there might be situations where the arduino won't be able to keep up with the data that MRL is sending...
We have 1 courses to take to make this "better'.
1. make the arduino code "faster" .. in that it can handle data quicker. This is always a good option, but no matter how fast the arduino code is, it's relatively certain that a computer is going to be faster and as a result, we'll still be able to overrun the input buffer on the arduino.
2. make sure we are aware of the buffer on the arduino. Back in the day of modems this was called "flow control"... It required checking various signals on the serial port to know that the device hookedd up to the serial port was ready to accept new data. I don't know how good the arduino support for this stuff is, but in theory we could monitor the "CTS" (clear to send) and "RTS" (ready to send) line on the serial port connected to the arduino to ensure we're safe to write each byte... I'm just not sure that those pins will be driven properly by the uart on the arduino.. so testing will tell..
anyway. minor victory for stability.. unfortunately, harry suffered some injuries in the testing of this... no worries. we have the technology, we can put him back together. (only a broken finger.. and 2 broken parts in the neck.. yeah. he broke his neck.. but ... it.... 'tis but a scratch!) ... it's mearly a flesh wound :)
in the MRLComm main loop,the
in the MRLComm main loop,the servo sweeping part seem to take forever to do, slowing down a lot the main loop, making the arduino unable to process quickly the serial buffer
I've got the idea to slow down the update of the servo position or even stop it if it have more important things to do
so at the begining of the main loop, I check the serial buffer, if it's almost empty, it run the sweep servo part every 1ms, if bytes begin to add up in the buffer, it does it every 10ms, and if the buffer is almost full, it stop sweeping the servo.
I also increase the buffer size to have a better control of the flow.
To test this I have attach up to 40 servo, ask the arduino to sweep them and spam 10k getVersion, and I don't seem to get any error report, but things are getting very slow, but seem to stay responsive
here my test script