Changing parameters on the fly?
 

Does anyone know a slick way of changing some parameters on the fly. My wife is going to attempt to tune our PID routines we have setup with crumby default values; and I want to avoid modifying a #define in code and redeploying 80 times in a day.

I've thought about attempting fopen or something like that, but that still requires me to filezilla something down there ( or SSH/terminal somehow into the robot)

If the fopen is on the right track, I'm not quite sure how I go about cracking into the robot, so a link to a guide or some instructions for that would be awesome.

Are there any sneaky methods that we could use from the driver station maybe?

Thanks in advance! ::rtm::

Re: Changing parameters on the fly?
 

You could program some joystick buttons to bump the gains up and down.

Crude, but simple and effective.

Each time you bump a button, display the actual value on your driver station so you know where you're at.

Re: Changing parameters on the fly?
 

Thanks, for the idea; however over dinner I realized what I think I should do is simply debug the robot, and set watches on P,I,D temp values that get loaded each time the PID starts, and set a breakpoint, so I can modify the values from the debugger and resume.

:D answered my own question.

Re: Changing parameters on the fly?
 

Yeah I've been in the same situation, and idealy I'd like to use the smart dashboard to set the values like:
But I could never get it to work at all.

Re: Changing parameters on the fly?
 

Alright folks,

I've got answers....

Indeed - we agree that SmartDashboard::GetInstance()->GetDouble("name") does not work...however, we did find that GetString() **DOES** work. So, here's an iterative solution...

1) You **MUST** use the smartdashboard app on a separate computer due to the fact that hitting ENTER will disable the robot.

2) You must retrieve your "double values" as strings and then convert them to double/float values... see below...

