Code Ran successfully but not being able to deployed

Technical Programming
1

I am sorry if this is consider spamming, but I have posted before but I was not successful in getting a reply. We “Run as WPILib C++ deploy”, in the eclipse console it ran successfully, but the comm light on the RoboRio is still red, and no code is detected on the Driver Station. But here is our robot set up:

  • 4 Talon Speed controllers wiring to pwm port 2-5 on the RoboRio
  • Running on Eclipse Neon.3 Release (4.6.3)
  • RoboRio is approximately 1~2 years old but the image is updated

and here is our code:
Robot.h :

#ifndef ROBOT_H
#define ROBOT_H

//Importing Liraries
#include <memory>
#include <Commands/Command.h>
#include <IterativeRobot.h>
#include <LiveWindow/LiveWindow.h>

//Importing OI and Subsystem file
#include "OI.h"
#include "Subsystems/DriveTrain.h"


//Creating the class robot, inherting from the class IterativeRobot
class Robot: public frc::IterativeRobot {
public:
	//Creating public pointer to the drivetrain subsystem and the oi
	static std::shared_ptr<DriveTrain> drivetrain;
	static std::unique_ptr<OI> oi;

private:
	//Creating a private instance of the live window
	frc::LiveWindow* lw = frc::LiveWindow::GetInstance();

	//Overidding all of the default method
	void RobotInit() override;
	void AutonomousInit() override;
	void AutonomousPeriodic() override;
	void TeleopInit() override;
	void TeleopPeriodic() override;
	void TestPeriodic() override;
};

#endif  // ROBOT_H_

Robot.cpp:

#include "Robot.h"

#include <iostream>
#include <Commands/Scheduler.h>

//Setting up the share Subsystems and oi so that the commands can use it
std::shared_ptr<DriveTrain> Robot::drivetrain = std::make_shared<DriveTrain>();
std::unique_ptr<OI> Robot::oi = std::make_unique<OI>();

//Run once on robot start up
void Robot::RobotInit() {
	//Putting the data of the drivetrain onto the smartdashboard
	frc::SmartDashboard::PutData(drivetrain.get());
}

//Run once when robot is in autonomous mode
void Robot::AutonomousInit() {
	//Put autonomous startup here

}

//Keep running when the robot is in autonomous mode
void Robot::AutonomousPeriodic() {
	//Running an instance of the scheduler
	frc::Scheduler::GetInstance()->Run();
}

//Run once when the robot go into teleoperated mode
void Robot::TeleopInit() {
	//End autonomous code here
}

//Keep running while the robot is in Teleoperated mode
void Robot::TeleopPeriodic() {
	//Running an instance of the scheduler
	frc::Scheduler::GetInstance()->Run();
}

//Test Mode
void Robot::TestPeriodic() {
	lw->Run();
}

//Start the robot?
START_ROBOT_CLASS(Robot)

OI.h:

#ifndef OI_H_
#define OI_H_

#include <Buttons/JoystickButton.h>
#include <Joystick.h>

//Creating the class operater Interface for inputs
class OI {
public:
	//Public contructor
	OI();
	//Public method getJoystick that return the address of joystick
	frc::Joystick* GetJoystick();

private:
	//Private object joy of class joystick
	frc::Joystick joy { 0 };

};

#endif  // OI_H_

OI.cpp:

#include "OI.h"

#include <WPILib.h>

OI::OI() {
	// Connect the buttons to commands
}

//Returning the address of the Joystick
frc::Joystick* OI::GetJoystick() {
	return &joy;
}

Subsystems/DriveTrain.h:

#ifndef DriveTrain_H
#define DriveTrain_H

//Importing classes
#include <Commands/Subsystem.h>
#include <Talon.h>
#include <RobotDrive.h>

//Creating a class joystick under the namespace of FRC
namespace frc {
class Joystick;
}

