Making Debugging Easier

[dm0ney]

I've had several ideas to make debugging easier on us programmers or even just checking out the robot between matches.

Currently we have an autonomous selector switch on our robot. I inserted a special 'debug mode' that we can put any autonomous sequence in and test it and when we run out of time and cant reload code, its not a big deal.
Stemming off that, I was wondering what other ideas or solutions fellow programmers have had?

My next change to our code once the 'No Work' period is ended for our team (Nationals) is going to use a toggle switch on our OI to enable or disable printfs for pots and encoders. Those two are by far the two most used printfs on our team, so I hope to make it easier for us programmers to work.

Also, has any team used the Dashboard to read pot or encoder values? That was going to be another project on the horizon which I believe is exempt from the 'No Work' period because its not actual work on the robot.
Currently we use the dashboard to trim joysticks, although we did use it to monitor pwms before we got our robot to test code.

A few ideas in the works for later this year or next year are:

Three Pots that can plug into the OI and be used to tweak PID gains rapidly.
Utilizing the leds on the OI we have to enable us to deadband joysticks sans dashboard
Mini Dashboard viewer instead of a laptop (possibly pocketpc or the like)
Wireless programmer for use in those few hours programmers actually get the robot right before shipping it away.
???

These are all ideas which we have YET to get working but please add what programming easter eggs you have put into the code to make your life easier.


EDIT:
Dashbord Config of pots and encoders in although since only 4 digits, I have a call that looks somethin like this for encoders:

User_ByteX = (int) abs( (int) Get_Encoder_Counts(LEFT)) % 1000;

Trim joysticks done sans laptop using the userbytes so dashboard or OI itself, still working on a more compact dashboard display.

[Mike Soukup]

Originally Posted by dm0ney

These are all ideas which we have YET to get working but please add what programming easter eggs you have put into the code to make your life easier.

The best addition I ever made was to print out joystick & pot values on the OI using the user byte. Flip a switch, move a joystick up/left and the joystick value is printed in the user mode display. Flip another switch, move a joystick up/left and a pot on the robot is printed. It saved me the time of downloading debug software whenever a pot was in question or was replaced. It also allows the drivers to calibrate the joysticks before every match & get the values perfect.

[Ryan Cumings]

Something that won our team an award from last year was a "debug box". It doubled as our arm control mechanism, but it had a big red button on it that said debug. When you were in debug mode you could hit a combination of 4 keys (or more) to change the way the robot operated. The changes would then be stored in the flash (?) memory so next time the controller booted, it would use the saved changes. The idea was to preprogram as much as you can to not need to recompile the program to do mundane changes.

A list of features was
- Enabling and Disabling the Right or Left motors
- Inverting the polarity on the Right or Left motors (this was useful for motor replacement)
- Changing the operator drive mode from one stick, two stick, or ultra topic secret mode
- Selecting which autonomous program to run
- Motor dampening
- Enabling and disabling specific debug statements
- Having one test autonomous program that you could hot script and save

This year we were planning on getting an rj-45 jack and hooking it into the digital ins/outs and then having a project box with LCDs on it as well as a keypad. The project box would then be able to hot plug into the robot and the LCDs would make a menu of sorts to replicate the same function as described before. They could have also been used to display output variables and such.

[Alan Anderson]

Most of the pins on the programming port aren't used. I made a pair of "breakout" connectors that steal pins 7, 8, and 9 from the programming cable and provide remote control of the robot reset and program buttons. The RC end has a "pwm" cable connector for the remote switch pins, and the computer end has a two-way rocker switch with red=RESET and green=PROG sides (though a pair of momentary switches would work too).

Without this, the programmer has two options: either get up from the computer and kneel down by the robot to press PROG every time, or shout "Please press program!" and wait for someone to comply. When the robot was on our practice field, connected by a 25-foot cable, on the other side of the alliance station wall from the programmer, the remote switches were very handy.

[dm0ney]

Originally Posted by Alan Anderson

Most of the pins on the programming port aren't used. I made a pair of "breakout" connectors that steal pins 7, 8, and 9 from the programming cable and provide remote control of the robot reset and program buttons. The RC end has a "pwm" cable connector for the remote switch pins, and the computer end has a two-way rocker switch with red=RESET and green=PROG sides (though a pair of momentary switches would work too).

I DEFINITELY love that... throwing this out there, any ideas why sometimes IFI Loader can put the RC into program mode and then mysteriously cannot most other times?

I'm definitely going to look into doing a breakout connector like the one shown.

I actually wrote an implementation of some code that I can drop in at a later date today to allow the printfs to become obsolete and use the dashboard instead... I suppose its on to creating a dashboard prog to run on a pocketpc, palm, or somethin else.


