Feature Requests and Improvements in ROBOTC?

Hi Everyone!

We originally posted this in the ROBOTC section of the forums, only to find that posting is limited to the OP and Moderators.

The ROBOTC Team is dedicated to meeting the needs of the VEX Robotics community. So here’s your chance to tell us the things you think ROBOTC is missing or could improve on. Your feedback is truly appreciated.

We’re already working on some of the suggestions from other posts, like a consolidated list of all functions and predefined variables in ROBOTC, so keep them coming! :slight_smile:

I would like to be able to write files directly to the cortex. This would be helpful in a recording type mode.

Seconded. Reading and writing to non-volatile storage from code would be an excellent new feature, and having a user-program accessible persistent file system on the Cortex seems to be the easiest way to do this.

That is what I mean. My team leader last year wrote a program last year that outputted all of the motor values and the time to the debug window. He then copied it from the debug window into his program. It then did the same thing. He said it would be nice if he didn’t have to copy and paste it but have the cortex store it in itself.

Also, MICROSECOND TIMING. This would allow the use of the accelerometer for determination of the speed the robot is going.

The ability to have “Projects” made up of multiple files, so if you press compile in a file it will then compile the entire project and not just the current file.

Also it I feel it would be useful to just remove the “Motors and Sensors” popup that comes when you double click on the code, when a file is to be included and so doesn’t the setup and you double click to do some copy paste it keeps bring up the “Motors and Sensors” thing. I think it would be better if it was just found in the “Robot” menu.

Reading and writing to the cortex would be nice but i don’t think it is very necessary. As a college team it would also be REALLY nice to be able to use the I2C port to talk to any sensor we want.

Also it would be nice if the auto code formatting was fixed currently this code


if(a){
//do something 1
}else if(b){
//do something 2
}else{
//do something 3
}

becomes:


if(a){
	//do something 1
	}else if(b){
	//do something 2
	}else{
	//do something 3
}

when i really think it should be


if(a){
	//do something 1
}else if(b){
	//do something 2
}else{
	//do something 3
}

Scott.

Going out on a real limb here, but would an addons system be possible so if users do want extra addons, they can code them and have them included like in a number of IDEs which allow extra addons/plugins to be installed to enable extra features the end user wants (SVN, Sensors, etc)

One word: Documentation.

Amen - Kb :wink:

I would like ROBOTC to have a printf statement with up to 80 character widths for debugging. In addition, the debugger should be able to view selected global and local variables in a Watch window in the IDE.

Another feature that ROBOTC should have is bit fields for structures and full ANSI C compatibility.

How about the ability to control individual pixels on the LCD screen

That would be great. I don’t think it would be possible. The VEX LCD works by use of the UART port. This allows RobotC to send text to the LCD, not control pixels. You can look at it kind of like a keyboard. All of the keys on the keyboard correspond to a letter. If a keyboard just had pixels to press, it would be a lot harder to use. That is why VEX made it controlled by UART.

To control each pixel on a LCD, it would require at least 6 pins. Some require 10. The VEX LCD only requires 3 to operate and one more for the button feedback.

On the VEX LCD there is a power pin (probably 5v), a ground, a TX (transmit), and a RX (receive) pin.

Actually, it is perfectly reasonable to send pixel-level information over a 3-wire serial link like the one the VEX LCD uses to display characters.

The real limitation will be the LCD display panel itself. I’m 99% sure that the display does not have continuous pixel coverage, but just has 5x8 dot rectangles in the 32 specific locations where characters go. That means that you couldn’t draw continuous lines that spanned across multiple character positions; there would be 1-pixel gaps between the character locations.

Further, the microcontroller on the LCD has to support it. Many character LCDs support downloading custom characters fonts, which can be used to simulate pixel-level drawing. It is possible the VEX LCD could be made to support this with new firmware (or perhaps it already does but the ROBOTC and EasyC libraries don’t handle it).

Two features I’d like to see are the ability to use a vex gamepad with the pc emulator. I think that would be really awesome to allow the students to work on the code download to the emulator and allow user control with the gamepad. ideally the interface would work with the standard vex gamepad or less expensive companion gamepad as an input device.

The other feature would be to allow the definition and display of specific data items in the robot. The debugger is really great, but lacks that ability to build a custom ‘heads up’ display of data from the robot.

Cheers Kb

  1. strings need to be larger than 20 chars, 32 would be better, using a char array even better so. For example, the following often has issues, can easily be over the 20 char limit.

sprintf(str, "JoyStick[Ch2] =  %d;",MyEvents*.JoyStick Ch2 ]);

  1. Access to more RAM, 12K is limiting, I know some will be used by the system but the cortex has 64K available (I think).

  2. Access to the flash file system. read would be good, read & write would be better. read & write with flash wear leveling even better.

  3. pointers.

  4. callbacks. ie, pointer to subroutine.

  5. variable args to subroutines, so we can implement things like printf using the available functions.*

Now I understand that this would need a lot of work to implement, but as long as we’re giving suggestions, can we please have re-entrant functions so that we can finally do recursion?

A nice big heads up display would be nice. I’ve had pretty good experience, though, with just using global variables to hold debug info (which show up in the bottom part of the screen), and then using microsoft’s magnifier (Win+R, magnify.exe) to zoom in on it; this way I can make changes to the robot from across the room and see what it’s doing on the screen!

As discussed here Updated motor controllers with DC braking there is support in the Motor Controllers for a breaking mode that requires sending a 200us PWM signal.
It would be great to see support for this in RobotC not sure how it would be implemented though, maybe two functions one EnableBrake() and DisableBrake() and in between it ignores the main motor array?

Scott.

I just ran into this problem while coding last night; no comma operator.

It would be really nice if RobotC supported the comma operator, so that you could have statements like:

int x;
int y;

x = (x == y) ? (y = y + 2, x + 1) : y

For more examples, visit: http://en.wikipedia.org/wiki/Comma_operator

Hi Everyone,

Thanks for the outpouring of suggestions and feedback. :smiley: