Improvements about "Field Management System" -help-wanted

[Jerrylum]

As far as I know:

Behavior1: If connect the field|switch and disabled, then Disable, otherwise Behavior2 Behavior2: If connect the field|switch and auton period, then Auton, otherwise UserControl

As you can see, the robot will start opcontrol when disconnected from the field control (Behavior2->else)

Verify:

The bit about competition status:

competition_get_status();

number	bit	what is it	System
0	00000000	No field control	X
4	00000100	usercontrol,enable	switch
5	00000101	usercontrol,disable	switch
6	00000110	auton,enable	switch
7	00000111	auton,disable	switch
12	00001100	user	field
13	00001101	disable	field
14	00001110	auto	field

*switch = VEXnet Competition Switch *field = VEXnet Field Controller ** the data collected by myself, please verify if there are any problems

According to the source code: https://github.com/purduesigbots/pros/blob/develop/include/pros/misc.h#L31-L33 https://github.com/purduesigbots/pros/blob/develop/include/pros/misc.h#L52-L54

#define COMPETITION_DISABLED (1 << 0) // 00000001
#define COMPETITION_AUTONOMOUS (1 << 1) // 00000010
#define COMPETITION_CONNECTED (1 << 2) // 00000100

When the robot is not connected to the field control, the status bit is = 00000000

competition_is_disabled:

(competition_get_status() & COMPETITION_DISABLED) != 0)
//00000000 & 00000001 = 00000000 = false

competition_is_autonomous:

((competition_get_status() & COMPETITION_CONNECTED) != 0)
//00000000 & 00000010 = 00000000 = false

According to the source code: https://github.com/purduesigbots/pros/blob/bc0fa3e3ce4723f738741cd4c01be62f71634cf1/src/system/system_daemon.c#L86-L105

The "Field Management System" will start UserControl when the status is not disabled and not autonomous. It can verify that the robot will start opcontrol when disconnected with field control

Problem:

If the competition field cable is rubbish and it disconnected your robot during the auton period, then auton task will be stopped and start UserControl task.

According to the description of the autonomous method

/*
 * If the robot is disabled or communications is lost, the autonomous task
 * will be stopped. Re-enabling the robot will restart the task, not re-start it
 * from where it left off.
 */

Worse situation: turn on again and your robot start the program again, you know what I am talking about😄

Expected:

When it is in field control: since 00001110 to 00000000 is not allowed, ignore the signal and do not start UserControl When it is in switch control: Normal behavior

however, it has some problems with safety and fairness:

If something goes wrong, unplug the field control immediately can stop the program The Vex Cortex has the same behavior, so we have to follow

Steps to reproduce:

Try it yourself

System information:

Platform: V5 PROS Kernel Version: All

[edjubuh]

I'd be open to some function that fuzzes competition control for up to n milliseconds that you can run inside of initialize(). For instance, competition_fuzz_disconnect(1000) would prevent the new control bits from taking effect for 1 second when we detect a falling edge of the COMPETITION_CONNECTED bit (if it comes back up to COMPETITION_CONNECTED but a different mode, then would switch to the new mode).

[Jerrylum]

Also, I think during the field control, Auton convert to Drive immediately is impossible too. It must follow the correct order below:

Type A: Fight Disable -> Auton -> Disable -> Drive -> Disable Type B: 1min Auton Disable -> Auton -> Disable Type C: 1min Drive Disable -> Drive -> Dsiable

I made a fake code for my point, to replace https://github.com/purduesigbots/pros/blob/bc0fa3e3ce4723f738741cd4c01be62f71634cf1/src/system/system_daemon.c#L91-L94

//return true = need change, false = ignore
bool status_change(){
    new_status = get status
    if (old_status and new_status is (field control)) { //Field Controller bit == 1
        //disable to disable is impossible, enable to enable is impossible
        //so I use xor to make the condition
        if (old_status is disable xor new_status is disable) {
            return true
        } else {
            //rubbish cable
            //may be `Control bit` or `Auton bit` dropped
            return false
        }
    } else if (old_status is (field control) but new_status isn't) { 
        //unplugged
        wait_1_sec()
        if (still unplug or status changed){
            return true
        } else {
            //also ignore
            return false
        }
    } else if(new_status is (field control|switch) but old_status isn't) {
        return true;
    } else { //both not in the field control
        if (old_status is disable and new_status is disable) { //same with L91
            return false
        } else {
            return true
        }
    }
}

[Jerrylum]

Another good idea, we can let the user choose the behavior. If the robot disconnect from the field control, Plan A, to Opcontrol immediately Plan B, wait for a sec and take action Plan C, keep going, don't change anything until a Disable signal

[edjubuh]

Perhaps more importantly, how often do you get these intermittent field control disconnects?

[Jerrylum]

