T3Bot

Status
Not open for further replies.

se5a

Member
This rainbow mess of wires is my current T3 project:
IMG_0097.JPG


Initialy I had problems with the reversing track coming off the wheels when doing full speed turns on grippy surfaces, the tracks were too loose, so I printed a new front axle holder with two hex screws which push agansed the front axle and tightening the tracks. you can see the hex screw in the side pic:

IMG_0098.JPG


front view:
IMG_0100.JPG

I love my reprap prusa. soo useful. going to have to redesign and print this again for more places to screw sensors and stuff. but that's easy.

I soldered pins on the 'top' side of the T3, and some female headers on the 'bottom' giving me easy breadboard wire access to all the extra digital and analog pads:
IMG_0088.JPG

this sort of worked, till I realized that although I'd put an oogoo spacer between the t3 and the pins to give the usb socket a bit more room between the breadboard and the t3, I still didn't quite have room for the usb plug to fit...
might cut out a small chunk of the breadboard to fix that little problem.


overall the robot is mostly sort of working well, it goes around and around in circles awesomely.
getting it going straight on a compass bearing is proving to be a little bit of a problem, it sometimes gets it right, but will often just spin in circles looking for the heading. I need to mess with it some more while plugged into laptop and read the serial out (I swear, half my code is Serial.print()).
I've found a fair number of mathy type bugs in my code already, but it's still not quite there yet.
I've got it so that I'm storing my desired heading and desired throttle with static vars. then the drive() function checks the desired_throttle and desired_heading functions, gets the current heading, compairs the current and desired headings, figures out how much it can throw the left and right throttle... maybe I should just post a snippet of code instead of trying to explain.

Code:
void drive()
{
    short desired_heading = getset_desired_heading('R', 0); //these two fuctions get or set the desired heading, 'R' since I'm reading them here, 'W' if I wanted to write or set them.
    short desired_throttle = getset_desired_throttle('R', 0);
    
    Serial.println("DRIVE");
    Serial.print("Desired Heading: ");
    Serial.println(desired_heading);
    Serial.print("Desired Throttle: ");
    Serial.println(desired_throttle);
    
    short current_heading = get_current_heading();
    short current_throttle = motor_state('R', 'B', 0); //another use of statics in a function, 'R' read 'B' returns both motors / 2. 'L' would be left 'R' would be right. 
    Serial.print("Current Heading: ");
    Serial.println(current_heading);
    Serial.print("Current Throttle: ");
    Serial.println(current_throttle);
    
    short diff = degrees_difference(current_heading, desired_heading); //degrees_difference function returns the number of deg between current_heading and desired_heading, neg number if desired is 'left' of current.
    short aggro = (diff * 100) / 180; /aggressiveness of the turn. 
    if (desired_throttle == 0) //if we're not moving foward or back, we need to use more juice to turn. 
    {
        if (diff < 10 || diff > -10)
        {
            if (diff > 5 || diff < -5)
            {
                aggro = MIN_AGGRO;
            }
        }
    }
   
    Serial.print("Diff: ");
    Serial.println(diff);
    Serial.print("Aggro: ");
    Serial.println(aggro);
    
    //short left_power = motor_state('R', 'L', 0);
    //short rigt_power = motor_state('R', 'R', 0);
    short left_power = desired_throttle;
    short rigt_power = desired_throttle;
    short unused_left_pwr;
    short unused_rigt_pwr;
    short set_throttle_l;
    short set_throttle_r;
    
    if (diff < 0)
    {
        unused_left_pwr = 256 - left_power; 
        unused_rigt_pwr = 256 - rigt_power;
        set_throttle_l = left_power - ((unused_left_pwr * aggro) / 100);
        set_throttle_r = rigt_power + ((unused_rigt_pwr * aggro) / 100);
    }
    else
    {
        unused_left_pwr = 256 - left_power; 
        unused_rigt_pwr = 256 - rigt_power;
        set_throttle_l = left_power + ((unused_left_pwr * aggro) / 100);
        set_throttle_r = rigt_power - ((unused_rigt_pwr * aggro) / 100);
    }
    Serial.print("Unused_L: ");
    Serial.println(unused_left_pwr);
    Serial.print("Unused_R: ");
    Serial.println(unused_rigt_pwr);
    Serial.print("set_throttle_l: ");
    Serial.println(set_throttle_l);
    Serial.print("set_throttle_r: ");
    Serial.println(set_throttle_r);
    move(set_throttle_l, 'L');
    move(set_throttle_r, 'R');
}

as you can see, lots of serial.prints in my code at the moment. and this is just one function.
first time I've really done anything from scratch in c. little bit of a learning curve. fun though.
might post the whole thing somewhere maybe.

