While using Command Based Robot code I am getting the following error for each of my SubSystems
Warning: module [what I guess is an address in the symbol table] holds reference to undefined symbol [some number]CommandBase[Hex Value][name of symbol]
It then unloads the FRC_UserProgram.out causing a “No Robot Code” error.
Now the weird part, on a whim I changed the reference name (via the refactor menu) to something different. The error never changed. I searched for every instance the old name and none were found. This makes me question whether the updated code is being put onto the robot.
I’m not sure what help I can be - we don’t use the command-based robot code. No doubt you know this but for the students out there - when we load kernel modules we use a dynamic linking loader but it is a single pass linker unlike the multi-pass linker we use to combine object modules and libraries form the command line. The process is much like loading a kernel module in Linux or a dynamic driver in Solaris.
So you are loading a kernel module that has a symbol in it that cannot be resolved against the symbol tables of all modules (and the kernel) already in memory. From your description, the symbol is a mangled C++ symbol.
When you build the command-based code, do you need to pre-link a library with your application code (with a -l parameter on the linker command line)? I will look at the command-based stuff and get back to you.
The command-based robot does not link to any extra libraries, only to WPILib.a, so that is not the problem. Do you include a customized version of CommandBase.cpp in your project? I see that class has 3 static members - init, OI and examplesubsystem)? Do you have instances of all 3 declared somewhere?
#include "CommandBase.h"
#include "Commands/Scheduler.h"
CommandBase::CommandBase(const char *name) : Command(name) {
}
CommandBase::CommandBase() : Command() {
}
// Initialize a single static instance of all of your subsystems to NULL
OI* CommandBase::oi = NULL;
DriveTrain *CommandBase::chassis = NULL;
Elevator *CommandBase::elevator = NULL;
Intake *CommandBase::intake = NULL;
Shooter *CommandBase::shooter = NULL;
void CommandBase::init() {
// Create a single static instance of all of your subsystems. The following
// line should be repeated for each subsystem in the project.
//examplesubsystem = new ExampleSubsystem();
chassis = new DriveTrain();
elevator = new Elevator();
intake = new Intake();
shooter = new Shooter();
oi = new OI();
}
#ifndef COMMAND_BASE_H
#define COMMAND_BASE_H
#include "Commands/Command.h"
#include "Subsystems/DriveTrain.h"
#include "Subsystems/Elevator.h"
#include "Subsystems/Intake.h"
#include "Subsystems/Shooter.h"
#include "OI.h"
/**
* The base for all commands. All atomic commands should subclass CommandBase.
* CommandBase stores creates and stores each control system. To access a
* subsystem elsewhere in your code in your code use CommandBase.examplesubsystem
*/
class CommandBase: public Command {
public:
CommandBase(const char *name);
CommandBase();
static void init();
// Create a single static instance of all of your subsystems
static DriveTrain *chassis;
static Elevator *elevator;
static Intake *intake;
static Shooter *shooter;
static OI *oi;
};
#endif
They are indeed all stubbed out, the Create New SubSystem option in the context menu on the project tends to create fully stubbed out subclass of SubSystem.
I attempted the commenting out solution, none of the modules would load.
In this thread from a couple years ago the poster had a similar problem. For him, doing a clean reinstallation of WindRiver and all the updates fixed the issue. I would try installing WindRiver to its default directory for good measure.
Time to check with the author I reckon - perhaps try the nmppc utility and see if you can identify the unmangled symbol name? Is the 4 Feb update required to support the command-based templates? And if so, is your development environment up to date?
Hey - we do something like this but it is all home brewed. It cleanly separates the behaviors into classes/tasks though and uses a message passing mechanism to isolate each function. It makes life much easier for the student programmers, they can focus on simple tasks as if they were a single program.
PM me an e-mail address and we’d be glad to share the current code with you.
have you declared all the static members somewhere other than the class definition? it’s a dumb problem with c++ but if you dont, the compiler wont actually create a symbol for the static class member.
I’ll throw my 2 cents in. We’ve had some whacky problem in the past which were never fully explained, but sometimes doing a Project->Clean… will rinse out the garbage and get you back to sanity. I would suggest doing it as there should be no ill effects from a clean at all and only potential up-side.
I’m having the same error. I thought it was because of a class I made for a sensor, but I removed the class and the error continues. Warning: module holds reference to undefined symbol round. In debug I get the screen attached.
Don’t know if this helps, but on my error it had to do with the math.h include. Even though winriver has it and it has the round feature. I think the crio has something different. Either ways I made my own round function and it worked fine. Your error is wpilib related. I’m thinking maybe if you run the winriver update and format the crio, maybe the wpilibs will be in sync.
In normal commands we implemented each command in it’s own .h file.
We found our selves constantly leaving out implementations of empty methods.
ex.
~ArmUpCommand();
instead of
~ArmUpCommand() {}
and
Execute();
instead of
Execute() {}
The best way to narrow it down it down that we found is to comment all the subsystems and uncomment them one at a time until you can narrow it down to a particular subsystem or command.
If you’er still stumped then you can post that command or subsystem and the CD community can hopefully help you out.
