Delta's Microcontroller Problem

We are currently trying to figure out what is wrong with the microcontroller #3222. Dante is going to contact Mark Lambert on Sunday...at 6am...so that he can try and figure out what is wrong with it.

Multitasking & Programming Update

Hey guys, it's Daniel!

Dante and I met up with John F. Davis so we could discuss and work some on programming today. We spoke for a bit and began working on multi-tasking/multi-threading which happens to be one of his specialities. After starting very basics, we try adding things and stopping to better understand the concepts of multi-threading. To summarize multi-tasking very quickly, it is a concept that also the CPU to split its 'timeshare' or splits the total amount of time it spends completing instructions of code on each task. What we got done was being able to do 2 things at a time (i.e. move forward a distance, raise/lower arm to a certain potentiometer value for BETA). And after discussing, how that would translate to our autonomous for now is simple.

Right now, what we have are functions that handles only one functionality of the robot (i.e. moving forward, turning left or right, raising lowering a basket).

A general example of a function would be...

void functionA (int para1, int para2,....)
{
/// checking sensors, changing motor powers, completing job
}

Also, our current autonomous is broken up to steps, doing one function at a time.

functionA(500,FORWARD, MAX);
functionB(400,RAISE,MAX);
functionA(200,BACKWARDS,MAX);
....
....
... and so on..

To fix this, we will simply be converting our functions into tasks. However, tasks cannot take parameters, so to get around this we will create functions that will read the parameters of a task
and assign this values to global variables associated with each task.

Therefore, our autonomous we be changed into a new kind of steps with the following structure:

//******************************************************************
//STEP(k):
//******************************************************************
// read in all Task variables into their 'setter' functions
getTaskA_Values(500, FORWARDS, MAX); // changes the global variables used in TaskA for
// moving forward.
getTaskB_Values(400, RAISE, MAX); // changes the global variables used in TaskB for
// raising the arm.

// starting all desired tasks
StartTask(TaskA, highPriority); // highPriority > default priority
StartTask(TaskB, highPriority);

//END STEP
//******************************************************************
// STEP(k+1):
//******************************************************************
...
...
...

Basically, tasks cannot take any type of parameters so the way we get around turning our functions into tasks is creating functions that take in the parameters and assign these values to global variables that will immediately be used in our tasks. This process will be consider one step and our entire autonomous will be consisted of these steps (for now or until we have something else we have to manage).

Also, priority between tasks is another issue we must consider. Before, we were only using functions with one task ( the 'main()' task). No function under any current function could not be run until the current function terminated and returned some value. With multi-tasking, there going to be some cases when we want 1 task running and other where 4 tasks are running. Therefore Priority comes in to play based on which tasks we want completed for each step. Basically, we will provide a 'highPriority' to all tasks necessary in a step, while main() is assigned the 'defaultPriority' which is less than 'highPriority'. What this does is it allows the number of tasked started in a task to all finish, before main() can continue onto another step, in which a possibly new task or tasks will be started (each of these with 'highPriority').

So, good news for us. I will be implementing this on BETA and EPSILON on Thursday and I will so how much I will get down.

As for what we programming still need to complete, here is the list:

1. Code in and fine tune 1st half (20-30 seconds) of autonomous that includes multi-tasking.
2. Testing any kind of autonomous on the competition template.
- my suggestion is start with having basic stuff on the competition template, then adding our
full blown remote control code and autonomous code.
3. Creating a way to somewhat scan the field for balls ( 2nd half of autonomous ).
4. Find a way to collect balls and go to a wall to dump then out ( 2nd half of autonomous ).
- This is unique to each bot.

So, all in all, we are in decent shape but still have a lot of work ahead of us. Let's keep up the hard work, because regardless I think we will do go over in Dallas.

Hey this is Daniel and I am here to do several things on this post:

1) Test out the blog posting, so this pretty much gets covered.

2) Talk about our what we have and what we still need in terms of programming.

So we have 4 bots:

a) Beta - Fast, single arm-claw type bot.

Remote Control: Complete.
Autonomous: Some.

b) Epsilon - Loader-Basket type bot.

Remote Control: Finalizing.
Autonomous: Very Little.

c) Delta - Combined Loader-Basket type bot.

Remote Control: Done.
Autonomous: Very Little.

d) Gamma - Loader-Basket type bot.

Remote Control: Some.
Autonomous: None.

Delta Autonomous Mode

Ok so I, of course, picked up the broken computer so I was unable to input Delta's autonomous code, but here it is. This is the code from the strategy that they made me:

D = our half (width-wise)of the arena

d = D/2

L = entire length of arena

autodrive(D, BEHIND, 127)

//** = add wait statement

autobasket(LIFT,127)

**

autobasket(DOWN, 127)

autodrive(d, FORWARD, 127)

**

autoturn(90deg, LEFT)

**

autodreeder(INTAKE, 127)

autodrive(~L/3, FORWARD, 127)

**

autodreeder(OFF, 0)

autodrive(~L/6, BEHIND, 127)

**

autoturn(90deg, RIGHT)

**

autodrive(~d, BEHIND, 127)

**

autobasket(LIFT, 127)

**

autobasket(DOWN, 127)

task complete

Delta RC Problem

Ok here we go:

Delta:

the feeder still doesn't work on RC control. It will work perfectly in one direction but then starts to..."sputter" as if the two motors are fighting each other.

The code for that part is:

while(true)

{ blah

blah

blah....

//Feeder button

if(Butn6U ==1)

{

motor[port8] = 127;

motor[port9] = 127;

}

else

{

motor[port8] = 0

motor[port9] = 0

}

if(Butn6D ==1)

{

motor[port8] = -127;

motor[port9] = -127;

}

else

{

motor[port8] = 0

motor[port9] = 0

}

}

I have tried the following with no results:

1. Motor 8 is a reflected motor so I tried switching the reflected motor to motor 9

2. switching the negative from the first if statement to the second if statement(when I do this the feeder spins perfectly in the opposite direction, but then struggles in the same direction it was working fine in before I switched it)

3. switching out the motors physically...well technically Mo did it

4. making none of the motors reflected

5. making both motors reflected

6. checking to make sure the motors are in the correct ports

7. changing the battery

8. making one of the powers negative in each if statement

9. changing the button from the "shoulder" button to the ch7 or ch8 on the face of the remote control

I can't figure this out because I have the exact same code on the basket, except of course with different ports, and the basket works fine

Ok so Delta's basic programming is done, but something is wrong with the code on their feeder and I can't figure out how to fix it

CORE Robot Blogs Introduction

Each team now has their own blog, which should be used by team members to communicate to each other, to SPS, and to club advisors.

Things to report:

1. Progress

2. any problems

3. problem flow chart updates

4. schedule updates

Note: we have not worked out the specifics yet of how we will be sharing documents, such as the design and problem flow charts, so check your blogs for an update from SPS about those details

Thanks!