rmrobotics / ftc_5421_2014-2015 Goto Github PK

One issue we noticed is the robot being knocked off of course from start up jerking. Probable solution: accelerate and decelerate instead of jumping from speed values in autonomous.

We should figure something out :)

Use AngleTest.c to check if math is being performed correctly

Hierarchy:
TeleOp.c -> Joystick.h
-> Motor.h
TeleOp should send its own motor state to Motor.h and Joystick.h. To enforce hierarchy, we need to make it so that calling Motor.h functions doesn't modify its state

I didn't even know half these functions existed -_-

We need to have the flexibility to modify autonomous on the field, because we usually have communication problems with our alliance partner.

See what Oly Cow did with their config_values function

Should define functions and a motor enum to receive power and motorname commands.

This would make encoder/motor performance more consistent, and probably result in fewer burnouts.

Also for future reference, this is the god of all motor libraries (https://github.com/jpearman/smartMotorLib/blob/master/SmartMotorLib.c), but it's written for the cortex :/

Would make it easier to quickly change robot-specific functions/constants

Should handle all motor configuration pragmas, and speed caps/safety functions.

E.g. add a deadband function, figure out the best way to translate odd joystick commands

• does strafing supersede rotation? etc. should be easily modifiable

The robot can quite easily tip were we to drive off of the cliff side of the ramp during autonomous, so we should check for this and stop before we tip completely. This would most likely require using the gyro

I think this is reaching the point where this is necessary to explain what each file does.

This will most likely have to be done in Joystick.h - when a certain button sequence is held down, a flag is set that breaks out of the while loop and resets everything, then waits for a certain amount of time. So it might look something like this:

while(true) {
  while(true) {
    updateJoystickSettings(joystick);
    joystickInterpret(joystick);
    if(reset) {
       break;
    }
    ....
  }
  killAllMotors();
  wait1Msec(2000);
}

One other thing we talked about was simplifying organization. I'm planning on doing this, this weekend.

We are going to need to decide a way to implement sensors to align the robot with the centerpiece, find the tubes on the ground and then find the center piece tube and how to deposit balls. We have considered to use touch sensors, sonar sensors, and the infrared sensors. The touch sensor to locate the center goal and to locate where the pole is. The sonar sensor to determine the angle of the center piece and the infrared sensor to detect the IR beacon to find the high tube.

This should most likely be implemented as a task that constantly reads/writes current velocity, position, and rotation. Care should be taken with the structure storing data (e.g. use a semaphore)

See this link for sample implementation of rotational stabilization.

See this link for an example of how to integrate the values outputted in order to determine velocity and position.

This link probably has the most advanced code (I haven't looked at it yet)

Currently the way we loop through all motors requires the assumption that the motor definitions are initialized. This means that we have to include the code guard if(motorDefsInitialized), which is very ugly.

We don't want to force code outside of motor.h to use motorDefsInitialized, so all code that loops through motors (such as encoder functions) must be placed in motor.h.

We currently have one function that breaks this rule, which is driveResetEncoders in Drive.h

We have to figure out some way of letting any code loop through all motors. In python we could do this with a generator but this isn't python.. :(

Motor loop is the for loop that loops through all motors and sets power

Would really rather do this than hardcode motors :)

Joystick.c should be easily swappable for different configurations

This breaks Servo.h. I'm going to see if there's a way to rewrite it.
See this link.

robomatter 👎

Currently does not look like they do...

This is very simple, see this link.

See this link.

I think we should go ahead and follow his advice, because he probably knows what he's doing :)
It shouldn't make a difference in terms of code - it'd just mean we put everything that used to be in the Libraries code into the Header files.

What do you guys think?

See if it is possible to include a .c file with all pragma configurations (makes it so that we only have to change them in one place).

It probably isn't possible (Xander says you should just put them in each .c file), but it's so annoying I sort of want to check :)

Suggestions include:
-Changing Motor.h into Motor.c. All motor assignments should only be done in Motor.h, so in theory the pragmas are only need there
-Creating a Setup.c that only has pragmas and then including that file

The way we do the PolarMecDrive calculations makes it so that if we split off the calculations into a separate function, we can then feed that function either a maxSpeed of 100 or a maxSpeed of encoder value and it can spit out encoder values or speed values.

The calculation returns ratios to maxSpeed, so sending it an encoder value for maxSpeed will return the correct encoder ratio. This will make our code more consistent, and will also enable us to do arbitrary encoder fns for any speed, rotation, length.

