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.