other info:
compass: pololu MinIMU-9 v2
motor driver: pololu TB6612FNG
T3 power: 2xAA with a Pololu 5V Boost Regulator NCP1402.
motor power: 4xAA.
IR object sensors: qrb1114 (one of which I've managed to fry, oops.)

IR sensors is currently hooked up and coded so that if it detects something, it will stop, reverse a little, turn 90 deg from current heading, move forward, then continue with it's last desired heading and throttle orders. I might change that and use them on the tracks to detect actual speed/distance by detecting the gaps in the track. will have to print out a holder for that.
 
Last edited:
Neat project, thanks for posting it! In the past I've also cut away part of the molding on a USB cable jack, to enable connection to a socket with a tight surrounding plastic housing. If it's just a few mm, usually that works OK.
 
Thanks John. Yeah I guess cutting away the molding on the usb jack could work too.

It seems I'm often getting the same reading from the compass all the while it's spinning around in circles. I'm wondering if it maybe too close to the rest of the electronics and maybe getting caught in an em field.
either that or the compass just sometimes acts up. which is a distinct possibility, since when I get the same reading, it is the SAME reading, with very little if any deviation.
could I be trying to read the compass too often? is that even possible?

Edit: I should note, that the compass sometimes works fine, giving a good reading in a full 360deg rotation.

Edit2:
I'm also just doing pretty much exactly the same code as the heading example for the LSM303 currently. the full AHRS example has lots more going on in it, I don't really understand it but maybe I should just incorporate that code instead.
 
Last edited:
just in general, could be a marginal timing issue, marginal voltage level, or a bad contact somewhere? Specifically for a compass, it could get confused by a magnetic field from your drive motor, if it is anywhere nearby, or any parts of steel / iron / magnetic in your assembly. My suggestion would be to get some jumper wires and extend the compass away from everything else, on a post, just to see if that helps.

Looking at the photo I see a black wire coming up from underneath (battery?) and going right next to what I think is your compass board. If that wire carries much current, that will generate a magnetic field which may affect the compass. Try re-routing that wire.

PS. Really neat to be able to print out your own plastic chassis!
 
Last edited:
Looking at the photo I see a black wire coming up from underneath (battery?) and going right next to what I think is your compass board. If that wire carries much current, that will generate a magnetic field which may affect the compass. Try re-routing that wire.
Oh good catch! it's only the 2xaa bat wire but still might be enough to be messing with things, would also explain why it's intermittent.
PS. Really neat to be able to print out your own plastic chassis!
oh hell yes. I'm pretty pleased with that little project too. note that it's only the red front bit in these pictures that I've printed on this, redesigning that now to hold the compass a bit further away and to hold the breadboard firmly.
I've also been using it to print molds for oogoo cases for electronics etc.
 
stuck the compass away from the rest of the electronics, didn't seem to make much difference, threw a delay in the loop and suddenly started to get better readings. was previously attempting to read the compass as fast as the loop allowed, about 3ms.
also found that I needed to stick an abs() in my agro thus:
short aggro = abs((diff * 100) / 180);
since I was often getting a negative aggro number, which was causing the bot to turn in the wrong direction if diff was also neg.
 
still sometimes having problems with the compass reading the same heading no matter which way it's facing. wonder if it's a problem with the compass initialisation. when this happens it's not an exactly the same reading, there's a little bit of jitter, but spinning the compass around does not seem to make any difference. it's an intermittent problem which makes it hard to troubleshoot though, since I do something, think the problem has gone away, then it comes back again.
I've ordered some of those little radios which I intend to stick on this, which should allow me to send readings to my laptop/pc without a usb cable which may make it easier to troubleshoot.

On a related note, I did post/report that issue with the 32bit unsigned/signed int with the compass and gyro libraries on github. not had any response to it yet though. ah well at least it's there if anyone else comes across the problem, which is likely now that the arduino Due is out.
 
OOOhh I've just noticed something:

if I upload the code to the T3 and read the serial, it all works fine.
after this upload and first run, I get this stuck heading problem.
any ideas?

edit:
using reset it will work, but just plugging it into the USB (or bat power) it wont.

Edit2:
on a hunch I stuck a 1 second delay in at the beginning of the void setup() which seems to have fixed the problem. is it trying to initialise the IMU before the IMU has fully powered on?
 
Last edited:
this sort of worked, till I realized that although I'd put an oogoo spacer between the t3 and the pins to give the usb socket a bit more room between the breadboard and the t3, I still didn't quite have room for the usb plug to fit...
might cut out a small chunk of the breadboard to fix that little problem.

I had a similar issue many, many years ago. The way we "fixed" it was to plug headers or a socket into the breadboard and then plug the device into them. We actually had to stack a couple sets of headers in our case. For the T3 you might get enough with a single set.
 
Status
Not open for further replies.
Back
Top