I thought it would be best to start a general support thread for PROS in order to keep the original thread less bloated with thousands of support requests.
As a starters: can PROS accept the standard C header files that we wish to include in the project (such as math.h or string.h) that are not already included?
-brep
PROS includes the toolchain that has all of these files. I haven’t tested any of them except the math header. C:\Program Files\PROS\toolchain\arm-none-eabi\include
Some yes, some no. math.h is ok, others not (stdio.h last time I checked) as they have function names that clash with the built in PROS functions.
Ok, thanks!
If a program written in PROS is run while not connected to a competition switch, will the manual code automatically execute after the two initialization methods or does the manual function (or autonomous function) have to be called manually in the initialize() method?
If no switch is present it will go directly into operator control.
can some help me with this, I can’t figure out what the problem is.
void LFmtrSet(int speed)
{
motorSet(2, speed);
}
void LBmtrSet(int speed)
{
motorSet(3, speed);
}
void RFmtrSet(int speed)
{
motorSet(9, speed);
}
void RBmtrSet(int speed)
{
motorSet(8, speed);
}
void LiftLeftSet(int speed)
{
motorSet(5,speed);
}
void LiftRightSet(int speed)
{
motorSet(6,speed);
}
void IntakeSet(int speed)
{
motorSet(1,speed);
}
my error window
my console
16:07:40 **** Incremental Build of configuration Default for project T#3C0D3 ****
make all
CC -I../include -I../src ArmMovement.c
In file included from ArmMovement.c:1:0:
NamedMotorsAndSensors.h: In function 'LFmtrSet':
NamedMotorsAndSensors.h:4:2: error: implicit declaration of function 'motorSet' -Werror=implicit-function-declaration]
In file included from MiscFunctions.h:1:0,
from ArmMovement.c:2:
../include/API.h: At top level:
../include/API.h:407:6: warning: conflicting types for 'motorSet' [enabled by default]
In file included from ArmMovement.c:1:0:
NamedMotorsAndSensors.h:4:2: note: previous implicit declaration of 'motorSet' was here
cc1.exe: some warnings being treated as errors
make[1]: *** ../bin/ArmMovement.o] Error 1
make: *** [src] Error 2
16:07:43 Build Finished (took 2s.251ms)
it can wait until after worlds, not in a huge hurry.
It appears as if #include “NamedMotorsAndSensors.h” occurs before #include <API.h>, so motorSet() is used by your functions before API.h gets a chance to declare it. <API.h> should be included before other files so that built-in functions get defined.
That fixed, now I hit ave new errors. The only thing in the error window was make: *** [bin/output.elf] Error 1 but this showed up in the console:
17:37:22 **** Incremental Build of configuration Default for project T#3C0D3 ****
make all
CC -I../include -I../src ArmMovement.c
CC -I../include -I../src EncoderMovement.c
CC -I../include -I../src auto.c
CC -I../include -I../src init.c
init.c: In function 'initialize':
init.c:63:7: warning: unused variable 'count' -Wunused-variable]
CC -I../include -I../src opcontrol.c
opcontrol.c: In function 'operatorControl':
opcontrol.c:72:7: warning: unused variable 'Btn8D' -Wunused-variable]
opcontrol.c:71:7: warning: unused variable 'Btn8R' -Wunused-variable]
opcontrol.c:67:6: warning: unused variable 'C2RY' -Wunused-variable]
opcontrol.c:66:6: warning: unused variable 'C2RX' -Wunused-variable]
opcontrol.c:65:6: warning: unused variable 'C2LY' -Wunused-variable]
opcontrol.c:64:6: warning: unused variable 'C2LX' -Wunused-variable]
opcontrol.c:62:6: warning: unused variable 'C1RY' -Wunused-variable]
LN ./bin/ArmMovement.o ./bin/EncoderMovement.o ./bin/auto.o ./bin/init.o ./bin/opcontrol.o ./firmware/libccos.a -lgcc -lm to bin/output.elf
./bin/EncoderMovement.o: In function `LFmtrSet':
EncoderMovement.c:(.text.LFmtrSet+0x0): multiple definition of `LFmtrSet'
./bin/ArmMovement.o:ArmMovement.c:(.text.LFmtrSet+0x0): first defined here
./bin/EncoderMovement.o: In function `LBmtrSet':
EncoderMovement.c:(.text.LBmtrSet+0x0): multiple definition of `LBmtrSet'
./bin/ArmMovement.o:ArmMovement.c:(.text.LBmtrSet+0x0): first defined here
./bin/EncoderMovement.o: In function `RFmtrSet':
EncoderMovement.c:(.text.RFmtrSet+0x0): multiple definition of `RFmtrSet'
./bin/ArmMovement.o:ArmMovement.c:(.text.RFmtrSet+0x0): first defined here
./bin/EncoderMovement.o: In function `RBmtrSet':
EncoderMovement.c:(.text.RBmtrSet+0x0): multiple definition of `RBmtrSet'
./bin/ArmMovement.o:ArmMovement.c:(.text.RBmtrSet+0x0): first defined here
./bin/EncoderMovement.o: In function `LiftLeftSet':
EncoderMovement.c:(.text.LiftLeftSet+0x0): multiple definition of `LiftLeftSet'
./bin/ArmMovement.o:ArmMovement.c:(.text.LiftLeftSet+0x0): first defined here
./bin/EncoderMovement.o: In function `LiftRightSet':
EncoderMovement.c:(.text.LiftRightSet+0x0): multiple definition of `LiftRightSet'
./bin/ArmMovement.o:ArmMovement.c:(.text.LiftRightSet+0x0): first defined here
./bin/EncoderMovement.o: In function `IntakeSet':
EncoderMovement.c:(.text.IntakeSet+0x0): multiple definition of `IntakeSet'
./bin/ArmMovement.o:ArmMovement.c:(.text.IntakeSet+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
make: *** [bin/output.elf] Error 1
17:37:28 Build Finished (took 6s.486ms)
Are you trying to use ROBOTC syntax on PROS? Can you post, private message, or [EMAIL=“edjubuh@elliotjb.com”]email me your code?
Here’s my code, I’m trying to port my ROBOTC code to pros, I have got most of it done.
T#3C0D3.zip (1.06 MB)
I fixed up a few things.
The first thing I did was create a header file for your extra functions. In order to use the functions, you’ll need to include the “.h” file. The header file (.h) contains the definitions for your functions and the source (.c) contains the actual functions. This allows you to include the same functions across multiple documents. You probably already noticed that you can’t include the same “.c” file. This is because you’re redefining the same functions multiple times, which leads to issues because C can’t handle overloading.
Your operator control was also responding to joystick controls set at the beginning of the operator control, before it hits the infinite while(true) loop.
The code successfully compiles. Please let me know if you’re not getting the desired results.
Hope this helps!
VEX Support.zip (1.07 MB)
Thanks a lot, this is really informative.
Is there anything built into PROS to see the sensor values or is that something that can only be viewed with the printf() function?
Got an LCD Screen? That will work.
Otherwise, no. You need to set up the Terminal window.
Okay, I need some help with that. I get these errors and I’m not sure what they mean
passing argument 1 of ‘printf’ makes pointer from integer without a cast [enabled by default] PrintValues.c /T#3C0D3/src line 26 C/C++ Problem
passing argument 1 of ‘printf’ makes pointer from integer without a cast [enabled by default] PrintValues.c /T#3C0D3/src line 23 C/C++ Problem
passing argument 1 of ‘printf’ makes pointer from integer without a cast [enabled by default] PrintValues.c /T#3C0D3/src line 20 C/C++ Problem
passing argument 1 of ‘printf’ makes pointer from integer without a cast [enabled by default] PrintValues.c /T#3C0D3/src line 17 C/C++ Problem
what does that mean?
#include"API.h"
#include"ArmMovement.h"
#include"EncoderMovements.h"
#include"main.h"
#include"MiscFunctions.h"
#include"NamedMotorsAndSensors.h"
#include"PrintValues.h"
void ValuePrint()
{
int C1LX = joystickGetAnalog(1, 4);
int C1LY = joystickGetAnalog(1, 3);
int C1RX = joystickGetAnalog(1, 1);
int C1RY = joystickGetAnalog(1, 2);
printf("C1LX is at:");
printf(C1LX);
printf("C1LY is at:");
printf(C1LY);
printf("C1LX is at:");
printf(C1RX);
printf("C1RY is at:");
printf(C1RY);
}
how do i convert an int to a string
Some people in my region have reported that PROS makes robots more delicate to static. Is this true, and if so, how do you mitigate this? If this is false, what other actions can be done to minimize static
I am no expert, but that sounds bogus to me. This isn’t hard proof to the contrary, but we have had PROS for a while on multiple robots have had no issues with static. Granted, issues occur that make no sense in robotics sometimes, but I have no idea what your programming environment or operating system has to do with static.
Well if you aren’t using IMEs so you shouldn’t have any problems.
That may or may not be bogus anecdotal experience. There are software things that can be done to handle static problems when using IMEs which robotc implements. Go back and see my old threads complaining about static and IMEs in toss up where jpearman explained a lot.
Static seems to kind of be a big mystery though. Supposedly the antistatic spray they use helps, but it didn’t help us. I would just not use IMEs whatever I am doing.