//Creating a class Drivetrain inherting from the class Subsystem
class DriveTrain : public frc::Subsystem {

public:
	//Public contructor
	DriveTrain();

	//overring the start up command
	void InitDefaultCommand() override;

	//Creating the Tank style drive method
	/**
	 * Tank style driving for the DriveTrain.
	 * @param left Speed in range -1,1]
	 * @param right Speed in range -1,1]
	*/
	void Drive(double left, double right);


	//creating an arcade style drive method
	/**
	* @param joy
	*/
	void Drive(frc::Joystick* joy);

private:

	//Setting up the drive train
	frc::Talon frontLeft { 2 };
	frc::Talon rearLeft { 3 };
	frc::Talon frontRight { 4 };
	frc::Talon rearRight { 5 };
	frc::RobotDrive driveTrain { frontLeft, rearLeft, frontRight, rearRight };


};

#endif  // DriveTrain_H

Subsystems/DriveTrain.cpp:

//Including Files
#include "DriveTrain.h"
#include <Joystick.h>
#include <LiveWindow/LiveWindow.h>
//Including the command file
#include "Commands/ArcadeDriveWithJoystick.h"

//Creating the contructor
DriveTrain::DriveTrain()
	: Subsystem("DriveTrain") {

	//Inverting all of the motor because the motor are wired in reverse
	driveTrain.SetInvertedMotor(RobotDrive::kFrontLeftMotor, true);
	driveTrain.SetInvertedMotor(RobotDrive::kRearLeftMotor, true);
	driveTrain.SetInvertedMotor(RobotDrive::kFrontRightMotor, true);
	driveTrain.SetInvertedMotor(RobotDrive::kRearRightMotor, true);
}

//Run on robot start up
void DriveTrain::InitDefaultCommand (){
	//Settting the default command to be drving this drive train with a Joystick
	SetDefaultCommand(new ArcadeDriveWithJoystick());
}

//Setting up the drive method
void DriveTrain::Drive(double left, double right){
	//Driving with the left and the right parameter
	driveTrain.TankDrive(left, right);
}

//Setting up the arcadedrive method
void DriveTrain::Drive(frc::Joystick* joy){
	//Driving with the Joystick address
	driveTrain.ArcadeDrive(joy);
}

Commands/ArcadeDriveWithJoystick.h

#ifndef ArcadeDriveWithJoystick_H
#define ArcadeDriveWithJoystick_H
//Importing the command class
#include <Commands/Command.h>

//Creating the class inherting from the class command
class ArcadeDriveWithJoystick : public Command {
public:
	//Calling public contructor
	ArcadeDriveWithJoystick();
	//Overidding methods
	void Execute() override;
	bool IsFinished() override;
	void End() override;

};

#endif  // ArcadeDriveWithJoystick_H

Commands/ArcadeDriveWithJoystick.cpp

//Including files
#include "ArcadeDriveWithJoystick.h"
#include "Robot.h"

//Calling the public contructor
ArcadeDriveWithJoystick::ArcadeDriveWithJoystick() :
			frc::Command("ArcadeDriveWithJoystick") {
				//Getting the DriveTrain subsystem.
				Requires(Robot::drivetrain.get());
}

//Run continously while IsFinished return false
void ArcadeDriveWithJoystick::Execute() {
	//Driving the drivetrain with the joystick)
	Robot::drivetrain->Drive(Robot::oi->GetJoystick());
}

// Make this return true when this Command no longer needs to run execute()
bool ArcadeDriveWithJoystick::IsFinished() {
	return false;
}

// Called once after isFinished returns true
void ArcadeDriveWithJoystick::End() {

}

And in the RioLog this is displaying over and over again:

execvp: Permission denied
➔ Launching «’/home/lvuser/FRCUserProgram’»
➔ Launching «’/home/lvuser/FRCUserProgram’»
➔ Launching «’/home/lvuser/FRCUserProgram’»
➔ Launching «’/home/lvuser/FRCUserProgram’»
➔ Launching «’/home/lvuser/FRCUserProgram’»
➔ Launching «’/home/lvuser/FRCUserProgram’»
➔ Launching «’/home/lvuser/FRCUserProgram’»
➔ Launching «’/home/lvuser/FRCUserProgram’»
➔ Launching «’/home/lvuser/FRCUserProgram’»
➔ Launching «’/home/lvuser/FRCUserProgram’»
➔ Launching «’/home/lvuser/FRCUserProgram’»
➔ Launching «’/home/lvuser/FRCUserProgram’»

And in the Driver Station, no code is detected, and on the RoboRio the communication light is red. We do not know why the code is not uploading to the RoboRio, please help, this is the only thing that are stopping us.

P.S: We confirmed that our electrical set up work because I deployed and ran this code on the RoboRio and everything work just fine (Code detected on the RoboRio, We can drive it in the teleoperated mode, and it run in Autonmous Mode):


//Importing all of the class file from FRC
#include <IterativeRobot.h>
#include <Joystick.h>
#include <LiveWindow/LiveWindow.h>
#include <RobotDrive.h>
#include <Timer.h>

//Creating a class robot inherting from the class IterativeRobot
class Robot: public frc::IterativeRobot {
public:
	//Public Contructor
	Robot() {
		//Settting the drive expiration and the starting the timer
		myRobot.SetExpiration(0.1);
		timer.Start();
	}

private:
	//calling and intializing all of our objects
	frc::RobotDrive myRobot { 2, 3, 4, 5 };  // Robot drive system
	frc::Joystick stick { 0 };         // Only joystick
	frc::LiveWindow* lw = frc::LiveWindow::GetInstance(); //Instance of the liveWindow
	frc::Timer timer; //Timer

//Running once before the autonomous start
	void AutonomousInit() override {
		//Resetting the timer
		timer.Reset();
		timer.Start();
	}
//Run while robot is in autonomous
	void AutonomousPeriodic() override {
		// Drive for 2 seconds
		if (timer.Get() < 2.0) {
			myRobot.Drive(-0.5, 0.0);  // Drive forwards half speed
		} else {
			myRobot.Drive(0.0, 0.0);  // Stop robot
		}
	}

	//Run once before the teleoperated mode start
	void TeleopInit() override {
		//Reversing all the drive
		myRobot.SetInvertedMotor(RobotDrive::kFrontLeftMotor, true);
		myRobot.SetInvertedMotor(RobotDrive::kRearLeftMotor, true);
		myRobot.SetInvertedMotor(RobotDrive::kFrontRightMotor, true);
		myRobot.SetInvertedMotor(RobotDrive::kRearRightMotor, true);
	}

	//Run while the robot is in teleoperated mode
	void TeleopPeriodic() override {
		// Drive with arcade style (use right stick)
		myRobot.ArcadeDrive(stick);
	}

	//Running while the robot is in test mode
	void TestPeriodic() override {
		//Running the instance of the live window
		lw->Run();
	}
};

//Starting the robot
START_ROBOT_CLASS(Robot)

I am really sorry for the long post.

2

Your roboRIO and wiring are just fine.
Your code deployed, but crashes from a coding error when the roboRIO tries to start it.
The roboRIO keeps trying to restart your code and it crashes every time, which isn’t surprising. That’s why you see repeated “Launching…” messages.
It probably means your code is trying to use something that hasn’t been instantiated or is instantiated later in the code order.

The RoboRio communication light is red when the DS and the roboRIO are communicating, but the user code is not yet running.

3

So the error in the code? as in a variable or an object was called before it is suppose to be? What can I do/check for to fix this?

4

Do you see any errors in the driver station console?

https://wpilib.screenstepslive.com/s/currentCS/m/java/l/599746-viewing-console-output

5