"If mechanical can have their labeled blocks of wood for tap and drill sets, electrical can have their helping hands to solder, us programmers can DEFINITELY have all that and more. "
~D. Mishra

[jgannon]

Originally Posted by dm0ney

any ideas why sometimes IFI Loader can put the RC into program mode and then mysteriously cannot most other times?

The newest version of the master code (version 10) requires that you push the Program button before sending new code. The master code on last year's RC does not have this restriction. At first I thought it was just an idiosyncracy with our new programming computer, but someone from IFI told me that it is indeed a new feature (not a bug, mind you) in version 10. My best guess is that it is intended to make sure that anything you connect to the serial port (like, say, the camera) doesn't accidentally send the data sequence that sets the RC into Program mode and corrupt your code in the middle of a match.

[marccenter]

[quote=Alan Anderson]Most of the pins on the programming port aren't used. I made a pair of "breakout" connectors that steal pins 7, 8, and 9 from the programming cable and provide remote control of the robot reset and program buttons. The RC end has a "pwm" cable connector for the remote switch pins, and the computer end has a two-way rocker switch with red=RESET and green=PROG sides (though a pair of momentary switches would work too). QUOTE]

Can you provide a picture of the words above? Can you point to any IFI documentation that details the programming port?

[devicenull]

[quote=marccenter]

Originally Posted by Alan Anderson

Most of the pins on the programming port aren't used. I made a pair of "breakout" connectors that steal pins 7, 8, and 9 from the programming cable and provide remote control of the robot reset and program buttons. The RC end has a "pwm" cable connector for the remote switch pins, and the computer end has a two-way rocker switch with red=RESET and green=PROG sides (though a pair of momentary switches would work too). QUOTE]

Can you provide a picture of the words above? Can you point to any IFI documentation that details the programming port?

Yea, pinouts would be helpful, or at least what pins are not used.

[Astronouth7303]

We used primarily printf()'s (again) for debugging. (though we had some issues with overlap.)
We took the 8 most significant bits off the pots on our arm and put those in the user bytes. That was very nice, since it seemed the pots were always loosing alignment. (And we were using a 'model' control for it.)

I also opened up PWMs 13-16 for debugging. So I could use CCP2_OUT (or whatever ), etc. for digital outs and pwm13-16 to see values on the dashboard.

[Alan Anderson]

Our software read one of the otherwise unused joystick wheel inputs (yes, we used the old reliable black joysticks for the driver this year) and used its value to select among a set of User_Byte outputs to be viewed by a dashboard program. With the wheel at one end of its travel, it sent (the low 16 bits of) the three encoder wheel values. At the other end, it sent arm potentiometer feedback. Intermediate positions gave internal state information for the arm and drivebase control routines.

A separate "debug mode" switch selected between all of that and the regular "drive mode" dashboard data, which was basically monitoring the autonomous mode selection, the vision tetra detection, and a few feedback bits such as air compressor status.

[Dave Scheck]

Originally Posted by dm0ney

My next change to our code once the 'No Work' period is ended for our team (Nationals) is going to use a toggle switch on our OI to enable or disable printfs for pots and encoders.

We have something similar to this. We have a 3-way switch that changes the OI mode between Driver mode, Joystick calibration, and Aux. The joystick calibration is what Mike described above. The Aux position allows us to remap any of our OI buttons/switches. For example, pressing one of our momentary switches in driver mode will trigger the pneumatics on one of our fingers while in aux mode it will toggle debug prints for the lift height encoder. Once we take it out of aux mode, the prints continue and we can move the lift to verify the state of the encoder. It is a real time saver and I would recommend it to anyone.

[Astronouth7303]

On a similar thing, has anyone tried something so that you can change constants w/o downloading code again? I'm thinking that's going to be my summer project.

[seanwitte]

Originally Posted by Astronouth7303

On a similar thing, has anyone tried something so that you can change constants w/o downloading code again? I'm thinking that's going to be my summer project.

This would be a cool project to work on. I sketched out a simple version but never got around to writing it. I figured the easiest way would be to implement a Get() and Put() function to read and write to the EEPROM and add a proxy layer to marshal calls through the serial port. You would need to tell the PC which EEPROM addresses represent which variables, but that can be encapsulated in a config file. If you write it I would use it.

[devicenull]

Program port pinout is at http://www.ifirobotics.com/docs/program-port-4-7-05.pdf .. pins 9, 4, 6, and 1 are free, I love the IFI support forums

[Astronouth7303]

I always figured it was just standard RS-232 (which it appears to be), though minus a few status lines (fairly common).