The servo isn't defining inside the servo.h. It doesn't seem to recognize that the servo was configured.

Peter, I get what you were talking about with the 0-78 thing now :D

Previously, I thought that the old tetrix motors required you to set power to something less than 100 to let you effectively use PID control. Turns out that's wrong: you CAN set it to 100, but (here's what Peter was talking about) you can only set the new NeveRest motors to 78.

However what this means is that now we have to check if the tMotor we're assigning is a NeveRest or a normal tetrix motor, and then cap power respectively.

We'll probably have to do this using a similar technique to what I did with Servo.h - constructing an array of structs that maps each tMotor to its cap speed.

At this point, we should start thinking about whether we can code/get an implementation of a map in RobotC so we get faster lookup times for the motor, seeing as this will be called multiple times per second with each joystick update.

See 4251's helpful description of Tetrix vs. NeveRest.

This will let us dynamically allocate variables so we can properly do stuff like get an array with variable size (instead of hardcoding arrays) .

This will probably consist of creating a byte array with some set size (nxt has 15k max for global variables), and then allocating it.

See this link for AVR's implementation of malloc.

We don't have to get that sophisticated - we could just keep a pointer to the last available memory space and just never free/realloc anything

See this link

and this explanation

All mecanum driving should only be set through this command - makes it much easier to enforce consistent movement.

This function can be used for all drive types and autonomous, etc.

We can try tank drive (one version is implemented like this)

Apparently (thanks again cougar robotics) this is a problem - sometimes the encoder will spit out an entirely wrong value and everything goes haywire. This will be tricky to solve because of the way our encoder code is written right now, as the function for limiting encoder values is not meant to have a delay as it's supposed to be called in a loop... but we can sacrifice that for this if necessary.

This library should contain an initialize() function that is called by all autonomous/teleop programs.

This function should at the very least contain clearDebugStream(), and should also call all motor and servo initialization routines. This way we make sure we don't forget to initialize something that is important.

We can also write something to the debug stream, such as a diagnostic listing the current power level, at initialization after clearing the debug stream.

Thank you Cougar Robotics :) This should be in JoystickDriver.c
nNoMessageCounterLimit = 150; //stop robot faster on disconnects (default is 750)

Frank was talking to us today and told us to make simple functions have simple names, like Min, Max, Constrain, not anything super fancy that it hurts readability.

This could be possibly due to PID, but even if it is PID's fault we'll have to do something about it (such as write our own PID control...?)

Blocking #4

Just so we can consistently refer to them - if names change (such as when Lisa makes us name them after the teenage mutant turtles)

Due to what Peter said about possibly having to replace two motors with non NeveRest motors and also in general, the DesiredMotorVals should always store power from 0 to 100, and only in Motor.h should that get modified

This would involve checking to see if encoder is moving a significant amount, when power is above some certain level. If it isn't moving for a specified period of time, the motors should be turned off. If we want to disable braking as well (make it easier for another robot to push us), they should be set to float speed.

Float speed for HT DC motors (where braking is disabled) is -128 (see this link).

See this link for an example implementation - search for "DriveTask" function.

Should probably be some sort of sequence of sounds (maybe it can spell out EXPLODING in morse code)

This would make sure that we always use a battery at a power level strong enough to last 3 minutes.

What do you guys think of the following debug standard?

• In initialize() of each file, clearDebugStream() must be called and then the name of the currently running program must be logged using writeDebugStream()
• All error codes/errors that are not expected must be logged using writeDebugStream()
• NO VARIABLES should be logged through writeDebugStream(). Instead, set variable allocation to Global Variables (View -> Preferences -> Global/Local Variable Settings, and then run the debugger to view variable contents. Remember to change it back!
• No usage of nxtDisplayString (unless as part of a GUI, like program chooser) is allowed for debugging
• For compilation at competition, RobotC should be set to compile for Best Realtime Performance (View -> Preferences -> Compiler Code Optimization.

Especially in JoyMecanumDrive, would help a great deal with fixing bugs by outputting messages to debugStream/datalog

I can do this really quickly. I just noticed that this was a problem and wanted to make an issue.

With the addition of the metal arm on the servo that is meant to kick the kickstand out, we now have a very long lever on our robot. We should definitely have some sort of obstruction test (maybe with ultrasonic?) before swinging this thing out

Current header is incorrect