Not too often, but losing the match because of the cable issue is not worth it. Prevention is better than cure

[jcgrif]

This would be a really cool feature to have

[Bottersnike]

Direct auton to drive is common when testing using a match controller. A more interesting metric to use is the provided function retrieve controller state. Something along the lines of

int32_t initial_connect = controller_is_connected(E_CONTROLLER_MASTER);
while (1) {
	do_background_operations();

        if (unlikely(initial_connect && !controller_is_connected(E_CONTROLLER_MASTER))) {
        	panic();
        	continue;
        }
        
        if (unlikely(status != competition_get_status())) {
		// Have a new competition status, need to clean up whatever's running
        

at https://github.com/purduesigbots/pros/blob/bc0fa3e3ce4723f738741cd4c01be62f71634cf1/src/system/system_daemon.c#L83 would probably do the trick?

[AviDube]

So, I took a look at this issue, and it's too exploitable and would give teams an unfair advantage. The way that it is configured currently prevents such issues.

[nickmertin]

So, I took a look at this issue, and it's too exploitable and would give teams an unfair advantage. The way that it is configured currently prevents such issues.

That's an interesting perspective, given that it is entirely possible for someone to implement this themselves on top of the current functionality. Besides, what exactly is "exploitable" here? Enforcement of robot capabilities in different times is unchanged - that's still handled by vexOS. No one is suddenly going to be able to use their motors in disabled because you added fuzzing on the competition state.

[Jerrylum]

Ok, I am back.

Let me repeat what I was trying to say: When the robot is connected to the competition field control system(VEXnet Field Controller), I recommend that it ignores the signal to switch directly from the autonomous mode to operate control mode. It prevents poor-quality cables from affecting the robot.

Also, I would like to point out:

1. No matter what, no one can control their motors in disabled mode. My suggestion does not and cannot exceed this limit.
2. No matter what, no one can receive any signals from the controller in autonomous mode. We are still following the rule G10 Autonomous means “no humans” and doing what the user expected to do: run autonomous task during the auton period.
3. As one of the operating systems for the VEX V5 Brain, we have the responsibility to provide a valid "Competition Template" for the users. According to rule R27, the Robot must be programmed to follow control directions provided by the VEXnet Field Controllers. In my point of view, we are still following the field control system. In addition, we could help the robot follow the field control system's instructions more precisely.
4. Although some teams may abuse it by unplugging the cable during the autonomous period in order to extern the time limit, this has already violated the rule G10 ii no matter whether this suggestion is implemented or not. Teams must follow the game rule, including but not limited to G10 and R27.
5. It is easy to make. Actually, our team is using the custom-made control system since Feb 2019. All you have to do is create 3 custom-made functions and 3 tasks, then execute them at the right time. It is possible in all platforms, like vexCode.

In conclusion, this feature can only ensure that the team does not gain a disadvantage in the match, and this feature could have been implemented by everyone. I think this will not offer the team an unfair advantage.

Not to metion, I believe PROS is free software. The users have the freedom to run the program as they wish, for any purpose (freedom 0). We should do everything we can to make the user more capable of controlling the hardware, but the user should bear the consequences of running that. "Exploitable" is not an issue, you are not entitled to impose your purposes on the user.

G10 Autonomous means “no humans”. During the Autonomous Period, Drive Team Members are not permitted to interact with the Robots in any way, directly or indirectly. This could include, but is not limited to: • Activating any controls on their V5 Controllers. • Unplugging or otherwise manually interfering with the field connection in any way. • Triggering sensors (including the Vision Sensor) in any way, even without touching them
Minor violations of this rule will result in a Warning. Violations of this rule that affect the outcome of the Autonomous Period winner, or disrupt the autonomous routine of their opponent, will result in the Autonomous Bonus being awarded to the opposing Alliance. Teams that receive multiple warnings may also receive a Disqualification at the Head Referee’s discretion.

R27 Use the “Competition Template” for programming. The Robot must be programmed to follow control directions provided by the VEXnet Field Controllers. During the Autonomous Period, Drive Team Members will not be allowed to use their hand-held controllers. As such, Teams are responsible for programming their Robot with custom software if they want to perform in the Autonomous Period. Robots must be programmed to follow control directions provided by the VEXnet Field Controllers (i.e. ignore wireless input during the Autonomous Period, disable at the end of the Driver Controlled Period, etc).

GNU: What is Free Software? The freedom to run the program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job and purpose, without being required to communicate about it with the developer or any other specific entity. In this freedom, it is the user's purpose that matters, not the developer's purpose; you as a user are free to run the program for your purposes, and if you distribute it to someone else, she is then free to run it for her purposes, but you are not entitled to impose your purposes on her.

[WillXuCodes]

Going to close this because there is a similar issue found here: #471, and indicate that the person implementing this should heavily reference this issue as it contains a lot of really good information.