No, there are no error popping up in the Driver Station Console. the display is the same as the RioLog.
Drive Station Console:

 ➔ Launching «'/home/lvuser/FRCUserProgram'» 
 ➔ Launching «'/home/lvuser/FRCUserProgram'» 
 ➔ Launching «'/home/lvuser/FRCUserProgram'»
6

I’m not familiar with that syntax in the last private block, so maybe I’m out to lunch here figuratively as well as literally, but it looks (for example) like you’re initializing myRobot to be an **array **of four numbers, not the result of instantiating it with four numbers as arguments.

7

Do you have the driverstation setup to display all messages or just errors (which is the default setting)? This can be changed using the little gear at the top left corner of the console viewer. It could be that additional helpful information is being filtered out. To gather some further information about where the error is, you could also add some print statements to your code and see which ones (if any) get printed before it hits the error and resets.

Just curious, is there a reason you do not have constructor for your Robot class? I certainly don’t claim to know every valid syntax for coding in C++ but it seems very odd that you have these lines of code below (which instantiate your drivetrain and OI objects) sitting in your Robot.cpp file but not in a constructor or other class method.

//Setting up the share Subsystems and oi so that the commands can use it
std::shared_ptr<DriveTrain> Robot::drivetrain = std::make_shared<DriveTrain>();
std::unique_ptr<OI> Robot::oi = std::make_unique<OI>();

I also noticed that you derive your Robot class from IterativeRobot, but have other items that appear to reference the structure of the CommandBased base class. I am not really familiar with the CommandBased code (we use SampleRobot as our base class), but this seems unusual and a potential source of confusion. And some of the architecture you have created seems overly complex, (e.g. creating an OI class which just gives you access to the Joystick… why not just add a Joystick object to your Robot class).

8

We are planning to add more to this, (We have two additional motor for shooting mechanism, and another controller to control that) therefore the overly complex oi. We just want to get this working because then we can learn from this and not make the same mistake again. Also, the last code block that I posted in the PS is a separate code that actually work. Can someone post an example of a simple driving robot on CommandBased format? Thank you for your replies

9

All of the FRC examples on our github site are command-based. 2013 is mecanum, the others are tank. The 2015 is the simplest, as it only had three PWM motors. The STEAMworks Developer Boot Camp code is probably the cleanest - done intentionally on an already built robot, then cleaned up in the following weeks. It only has four independent motors - SRX on drive and climber and PWM for the gear pusher, plus two SRX “followers”.

Edit: Oh, wait - skip it as you want C++ rather than java.

10

To my knowledge, there is constructor for the Robot class because in the place of that, we have the RobotInit class, which run once on Robot Start up. Most of the code that we are making are base off of the example command base robot that was given in the FRC plugins, sorry for any confusion because this is the first we are doing FIRST.

11

In case you didn’t know, teams that use C++ are in a significant minority in FRC (less than 15% of all teams in 2016), which is likely why a lot of us aren’t able to help you much.

You would have a much easier time getting help on CD and at events if you used Java (~50% of all teams, 66% of teams on CD) or LabVIEW (~35%). You’ll probably want to factor this in to your decision of what language to use, if you aren’t already committed to C++.

12

Thanks, I will keep that in mind when the actual season come. Also, does programming in C++ an Java have any difference aside from the syntax difference? And what is LabView Programming

13

This is expected. Command provides a template that is built on the Iterative base class.

14

The OI class is standard with Command-based programs, as it is automatically generated when a command-based project is made with WPILib.

Besides syntax differences, (off the top of my head):

  • Java does not have the equivalent of header (.h) files, so all of your code for each Subsystem or Command would go under one file, which is nice.
  • Java doesn’t have pointers (at least, not in the same way that C++ does)
  • Java has built-in garbage collection
  • I know you said “aside from syntax,” but the Java syntax is usually much less confusing than C++.
  • C++ is IN THEORY faster, but in practice it probably doesn’t matter for FRC.

