There is a certain amount of time required for each Function Call to PTS ( or any other Function ), but the program in the Cortex runs much faster than the Characters can be sent across the Serial Lines to your PC/Laptop. That is why when Sending Debugging Data in EasyC, you Don’t want to send Data EVERY TIME through the Main Loop, only every so many times, otherwise, if the Output Buffer gets Full, the PTS Function will take Longer and Longer, and Slow your whole program down…
That is also why if you can send Binary Data, you send less Bits, for the same amount of Information…
Thanks for the explanation MarkO! I am going to re-time the printing process tomorrow when I have a cortex since I now have a fraction of the number of PTS and Wait commands. If its reasonable then I’ll probably stick with the simpler method. But thank you. Also the explanation of arrays within arrays really helps.
As far as the source code goes, I was referring to changing a few different functions(not the PTS one). But from how you described it, I imagine getting a hold of such code would be an effort in itself, not to mention redistributing the modified one being both difficult and probably illegal?
The serial port runs at 115200 baud, a theoretical max of about 10000 characters per second. Transmit buffer management in EasyC seems screwed up, that’s why we need to put in the occasional Wait() to slow down communications. I think less calls to PrintToScreen is probably more efficient each followed by a Wait to allow the buffer to empty, bad runtime library = more work for the user. You can see I added a Wait() in yesterdays code after sending about 70 characters to the output. Experiment and see what happens.
What do you want to change? Some are hidden, some are not, some could be replaced without too much trouble but I always conclude “what’s the point” and use ROBOTC. I wrote a wrapper for the LCD display function when that was broken last year, we could do the same for PrintToScreen I suppose.
GetJoystickAnalog, GetJoystickDigital, and GetJoystickAccelerometer, the three foundations of all the joystick functions. This is why I have had to rewrite all of the joystick functions so that they include my NewGetJoystickAnalog, NewGetJoystickDigital, etc.
If I could just change the three themselves, I wouldn’t have to rewrite any of the other joystick commands since they all use these within themselves (I’m assuming, if not…well that doesn’t help me then)
Well, that’s possible but we are getting outside the realm of normal EasyC programming. The function that does the real work I think is actually called GetJoystickAnalogReal, there are many things not exposed in API.h. You could also bypass all the built in functions and work directly with the SPI data coming from the master processor by monitoring the external array SPI1_Buffer_Rx. I still not seeing the point though, what’s wrong with the built in functions?
Well I figure I’ll just explain what I’m actually doing and forgo the big surprise.
I’m working on creating a library that will record all values on the joystick for a duration (currently 1 minute) and then allow this to be used to simulate a driver’s input during autonomous. The same code for operator control is used in autonomous with an additional bit of overhead control I have written. I’ve gotten the idea working on my own robot, now I’m trying to generalize it so it can be distributed in a small package that would work on any robot. To do this, I needed to take those three functions and turn them into something like this
NewGetJoystickDigital
If (IsAutonomous())
return array[joystick][channel][z]
Else
return GetJoystickDigital
This requires the end user to replace all of their joystick related functions with my own. The downside to this is that they lose the EasyC interface provided with the joystick functions (like TankDrive). It also gives me a headache having to try and rewrite the more complicated functions like Holonomic and GetDigitalLatch so that they include NewGetJoystickDigital instead of GetJoystickDigital. Also, it means that I now have a bunch of user functions and it takes nearly twice as long o=to build and download…
If I was able to modify the three fundamental joystick funcitons (GetJoystickDigital, GetJoystickAnalog, and GetJoystickAccelerometer) it would mean I wouldn’t have to rewrite all the other functions (I’m assuming functions like Holonomic use GetJoystickAnalog inside of them…) my job would be ALLOT easier. I’m already having a rough enough time rewriting and cleaning up my recording/print function and my autonomous function as much as possible. (It’s works, but it’s not something I think is of the quality I would want to give to another)
As I side note, I was looking into writing something like this for the autonomous routine to clean it up
#include Recording.h
int row = 0
while (row < 599)
{
OperatorControl(.1);
row++;
}
I haven’t been able to get this to work. Is it possible to call the OperatorControl() function inside of the Autonomous() function for 100ms?
I realize this means that there couldn’t be any kind of setup code at the beginning of OperatorControl() since it would run ever 100ms; that would just be the end users consequence for using my library.
What are you doing about determining when input was received? Are you adding a time stamp to each driver input or is the assumption that there will be no delays caused by Wait() functions (or any number of EasyC functions that indirectly call Wait()) ? I think I would perhaps use a repeating timer and monitor the SPI RX buffer.
I don’t think you can call OperatorControl from anywhere (although I have never tried), it’s all part of the odd way EasyC does competition control, although there is a “main” function I think that Autonomous and OperatorControl are called from some of the EasyC startup code.
Sorry for the delay, I’ve been at the Florida TSA State conference and didn’t have a chance to open my laptop until I was home.
For the recording part of the library it runs off of a timer. Each loop it gets the timer, if its greater than 100 ms it presets it to 0 and records all the inputs fro the joysticks. I know that this isn’t perfect since there it doesn’t necessarily start at exactly 100 ms and that it takes time for all the inputs to be recorded. So far this hasn’t caused any problems with my robot, but I haven’t had a chance to test it with any other designs.
I haven’t implemented anything to account for any Wait()s the User puts into his or her operator control code (which is basically copy and pasted into autonomous since I can’t seem to get OperatorControl(.1) to work) but it seems to me that if the Wait(s) are there during the recording part, then it should preform the same during autonomous, again though, I need to test more.
In all honesty, I haven’t a clue what the SPI RX buffer is… Overall I am by far a novice programmer. I have no education related to programming. Whenever I come across a problem I simple research it and find out how to solve it, so my knowledge base is very limited. (So please excuse my terminology. I know I probably use the incorrect programming terms fairly often)
As far as a little bit of an update:
Previously my robot had used IME’s to control arm height with various stages. However, the robot had issues whenever it operated on the field. It was having the hot topic issue of what appeared to be the user process crashing due to static discharge. I made sure to isolate the cause to be the playing surface of the field and therefore disabled my IME’s and went back to using manual control of the arms with JostickDigitaltoMotor since I did not have any optical encoders with me and I was pressed for time.
In the end I discovered a downfall of my recording library. It field to effectively execute the recording during autonomous. The only difference between my previously successful setup and this one was the way the arms were controlled. I determined that since the arm motors’ power is dictated by the battery voltage, this difference in torque output was causing large problems. Even though I always used a fully charged battery, it still did not preform the autonomous mode consistently.
Long story short, I realized the library without any additional user programming (PID loops, etc) is still just a form of time control. It is effect for a drive train over a 15 second period, but for a lift mechanism that requires allot of user feedback when driving, the library is ineffective.
This leads me to ask myself a question that I hope others can input on. Is there any reason to include all of the functions, or would just the three fundamental joystick functions suffice? How many people that would use such a library would be concurrently using the pre-made joystick functions? (the different drives, the different joysticks to motors and servos, etc)
During the roundup season our team implemented a recording library. We decided to use the encoder values rather than the joystick inputs. We started with a continuous timed recording and attempted to play it back but it was not straightforward to get the system to work smoothly. Since we were in a crush for time but had a lot of the framework done we settled on using a stop motion technique. We re-worked the code to ‘record’ sensor values each time the record button was pressed. the Drivers could drive the robot through a series of steps (go and stop) when they stopped they could press record. after the routine was complete, they pressed a different button and the robot would print out the series of encoder values they had just recorded. Later we updated the code to have the robot print the code as the program would use it. It still took a bit of practice to drive / stop / record/ and finally print to get good results. but it was the fastest I’ve ever seen them pull off autonomous programs. They won states that year with 2 autonomous routines. went to nationals an upon discussing upcoming matches with teammates they went over tot he practice field and would add a complimentary autonomous. They went home from nationals with 14 more routines recorded. We still had a number of issues during playback (PID controlled) as we wouldn’t always get to an interim step and the robot would just sit there. We could’ve worked it out I’m sure but in the short term we ran out of time that season. This was all done in Easy C. The next year we switched to Robot C and the game (gateway) had a significantly different emphasis on autonomous. They didn’t bother to re-write the previous year’s code in Robot C as the Autonomous didn’t call for anything that flexible. This year I had a new programming Crew and we never got that far.
Long winded story, but the key is the task can be done either via input recording (I would just record the inputs you wish to play back) or sensor recording (using a good control program such as PID). I have never gone back to try continuous recording or to determine a better method of controlling the autonomous (coming up with the Playbook strategy) but I would like to I’m sure there are better ways than our first attempt.
Thanks fretless_kb,
I too tried recording encoder values first and ran into probably the same difficulties. I moved onto doing what i called a “waypoint system” like your second version and I encountered the same issues as you again. The robot sometimes didn’t travel to a waypoint completely and instead sat there. Therefor I moved onto this new system. Hopefully I can get this working completely and then it will be open game for anyone to use.
Does anyone have some sample code for using Macanum wheels with tank drive in RobotC? We know how to program them with buttons but would like to use one of the joysticks for lateral movement. I am not sure how to do the mixing of the 4 motors on a joystick.
Now that worlds is over I am working on my recording project again (posted a few questions a few posts back). I’ve come back here for some help after more testing.
So far, these are the issues I have encountered.
Linking Errors are they caused by using too much memory or because of too large arrays? In either case, does EasyC support the bool type variable? It would save a ton of wasted bits. Or should I jsut use a char or int and store each button value on a different bit in the variable? (I’ve never done such a thing…)
Battery Voltage differences between recording and playback cause problems. I was looking for theoretical information regarding voltage and power output (is it linear?) and how well this theory applies in the real world.
Finally, I have been looking for an easier programming method than what I am using now. Currently, I have had to recreate all the EasyC joystick functions to include my own version of getjoystickanalog, getjoystickdigital, and getjoystickaccelerometer. Is there a simple way to redefine any of these functions so that they use mine instead of the normal ones? It would save a ton of work and debugging.
My vex robot has a set program where it spins its wheels when I turn it on. Even when I try to download a new competition project to the robot, it still does the wheel spinning action. It seems that neither my controller/joystick or the robot are connecting to each other or accepting the projects that I try to download. Any suggestions?
Try loading a blank program (with no movement code) to the robot. If the wheels are still spinning after the blank program is loaded, double check to make sure that the motors are plugged into the Cortex correctly; the motors are keyed to the motor ports so they should only fit in one way (with the white signal wire closer to the ‘center’ of the Cortex and the black ground wire towards the ‘outside’), but I have seen instances where the plugs are forced in backwards. This is another possible cause of the problems you are seeing (along with what fretless_kb has suggested).
Is there a way to say (if variable1 or variable2) == (a number n) so that you can check if two different variables are equal to the same number at different times without creating multiple if loops?