During a practice event at our school on Saturday one of the teams complained that he was constantly loosing the programming of the robot. This has passed to me before, so I was able to explain to him, but has become kind of an annoyance to him.
When he passes the autonomous program to the brain, he forgets to select autonomous and leaves it as teleop. RobotC “passes” the program and you are able to run it, but when you turnoff the robot and turnon and look for the program is not in autonomous. This has happened to me the other way around, so it may be a good idea to reincorporate the error that you used to get when you didn’t select the correct folder.
Agreed. The way Robot C switches between autonomous & teleop is unintuitive. It would be better if that setting were made per program, kind of like sensors and motors. Once you designate a program as teleop is should not inadvertently switch to autonomous.
Thanks for the feedback - We agree that the method of switching between tele-op and autonomous is less than ideal. We’ve tried to come up with various ways to have the compiler do the work (i.e. see if the user is using a joystick or not) but we’ve found it’s wasn’t as reliable as we’d hope.
As for the per-program setting: This is a great idea - we’ve though about it, but were worried that it would force EVERY user to go into motors and sensor setup. Would you ever think of a scenario where you’d want the same program to be both autonomous and tele-op?
I’ll definitely look at implementing the ability for Motors and Sensor Setup to “override” the global setting (from the menus), and then if a user doesn’t specify a program “type” it’ll just default to the global setting. Thoughts?
It seems like most of the time a program would be either Tele or Auton, and that the override should be for exceptions where a program could be both. Would it be possible to have a third option to prompt the user for Tele or Auton when downloading the program to the brain?
Tele-Op -> Requires the VEX IQ Controller (joystick) to be connected via tether or wireless radio for the program to be allowed to run. This is a “master firmware” restriction - basically the master firmware won’t give the ROBOTC Virtual Machine timeslices to run unless there’s a VEX IQ Controller (joystick) present. Once the VEX IQ Controller (joystick) is there, you can run either autonomous or tele-operated code - the robot doesn’t care.
Autonomous -> Ignores the requirement for the VEX IQ Controller and forces the joystick packet of data to always be zero. You can run joystick code here, but you’ll just always get a zero value back from the getJoystickValue() command.
The trouble is we have to mark a program as “TeleOp” or “Auto” when it’s downloaded, so you can’t switch it once it’s already on the brain (otherwise that would be nice). We could prompt the user if the mode hasn’t been selected via the motors and sensor setup and then just plop the configuration code into your program automatically at that point. In a perfect world, there wouldn’t be this requirement, but it’s out of our direct control.
It seems to me there could/should be a bit in the program that gets downloaded, that defines Tele/Auto. THEN, you would not require two “folders” in the menu, and when the program is run, it simply starts by passing the “radio required” bit. I guess that may not be possible, if timeslices are granted.
For the World Championship, my team has 1 tele-op program, and 1 auto program. Last week, they had to download both programs, and they EXPECTED that setting to be part of the program. They said “It’s not remembering what type of program this is”.
Given that this setting is a requirement PER PROGRAM, I would expect it to be included in each program. And, when the motors/sensors are configured, this information should be known.
The trouble is that the architecture that sets the bit of “Tele/Auto” is only know to the main menu interface. Our ideal solution was to only have one entry “ROBOTC Programs”, but the VEX IQ ‘master firmware’ requires the front/main menu program catalog slots to be set to the “Tele/Auto” bit on a per-slot basis… hence the need for two different entries. I agree it’s less than ideal and a bit of a workaround. The catalog slot entry system was developed with software packages that use the front/main menu as the primary means of storage - this limits you to 4 programs on the brain compared to the 16 available to ROBOTC and doesn’t play nice with a Virtual Machine architecture - so we’re stuck having to work around the issue.
I believe what I’ve gained from this discussion is the need for this to be a per-program basis. I don’t think we’ll get this change implemented before worlds (we’re really adverse to releasing updates right before a major championship) but definitely look for this improvement shortly thereafter.
Can the “Run Menu” be changed from “Run - Configure” to “Run - Configure - Run as Auto” then we get the following
My program needs the sticks – Run
My program does not need the sticks, but it’s not ready to solo - Run
My program is ready to solo! - Run as Auto
I know the radio requirement is part of the overall safety of the system to not allow runaway robots (once they are out of radio range they stop) or robots that start up and move unexpectedly.
Still think the per-program needs to be there to say “yes, this may run in Auto”. I’m good with either a pragma (motors and settings) or setting a flag in the code ( bVexAutonomousMode = true; )
Here’s another alternative. Keep only one listing of files, but if you enter the list via the “Tele-Op” menu, the program will require a joystick to be connected / If you enter the list via the “Auto” menu, the program will run no matter what. Then end users don’t have to worry about the type on the PC / at download time… only at run time. You could then theoretically run the same program in either mode whenever you choose.
Not sure why the user has to specify if the joystick is going to be used. Seems like the software/firmware should be able to say “if the joystick is on, use it”
I don’t disagree at all - but it’s not our design (the master firmware and how the radio interacts)…so we have to stick within the constrains provide to us.