I would say that, in general, Java is much easier to start off with, and it is much easier to teach to any new programmers that you will be bringing aboard, which is super important. It is taught as part of the AP Computer Science A curriculum, if your school offers that as a course. As others have mentioned, it is generally more common among FRC teams, at least partially for those reasons.

LabVIEW is a proprietary language developed by National Instruments (NI), who make the roboRIO. It is a graphical language (some love it, some hate it. up to you) and has its benefits and drawbacks like Java and C++. For example, it is awesome for getting feedback as you can see the state of any variable at any time. But it also takes a while to compile (and it’s graphical, which I personally don’t enjoy). All in all, it’s just another alternative that you can explore if you are interested and/or have the time.

15

We finally fixed it!!!. The problem was with the instantiation of the OI and the Subsystem. Instead of doing it like this:

std::shared_ptr<DriveTrain> Robot::drivetrain = std::make_shared<DriveTrain>();
std::unique_ptr<OI> Robot::oi = std::make_unique<OI>();

I changed it to be like this:

 DriveTrain* Robot::drivetrain = NULL;
 OI* Robot::oi = NULL;

//Run once on robot start up
void Robot::RobotInit() {
	drivetrain = new DriveTrain();
	oi =  new OI();

}

with the pointers for the drivetrain and the oi initialized in the header file as public static pointer:

static DriveTrain* drivetrain;
static OI* oi;

Thank you for all of the help you have provided, without this our team wouldn’t been able to do anything.

16

Although the RobotInit method is called by the framework/base class code once at startup, it is not a replacement for a constructor. C++ code expects that the constructor for any class will instantiate and initialize all class members, like your drivetrain and oi objects.

Understood. If you look that code over you will notice that you have a constructor for your robot class and you don’t have those lines of code sitting there outside of any functions before your RobotInit method. I suspect if you put that code into the class constructor you might have better results.

I would disagree with this statement. There are lots of teams using C++ who are on CD and happy to help. In fact many of those teams are very experienced and have knowledgable programming mentors. I suspect that the longer response time right now is more related to being off-season and heading into the holiday season so many may not be on CD as much as during build season.

I will note that C++ can less forgiving of coding errors and therefore may not be the best choice if you do not have an experienced programmer or mentor. However, C++ is more efficient than Java in its implementation and runtime operation (eg. I have heard that the Java code deployment can be rather slow).

I would also add that C++ is call-by-value where as Java is call-by-reference. This basically means that any parameter that is modified within a function will retain that modified value outside the function. This can be helpful if you want that to happen, but it can be hard to trace down if you are not aware of it happening in someone else’s function that you are calling. (Note that this is related to the “Java doesn’t have pointers” point made above… in C++ you can call-by-reference by passing the parameter as a pointer).

17

This bit is almost certainly wrong. Static means the variable scope is only for the source file it appears in. In your case, that would end up creating separate drivetrain / io variables in each source file the header is included in. That is, the drivetrain var in one .cpp file would be totally separate from the one in another. You probably want to replace “static” with “extern” if you want the var declared in one .cpp file to be visible in others.

18

I believe you’re thinking of the C definition of a static. C++ classes can have static variables that can be public scope as desired. (They still will be restricted to the source file compiling, given that it will be declared in the “.h” file). A class static variable is shared by all instances of the class (and still exists if there are no instances of the class).

And, this is the way this was commonly done when command based programming began. They’ve tried to make a move to smart pointers, but some of us are a bit stuck in our ways.

19

To my knowledge, static mean that there is one copy of the member exist within the code. Since this is a pointer to an object, we wouldn’t want its content to change. Please correct me if I’m wrong, I am still pretty new to programming in C++ and robotics.

P.S: When I try to change the static member to extend, the compiler return an error (two errors, actually).

20

Oh yeah, if they’re class member vars that’s different. I couldn’t tell from the context posted which was which - but given that changing to extern caused errors it seems that they are in a class.