Resolving Issues with the Arduino Control Box
The Arduino microcontroller used has limited memory, while the student who programmed it used a lot of bloated publicly available libraries. That combination means that there is very little memory for runtime variables. Most things are manageable except for the communication part. When there is too much communication, then slow processing and filling buffer lead to memory overflow. I don't know what happens, but either programming memory is overwritten or working memory hits a limit and variables no longer get populated. The end result is a frozen microcontroller that triggers communication errors on the computer side (either by not responding to commands or by actually resulting in a recognized error that is output on the computer).
Some tips regarding resolution of the seized microcontroller:
- If the Lynx6 seizes, then it is important to unplug the USB cable and plug it back in. The computer side is usually the easiest to do that for. Doing so truly powers off the microcontroller so that it can be reset. The control box seizing means it does not obey commands or it outputs a communication error (in Matlab). Anything that looks like the message is not getting through merits a USB cable reset. The power cable and switch is only for powering the motors and will do nothing to resolve the communication problem.
- In the code stubs, look for code that sends commands too fast. So far a minimum pause time of 0.1 or 0.25 seconds works after a command has been sent.
- Instantiating the robot class sends a command, so pause after constructing.
- Commands sent in succession using a for loop with insufficient pause will for sure cause problems.
- When calibrating, do not click too fast or it will seize. If it seizes during calibration then save the parameters by hitting the save button, the restart the calibration routine with the save parameters loaded up and passed as an argument.
- There is a lynx6.closeSerialPorts (or something like that) for resetting on the Matlab side, but hardware reset is almost always needed (point 1).
Generally, be a little cautious about command send frequency. You'll quickly get the hang of it and things will run smoothly.