3) When in operation, you simply tune your PID values by entering a new value into one of the boxes and hitting ENTER (on the 2nd laptop....see #1) and the new value will be put into the PIDController immediately so you can see the difference. When you're happy with the results, record your P,I, and D and put those into your real code. Tada.

Bob...

Re: Changing parameters on the fly?
 

The shell provided for the operating system is really a C interpreter. So you can define a global in your code then simply change its value from the command line.

in your C++ code:

extern "C" { float iMyPidGain; }
then from the VxWorks shell:

% iMyPidGain = 0.001

Re: Changing parameters on the fly?
 

Keith,
Are you talking about the terminal console via the VxWorks menu (ie. Netconsole output) ??

I've never heard of this...can you point to some documentation on it?

bob

Re: Changing parameters on the fly?
 

Yep, wtx console and host shell are both C interpreters. I never use netconsole but I assume it is also. If netconsole is the resident shell accessed via telnet, it definitely is a C interpreter also.

Help->Help Contents->Wind River Documentation->Guides->Host Tools->Wind River Workbench Host Shell Users Guide->Part 1->Using C Interpreter with VxWorks 6.X

Re: Changing parameters on the fly?
 

This is really big news that I believe VERY few people know of...if I have 'external' access (on the fly) to my program's variables in an interpretive way, well...the possibilities are HUGE.

I'll be trying this with my programmers tomorrow for sure!

bob - Team 1967 Mentor - The Janksters

Re: Changing parameters on the fly?
 

This feature is one of the most productive things about Wind River's setup. Remember that it is 'C' interpreter, not C++. To get your symbols into the symbol table (and thus accessible) in a usable format (not mangled by the C++ compiler), be sure to put them inside a extern "C" clause.

We use this all the time: to turn on/off the collection of data, play with operating params (like PID constants), enable/disable features while debugging etc. It definitely works!

Good luck!

Re: Changing parameters on the fly?
 

I personally use LV, so this problem is trivial for us, but would it be possible to have a CSV file stored on the robot that it reads from? So that if you modify the values, it's behavior will change?

Re: Changing parameters on the fly?
 

from the original post:

Re: Changing parameters on the fly?
 

Can you access members of a structure? For example:

Re: Changing parameters on the fly?
 

No - can't do that directly. The interpreter does not have the benefit of things the compiler/preprocessor would know. Constants are also of no use.

If you know the offsets into the structure you can do it manually with the memory modify commands.

HTH

Re: Changing parameters on the fly?
 

Wow - I just tried it and it certainly works. Really cool.

If only there was an inverse of c++filt...

The debugger also provides a nice way to do this, but with more complex multithreaded applications debugging's bound to get tricky...

SmartDashboard is the future though. Once they can actually get it working, that is :P

Re: Changing parameters on the fly?
 

Is there any other way to do this without having to have a second computer? It would not be ideal to have to laptops running at the operator's console...

Re: Changing parameters on the fly?
 

It is possible to save data to a text file on the cRIO,
and to read it back. Team 1425 has done this in the past.
Having a robot ability to update tunable parameters without firing
up WindRiver workbench is a great time saver.

This works wonders when you need to calibrate some component that is
likely to get adjusted during normal maintenance and repair during
competition.

I'm currently trying to get the team I'm working with in MN (3765)
to recreate this.

The neat thing about creating ascii based files is that you can use external tools to view them.

Last night I was showing the team how you can use the robot's built in FTP server to look at the file system on the cRIO. We looked at the system install files and noted the changes and deletions that happen when code is deployed and undeployed from workbench. We also used the ftp server to create a team data directory on the robot as a location to create our persistent data files.

On a PC that is connected to your team's robot, you can use ftp to browse the robot's file system by opening a web browser and using the URL:

ftp://10.XX.YY.2/
10.XX.YY.2 being the standard FIRST defined IP address for your robot.
Note that the protocol part of the URL is ftp - not http like you see during
regular web browsing.

This will give you a file listing of the root of the robot file system, and you can browse down into the various sub-directories.

The web browser is a good place to start since it gives a read-only view of the file system. You want to be sure that you don't modify any of the existing files there, without fully understanding the consequences.

Re: Changing parameters on the fly?
 

We ftp text files to the robot and read them all the time. Our autonomous behavior is implemented with a special script language.

HTH

Re: Changing parameters on the fly?
 

I will be working this weekend on doing a non-2nd-laptop SmartDashboard text-input experiment which you could try yourself if you're so inclined...

Basically, it is my understanding that the text box is "filled" and noted as such when you tab away or change focus, but the "GetString()" call doesn't notice it yet. So, I'm thinking that if we put a BUTTON on the screen which says "Commit Changes", that possibly in that function, we can do the GetString() and maybe get the changed values back out.

We'll see...

bob

Re: Changing parameters on the fly?
 

You can always declare a driver station object and make use of the GetAnalogIn which has four inputs.

Re: Changing parameters on the fly?
 

We do this all the time. We have many variables that we can adjust all the time.
you can see the code as part of our 2010 code.

http://www.frc272.com/seminar/Archive/.

We call the LCConfig.cpp. You can change the config file, save it via FTP to the Crio, press a button and have it read in to the running code then have it apply the new settings. Once you like them leave it there. The config is read in when we boot up. Very flexible.

Re: Changing parameters on the fly?
 

Well - we gave a shot at the interactive input on SmartDashboard with no luck. It all works on a separate computer as we've all noted, but otherwise...sigh. We tried to also put a button on the SmartDashboard so we could interactively click on the button ... no go...

So, SmartDashboard::GetInstance()->GetDouble() doesn't work... so we use GetString() and then sscanf() to turn it into a double.

Also, using Preferences::GetInstance()->PutString() doesn't work, but PutDouble() and PutInt() work just fine.

bob

Re: Changing parameters on the fly?
 

You should check out the SendablePIDController, which is part of the SmartDashboard. I'm not sure if it works in C++ because of the double issue... but it works for me in python :)

And, before there was SmartDashboard, there was WebDMA, which does the same thing as SmartDashboard except with a webserver on your robot. :)

Re: Changing parameters on the fly?
 

Have you filed trackers for these issues? If they aren't tracked we don't know about them and are less likely to fix them.

http://firstforge.wpi.edu/sf/tracker....wpilib_c_bugs

Thanks,
-Joe

Re: Changing parameters on the fly?
 

We code joystick->GetZ() to use the "throttle" input roller to return a float in the range -1.0 to 1.0 inclusive. One can then tune with several joysticks while observing the the behaviour of the 'bot. Or fine-tune by dividing the z axis value by 10.0, etc.

Re: Changing parameters on the fly?
 

Joe,
Thanks for the link to the trackers -- I filed 3 for:
- SmartDashboard::GetDouble() doesn't work for interactive data.
- Preferences::PutString() doesn't work at all
- SmartDashboard::PutInt() graphs/logs an incorrect (huge) value once in a blue moon causing graphs to become unreadable until the errant data-point scrolls off the graph.

Bob Wolff

Re: Changing parameters on the fly?
 

I just noticed the analog and digital inputs in the driver station last night, wasn't quite sure if they did what I thought they did :)

Seems like a more smooth way of tuning these things, I'll have to give it a try (we wound up swapping our tires which messed with all the PIDs :ahh: )