Some suggestions for improving Roborun

In the course of working out a solution for steering problems during acceleration and deceleration when using a mixing mode,
acceleration-deceleration-with-mixing
a number of things came up that I think could greatly improve the usefulness of the Roborun interface. In several cases these are things that I was able to do, awkwardly, outside the Roborun environment or by scripting, but that would work far better if incorporated in your software.

Some of these will be very easy to implement, others might take some more work.

I. Run tab

One of the nicest features of Roborun+ is the ability to see real-time graphs of what the controller is doing. Two central motor parameters are included in the list of what can be graphed – the channel commands (which will be Throttle and Steering if mixed, or Motor1 and Motor2 if separate) and motor power. Especially if a mixing algorithm is in use, however, understanding what a vehicle will do by looking at motor power curves alone is certainly not intuitive. What does give an almost intuitive picture is a plot of fore/aft and left/right movement, and these curves can be gotten by just un-mixing the motor power curves. I'll repeat an already posted graph here in which those are plotted, and in which the poor steering behavior during "standard" deceleration is quite evident.

It is a bit surprising that no one ever complained that their vehicle keeps turning till much of the forward motion has already ceased, or that accelerating into a turn yields straight ahead movement for quite a ways before turning begins. Perhaps some people did have trouble driving this way, but instead of understanding the cause, they hid the problem in one way or another by using a closed-loop to fight it or by simply slowing things down. Perhaps, had they seen curves of resulting movement they would have gotten at the root cause rather than applying a bandaid.

In any case, adding fore/aft and left/right motion to the drop down list for the Run tab graph should not be a major task. Certainly the algebra is easy enough.

II. Scripting tab. I have four suggestions for improving this, ranging from trivially easy to quite a bit more difficult.

(a) One very simple improvement: addition of a box or some text in the title bar that shows the name of the opened file. I'm often juggling more than one file, and sometimes more than one instance of Roborun, and my memory sucks so I frequently have had to save with a new name and then re-name because I wasn't sure which file I was actually working on.

(b) The simulation available in this tab is very, very limited. It only allows you to enter numeric values in place of configuration or command parameters, and you get numerical results that you hope will tell you whether the calculations make sense. It actually simulates neither controller behavior nor motor behavior. At a minimum, it should be able to read configuration values from the profile XML file rather than requiring that these be typed in. Doing at least this much should not be too difficult and would certainly remove some of the tedium of running simulations.

(c) Once we are using actual configuration values, there should be no great difficulty to actually simulate at least some aspects of motor behavior. While simulating things like current draw can't be done without parametizing the motor's characteristics, and simulating closed loop behavior would pose further difficulties, simulating mechanical open loop behavior is not that difficult. Indeed, after suffering the frustration of software being written in one country with field testing taking place in two others,
bugs-in-accel-decel-mac-and-mdec
I added just such a subroutine to the my script. Taking motor channel commands, mixing them if needed (using whichever algorithm is returned by GetConfig (_MXMD)), applying acceleration and deceleration to get motor power and un-mixing those to get vehicle movement is just not terribly difficult and massively cuts down the number of iterations that have to be physically tested to find bugs that are actually evident even with a minimal simulation. Even if one takes the precautions of testing first with wheels off the floor, and then by RC with no one aboard, as much testing as possible should be really be done before powering up a several-hundred pound, multi-horsepower, and very expensive "rocket" or in our case wheelchair. I just set a boolean SimulateMotors = TRUE for initial testing, change it to FALSE once I've gotten typos, unedited copy-and-pastes and other stupidities out of my code (I confess to having had difficulty adjusting to lack of scope in MicroBasic), and send it off for real-world testing.

(d) If possible, simulation should also include joystick or even mouse input to allow exploration of the input "space" without having to repeatedly enter numerical values.

(e) Probably the most difficult of all of these: it would be helpful if simulation output could be shown in two ways -- numerically as it does presently, and in a GUI similar to that of the Run tab (or in the Run tab GUI itself).

My little motor simulation sub-routine requires repeatedly pressing at least the enter key (if no input values need changing), and only yields the normal numerical output. While I can parse the output to get numbers that can be graphed, the simulation via keyboard is so time consuming and the output file is so long that the simulation has to be run in largish "chunks", e.g. 50 or 100 steps to go from motor power = 0 to motor power = 1000, or it takes forever. Simulating things in relatively large steps, however, can lead to artifacts such as overshoots. With graphical output the simulation could be quasi-continuous.

(f) If doing (e) is not in the cards for now, it would still be helpful if the simulator output could also be written to a CSV file that would be easier to import into something like a spreadsheet program.

Lenny Robbins (Siena, Italy)