In the power module (that i deleted by accident, get from us puter!) the “charge” connection is connected to the positive battery terminal via a P channel mosfet. When I fully charged the battery pack (2 at a time) using my sony battery charger the overall voltage of the pack was 8.08v, so thats 8.08v/ 6 = ~1.35v per cell. I gauge that the charger is putting out about 1.435v per cell to charge them.
So the plan is this, turn on charger for about a sec, turn off charger, check battery voltage. If the battery voltage is less than it was in the previous check stop, or if its like 8v or something. This is using the negative delta V property of nimh batteries. I’m worried that since we are doing them all in series they may kinda compensate for the negative delta V but, the only way to know for sure is to just do it and record the output.
I’m watching it now and the code looks something like this
void chargeBattery(){ set_adc_channel(13); // vdivider hooked to battery (39/(47+39))*vin // reset vars, if not it will hold the last value battVolts = 0; chgVolts = 0; // turn off charge input and read battery output_high(CHGPIN); delay_ms( 1000 ); battVolts = read_adc(); printf("battVolts = %2x\n\r", battVolts); // turn on charge input and read charge voltage output_low(CHGPIN); delay_ms( 1000 ); chgVolts = read_adc(); printf("chgVolts = %2x\n\r", chgVolts); }
I’m doing it this way to read the output and see what happens. On the input line that the pic is reading i have a voltage divider of (39k/(39k+47k))=.453, and we are using 8 bit ADC so the max value (vref = 5v) is 255 and zero is zero
So to see the real voltage the calculation would look something like this
[(value/255)*5] / .453 and yes a quick check with the Multimeter and some calculations show this calculation and the pics ADC to be spot on to two decimal points. I’m changing the code to reflect the actual voltage so its easier to read, later we will just read the value and pass it as a byte in the packet.
Summary
8.08v is (8.08*.453/5*255)= 186 or 0xBA in hex
After some testing it seems as if they charged, the pack was at 8.09v and a random cell was at 1.35v. I made some code to detect the negative v condition if no negative V just turn off in a hour, we will see how that works out. If it is charging there is no way its charging faster than 1A per hour because of the limitations of the lm317 and because the batteries arent getting hot at all !
This is my code for now I’ll see how it works. I need to test the amps coming through and see if the batteries actually hold the charge for a while. I know the seconds wont be “exact” but close enough.
// for battery charging and maintenece #define CHGPIN PIN_A4 // global variables for this .h int8 battVolts = 0; int8 chgVolts = 0; int16 ChgSec = 0; void chargeBattery(){ set_adc_channel(13); // vdivider hooked to battery (39/(47+39))*vin // reset vars, if not it will hold the last value battVolts = 0; chgVolts = 0; // turn off charge input and read battery output_high(CHGPIN); delay_ms( 900 ); // if negative delta v or one hour stop charging and go to idle state if(battVolts < read_adc() || ChgSec > 3600){ printf("Battery Charged!, NDV detected in %u Seconds", ChgSec); state = '0'; // return to idle state }else{ // continue charging battVolts = read_adc(); // latest battery voltage // turn on charge input and read charge voltage output_low(CHGPIN); delay_ms(50); chgVolts = read_adc(); printf("\f -Charging Chg: %u Batt: %u time:%u ",chgVolts,battVolts,ChgSec); } }
Hooking up a 10k resistor through the high output line from the charger to the power module i get 10.88v on the charger side and 10.77 on the jinx side, that means .11v voltage drop. So v=i*r , .11=i*10k then i must be .011uA ?
Update . .
Looks like the logic is sound and the program is working great, but i’m sure the circuit is wrong. I have the drain side of the mosfet on the positive terminal of the battery to be charged and the source side on the charger. I dont know if the mosfet is hooked up backwards (to do what i want it to do) or some other underlying problem but i calculate the current flowing into the battery when charging to be like 20mA and the power consumption of the mcu and transmitter is more like 50mA, either way something is wrong. I need to go back and evaluate the mosfet and how it is working then repair the power circuit.
Also I got a old version of the power circuit 2 i should check to see that everything is right on it.
… just reading on other sites ..
If you charge several cells in series, you need 1.5 V times the number of cells plus 3 V. For four cells, this means a supply voltage of 9 V.
- so thats 6*1.5+3 = 12v, no need for the lm317 because i have 12v, we can use the lm317 to limit the current though
The well-known LM317 three-lead regulator is designed to adjust its internal resistance between the IN and OUT leads to maintain a constant voltage of 1.25 V between the OUT and ADJ leads. If we chose a value of (1.25 ÷ 0.180) = 6.94 Ω for R1, then exactly 180 mA will flow.
- for us if we have 1.25/.5 = 2.5Ω, that will allow about 500mA to flow through the battery to ground using the following schematic.

There is some scewyness with the compiler and enhanced pwm, so just to get all the p1a,b,c,d to work i had to use the code in this ccs post.
From there I wanted to know how the values are set to actually make the frequency you want. First you have to realize that the pwm is really just a result of a interrupt on overflow for timer2. So, whatever you set timer2 to be will be your fq of your pwm. To set up timer2 you use the command
setup_timer_2 (mode, period, postscale)
The mode is simply a divisor of your main clock frequency it can be 1,4 or 16. You should also note that since this is timer2 it also automatically divides your main clock by 4, each timer has its own “dividend” of the main clock, in timer2’s case it is 4. The postscale is the amount of times you will allow timer2 to overflow before you interrupt, so if you had everything setup for 500Hz and you wanted to actually use 1kHz you could just change postscale to 2 and it would interrupt every 2 times it overflows.
The hard one to figure out is the period, we all know what the period is but how do we set it in ccs? Well the max value is 255 and the min is 0 being that it is a 8 bit value (i think). So, 255 represents the max period which would be Tosc/(4*mode), you can figure out what that is. Just playing around half of 255 would represent half of Tosc/(4*mode). Anyway forget loosing yourself in all this there is a nice page here that oultines the whole thing and gives a nice formula
How to calculate the required values of the TIMER2: 
that (PR2-TMR2) is really the value you put for “period” in the function for ccs. A quick example at 4MHz main clock on the 887 to get 1kHz we would use
setup_timer_2(T2_DIV_BY_16, 124, 1); // Set 1000 Hz PWM freq
so with that example we have a 1kHz frequency and this is where our timer2 would interrupt and our pwm would turn on/off to drive our motors. But, thats just part of the equation how about the duty cycle ? Turns out thats pretty easy to do (hard to find info on) you just take your period (for timer2 interrupts) and multipy it by the % you want of the duty cycle. So, if we have 1kHz and we want 25% thats (1/1000)*.25 which gives you 250uS then you times that by (1/Tosc) * “mode divisor” in our case 250uS*(1/4M)*16 which gives me 125. I’m not sure if their value is wrong or my calculations but this is what they (ccs) give in the help file
value*(1/clock)*t2div
But you can just forget all that, since you’ve already calculated the value for “period” in setup_timer_2 you can just multiply that value by the desired % … for example 25% of our period 124 is 31 so we can set the duty at 25% with the instruction
set_pwm1_duty(31); // Set PWM for 25% duty cycle
With this code I got the pwm working great, it would wait a few seconds then increase in increments to 90% afterwards it would go to 0% duty then start over again. Here is my code
code here . . .
after hooking it up to the hbridge circuit I made a short video of it switching speeds, at the end of the video there is a unhappy ending when the hbridges burn again. I really need to go back and redesign the Hbridge circuit to make sure shootthrough is never a possibility. The lines float or something happens and it burns up the hbrigdges quickly. I almost want to make my own hbridge so i would have a better idea whats going on but I dont have any mosfets that will handle the motors.
So enhanced mode pwm, and switching lines on/off pwm worked great ! Hbridge still burns up
The two sided big jinx mainboard was kinda a disaster. With traces just .3mm thick and clearances of .1mm I think I was pushing it a little. I made the board but there were lots of problems, the outer traces got eaten by the echant was the main problem.
I had been thinking about doing a more modular design, but I had already started the other board and expected it to work. Anyway a modular design was kinda a fallback plan B sort of thing. It is actually better than the one board approach.
The modules are
The advantages of this modular design are
I made each board have a male header that goes out from the bottom, on the main mcu board there are female headers to plug these boards into. Most of the boards have 6 or less pins connecting to the mcu board. If the boards connect to anything else (motors, batteries, etc) they have male headers on the top of them. This should allow us to make the modules stack on top of the mcu board and make the overall board smaller. By doing this we reduced the connections on he mcu board from 130+ to 70 ish.
I created all of the boards quickly in multisim then made the pcbs for all except the MCU and Multiplexer board. They are all etching as I write this.
Multisim
While creating the mainboard in mutisim I discovered a lot of errors in the thinking. For one I was using N channel mosfets and not allowing things to go to ground where I should have been using P channel. One example of this was the voltage input jack for charging, had I simply not allowed it to go to ground it would have still went through the batteries to ground. So I replaced the two N’s with P’s, this actually helped clear up some stuff. One thing it cleared up was the on push button, this button would have needed ~1v to turn on had it been a N channel so this would have required some voltage divider and a constant drain on the batteries to provide this 1v, but with the P channel all we need is the tactile switch to go to ground. Also another thing that was wrong was we had the mosfet that keeps the circuit on before the place where the battery taps in, this would mean the motors would flow through this mosfet which isnt rated high enough this would burn it up. All these modifications will have to be updated in the architectural design and the pinouts and such. Another thing i had to move the mosfet that turned off the circuit to before the 7805, i dont want the 7805 running constantly.
I also had some trouble with footprints. I had to make a footprint for the pots i ordered from ebay, also some things didnt really have the pins mapped right. Like the Voltage Regulator, pin1 vin, pin2 gnd, pin3 vout and that is how it was shown on the symbol but then when you sent it to ultiboard the footprint had things going to the wrong pins. I had to go through and make sure all those things were ok. I pretty much just spot checked a few things to make sure the pins were going where they should.
I tried to make the multisim design as “pretty” as possible but that proved impossible. I added all the male headers and other circuits into sub circuits but even that was not enough. The circuit has so many connections you cant really tell what goes where, well i take that back you can but it takes a lot more than just glancing at it to see where the wires go. I’m not sure what can be done about this except being very careful. I tried to move one of the components after wiring it all up and it made all kinds of messed up connections all over the place causing me to start again from scratch. I tried to make some of the connections more clear by making them at a angle, when two things overlapped I set one at a angle.
Ultiboard
Things didnt get much funner when I moved everything over to Ultiboard. I spent a long time trying to figure out how to get the “autoroute” and “autoplace” to my liking. If you autoplace the components it kind of just throws them around without any order, this might be great for connections but it makes a really nasty confusing board. I wanted the connectors to be on the outer ridge and the components to be more on the inside, also the led’s and buttons should be in a easy to find place. To acomplish this I put everything where I wanted it and then locked it in place. Since I’m going to be having a double sided board I allowed smd mirroring, then I allowed ultiboard to autoplace the components. There are a lot of things that are needed to know to get this done without taking all day, it just comes from experience working with the software and reading the help files (and user guide on your c drive).
After that I wanted to route things on both sides but it always seemed to autoroute more on one side. I found that you can fix this by selecting the nets in the spreadsheet (on the bottom if enabled) then where it says something about what side to route on you click that and then click top and bottom, make sure its not grayed and checked make sure its clearly checked (by checking it a few times). This causes the mode of routing for the nets to be 111 for a double sided board and then it will create a ton of vias and route a lot on both sides of the board. I had to reduce my trace width to about .3mm which is pretty small, also I had to reduce the clearance in the traces to about .1mm i think. The traces get spaced out well by changing the density factors in the autorouting settings. I recommend reading the ultiboard documentation (or help file) thats here \pathtoNI\documents\ultiboard usermanual.pdf . You really have to read that to know what all the “cost factor” things are when setting the settings for the autorouting and autoplacement.
Auto routing got me almost all of the 130+ connections, then I added a few jumpers and added a little fluff around the places I know I’ll have to work magic later. I paid special attention to the accelerometer area because I wont be able to solder jumpers to this area later. At the least if you see parts of the ratsnest where you will need to solder jumpers later make sure there is a nice copper trace there to solder too. I think I’ll have to add about 10 jumpers but they are all in places where I can get to. At least the board has some order to it and it will be easy to work with when/if everything works.
There are lots of errors I’m ignoring especially around the lga-14 footprint since its pads are closer than the clearance for the boards. I’m hoping to make the traces a lot fatter with a marker after transferring to the board, we will see how it goes.
Oh just a quick note. I was looking for a way to print out all the connections to test them by hand however I could not find it anywhere in multisim. But, if you export the circuit from multisim to orcad pcb (transfer -> export to pcb layout) then save as a orcad .asc file it creates a file that you can open in wordpad. In that file you can easily see what is connected where, its very useful for checking everything.
This has been abandoned.
This board was very hard (impossible?) to make. I thought of a better way of doing this using several small boards instead of one big one. You can read about the modular board here.
Well you know from my other post that I had some of the ‘7331 accelerometers, I also have some of the 7455 accelerometers. I’ve already spent my two 7331’s so unless I order more I only have the 7455’s. While browsing mouser I notice the 7331 is at EOL (end of life), so I took another look at the 7455.
The main difference between the two is the 7331 uses analog signals and the 7455 uses I2C protocol to relay the data. I’m really against “package” things, I dont want to just make things work together, I want to make the things. Originally I thought the 7455 was something like a packaged cots solution; however, it really isnt. Basically the 7455 does the digital to analogue conversion so your MCU does not have to, it also has other benifits which I’ll try and sum up here. Another thing I’ve never messed with I2C and I love learning new things.
Summary comparison
7331
End of Life
Pins that go to MCU: 3
Total Pins it uses (from 14): 8
G-selects: 2
7455
New Product
I2C/SPI output
Programmable Interrupts
Pins that connect to MCU: 3 or 4 (or more, I’ll be using 4 I think)
Total Pins it uses: 10 to 11
G-selects: 3
In this case the “package” with the more bells and whistles actually lets you do a lot more. They are both about the same price btw.
Here is the basic connections to the MCU

I pretty much know nothing about I2C, looks kinda like token ring to me so I need to go read up on it. But, if we use this one and get the I2C working we can easily add more devices via the I2C (from what i gather). For this one device looks like we will need at least 3 pins but for the full features we will need 4. I want to get all the interrupts I can out of this thing. This way we can have interrupts instead of polling the device (as we would have had done in analogue). So, basically if there is a collision, free fall or acceleration it triggers a interrupt. To make sure we are going somewhere we can start the motors then check that there is acceleration, if we fall off something i guess we can cut off power to the circuit to minimize damage and if there is a collision we can stop and see where the collision was. But thats all for later what I need to focus on now is how to hook it up to the MCU, I’m going to have to go back and change the connections in the architectural document and I’m going to add a male header connection in case we want to add more I2C devices later.
I had to create custom components in mulstim for almost everything I’m using in the project. I even had to make a footprint for the accelerometer LGA-14 which was pretty hard. There was no 7805 in the right footprint so I had to remake it, also the 555 timer didnt have a footprint.
Pretty much all of these components are just like dummy components that have the right footprint and pins. You cant simulate them and they dont list the pin functions.
The LGA-14 is for the ti accelerometer it might come in handy to others.
In order to get a better understanding of the circuit I need to create for JINX I’ve summed up everything in a diagram. I use DIA free diagram software. I also took the opportunity to put information about the inputs and outputs so we know we are not cramming round pegs in square holes.
The circuit is turned on by pushing one button that turns on a transistor, after that the mcu starts up and keeps that transistor high. This allows the circuit to turn itself off if needed.
I’m using almost all the pins on the 887. I did not try and spare pins but i did try and spare more useful pins, most (both?) of the free pins have a good hardware function that may come in handy later.
I mentioned above I used dia, I love dia and its free at http://projects.gnome.org/dia/ it is a linux program but there are windows binaries. I will include the actual dia diagram also.
This is some code for my old protoboard version .1 i think. Im just posting it here for reference it has some good things like.
Real time clock
RX serial recieve interupt
Menu system via rx
password recogitition
pretty much all it did was keep time and beep, it was all the fluff that was hard. The whole project is attached as a HomeControl.zip
here is the main .c file
////////////////////////////////////////////////////// // Home Control Version 1.0 // A program to control my home via a pic 877 // or at least do the things im to lazy to do ;)~ // // By Mikel, http://www.zonemikel.com ///////////////////////////////////////////////////// #include <16F877.h> #device adc=8 #use delay(clock=4000000) #fuses NOWDT,HS,NOPUT,NOLVP #use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8) #include <string.h> // string stuff #include <stdlib.h> // for strtol etc #include <INPUT.C> // for get_string() // Defines #define XTal_FQ 4000000 #define T1_FQ (XTal_FQ/4) // 1 clock tick = 1 instr. // cycle = xtal freq / 4 // Global Variables int32 Ticker; // current Date/time will be here int8 Years=0, Months=0, Days=0, Hours=0, Minutes=0, Seconds=0; // is user connected ? int8 UserConnected=0; // how many minutes left to re login for users with wrong pw int8 WrongPassword=0; // hmt users put wrong password // global "status" vairble 0=nothing 1=user connected 2=feeding fish int8 Status=0; ///////////////////////////////////////// // Initilize RTC ///////////////////////////////////////// void Init_RTC(void) // start up the real time clock { Ticker = T1_FQ; // clock counter = #clocks per second setup_timer_1( T1_INTERNAL | T1_DIV_BY_1 ); // int 16 bit timer to interupt // Every 65536 clock cycles enable_interrupts( INT_TIMER1 ); // Start RTC } //////////////////////////////////////// // Process RTC Info //////////////////////////////////////// #int_TIMER1 void TIMER1_isr() { Ticker -= 65536; // Decrament by clocks per interrupt if ( Ticker < 65536 ) // If second has expired { Ticker += T1_FQ; // Incrament ticker by clocks/sec Seconds++; // Incrament Seconds } // turn seconds into everything else if(Seconds == 60) { Minutes++; Seconds=0; if(Minutes == 60) { Hours++; Minutes=0; if(Hours == 24){ Days++; Hours=0; if(Days == 30){ Months++; Days=0; if(Months == 13){ Years++; Months=0; } // years } // months } // days } // hours } // minutes } //////////////////////////////////////// // Beep makes a beep then waits 300 ms //////////////////////////////////////// void Beep() // sends a beep to the piezo on C0 { int k = 0; for(k=0; k<255; k++) // 255 times not very long but a beep { output_high(PIN_C0); delay_us(100); // produces a tone output_low(PIN_C0); delay_us(100); } delay_ms(300); // need to wait a little b4 doing again } //////////////////////////////////////// // Set the time, i hate dialoges //////////////////////////////////////// int SetupTime() { char String[5]; // for user input printf("\n\rPlease Give Me the time"); printf("\n\r Years:"); get_string(String,10); Years = atoi(String); // save year write_eeprom(00, Years); //years stored to eeprom 0 delay_ms(20); // allow time to stick printf("\n\r Months:"); get_string(String,10); Months = atoi(String); write_eeprom(01, Months); //stored to eeprom 01 delay_ms(20); printf("\n\r Days:"); get_string(String,10); Days = atoi(String); write_eeprom(02, Days); //stored to eeprom 02 delay_ms(20); printf("\n\r Hours:"); get_string(String,10); Hours = atoi(String); write_eeprom(03, Hours); //stored to eeprom 03 delay_ms(20); printf("\n\r Minutes:"); get_string(String,10); Minutes = atoi(String); write_eeprom(04, Minutes); //stored to eeprom 04 delay_ms(20); printf("\n\r Seconds:"); get_string(String,10); Seconds = atoi(String); write_eeprom(05, Seconds); //stored to eeprom 04 delay_ms(20); printf("\n\r New Date: %d/%d/%d %d:%d",Months,Days,Years,Hours,Minutes); } //////////////////////////////////////// // Interupt on serial RX //////////////////////////////////////// #int_rda void serial_isr() { disable_interrupts(int_rda); // stop this int UserConnected = 1; // make a user } //////////////////////////////////////// // Prints Menu on rs232 connect //////////////////////////////////////// int PrintMenu(int GetPw) { char Password[15]; // password char Input[15]; // Users Input // if this should get the password if(GetPw) { printf("\n\r Please Enter Password:"); get_string(Input, 15); // get password strcpy(Password, "Password"); // copy the password if(strcmp(Password, Input) == 0) { printf("\n\r Password Accepted");// it was right }else{ WrongPassword++; // track the wrong password printf("\n\r Wrong Password"); // wrong password return(0); } } // end if getpw printf("\n\r ----------------------------------------------------"); printf("\n\r | %d/%d/%d %d:%d\t",Months,Days,Years,Hours,Minutes,Seconds); printf("\n\r | Status: %d",Status); printf("\n\r | valid choices: s,t,m,x,b,f"); // show choices printf("\n\r | s=Set time \t t=View time"); printf("\n\r | m=Menu \t b=beep"); printf("\n\r | f=Feedfish \t x=Dissconnect"); printf("\n\r | r=Show Status"); printf("\n\r ----------------------------------------------------"); return(1); } //////////////////////////////////////// // The Glorious Main //////////////////////////////////////// void main() { //variables char String[10]; // for user input char Input[10]; // int C1On; // to see if C1 is on int C2On; // same for c2 // startup the pic has been restarted all old data is lost printf("\n\rStartup, old settings may be lost"); //SetupTime(); // get time from user // do the rtc stuff Init_RTC(); // startup the rtc // interrupts enable_interrupts( GLOBAL ); // use the ints enable_interrupts(int_rda); // int on serial RX setup_adc_ports(NO_ANALOGS); setup_adc(ADC_OFF); setup_psp(PSP_DISABLED); setup_spi(FALSE); setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1); setup_timer_2(T2_DISABLED,0,1); Beep(); // startup beep printf("\n\rStart"); // print start // from here on its for ev er while(1) { /* if((Prev_Minutes != Minutes) && MinutesLeft !=0) { MinutesLeft--; // decrament timer printf("\r Minutes Left:", MinutesLeft); if(MinutesLeft == 1) { MinutesLeft = 0; // reset timer enable_interrupts(int_rda); // enable interupt } } */ if(UserConnected) { delay_ms(500); // let them open their eyes Beep(); // print the menu if they type right password continue if(PrintMenu(1)==0) { printf("\n\r-Goodbye you have been disconnected");// let them know they diss UserConnected = 0; // set user to 0 enable_interrupts(int_rda); // resetup interrupt } // while the validated user is connected take their commands while(UserConnected) { delay_ms(200); // so they dont flood me printf("\n\rYour Choice:"); // prompt for item get_string(String,10); if(String[0] == 's'){SetupTime();} // setup time (set clock) if(String[0] == 't'){ printf("\n\r Time: %d/%d/%d %d:%d.%d",Months,Days,Years,Hours,Minutes,Seconds); } if(String[0] == 'm'){PrintMenu(0);} // reprint initial menu if(string[0] == 'x'){ // disconnect UserConnected = 0; // set user to 0 enable_interrupts(int_rda); // resetup interrupt printf("\n\r-Goodbye you have been disconnected");// let them know they diss } if(string[0] == 'b'){ Beep(); } if(string[0] == 'r'){ printf("\n\r Status: %d WrongPasswords: %d", Status, WrongPassword); } // turning on c1 and c2 like a toggle if((string[0] == 'c') && (String[1] == '1')) { if(C1On == 1) // if c1 is high { printf("\n\r Pin C1 Low"); output_low(PIN_C1); C1On = 0; }else{ output_high(PIN_C1); printf("\n\r Pin C1 High"); C1On = 1; } } if((string[0] == 'c') && (String[1] == '2')) { if(C2On == 1) // if c2 is high { printf("\n\r Pin C2 Low"); output_low(PIN_C2); C2On = 0; }else{ output_high(PIN_C2); printf("\n\r Pin C2 High"); C2On = 1; } } } // end if userconnected } // end while one /* delay_ms(1000); printf(". Ready:"); // test reciving of rs232 from computer gets(string); printf(". Your string was: %s", string);// print string back to user // figure out what they wanted to do if(string[0] == 'f') { Beep(); printf(". Feeding Fish"); FeedFish(); } */ } }
Problems with transistors
I have been working on this line following bot using only two transistors. It barley worked with 2n3906 and 2n3904’s driving the motors, which is to be expected since the are “small signal transistors” not for driving motors. On top of that the sensors would not even allow the pnp transitors to really reach ground so there was not enough current to really get the motors going. I had to remedy all that by using some npn transistors to allow the pnp’s to get a good ground. In case you are confused,
sensor -(output goes to base of)> npn ‘04 -(collector goes to base of)> pnp ‘06 -(emitter goes to one side of)> motor
so basically the sensor drives a npn tranistor that drives a pnp transistor that drives the motor. It didnt work well at all, I knew it would not but i was impatient waiting for other transistors to arrive. In the video it only shows the bjt transistors once, its the part where i kick it to keep it moving.
Eventually i got some mosfets, really little buggers you cant really see them in the video. Hooking up one didnt do the trick i had to solder 3 of them in parrallel to get enough umph to the motors. They work 10 times better than the bjt’s and simplify the circuit greatly. With the mosfets I just have the sensors driving the mosfets that drive the motors, so the entire circuit consist of 2 transistors, 2 sensors, 2 motors and some resistors. Really the transistors are 3 in parrallel but they act as one, they are so small they fit on the end of the 3 pin male headers in the video. I need to get some different fets that allow me to use just one, or we may go to a h-bridge ic. This was just for testing/prototyping.
Problems with following the line
As you can see it overshoots the line a lot. The fact that once one motor shuts off the otherone gets a extra boost of power makes it “jerky” but should actually help it. The right motor turns a little slower than the left motor, this causes it to go right when its not really following anything, it will not just go in a straight line. Anyway once it overshoots the line it has nothing to go off of so it just goes, the paper was to stop it from running under the sofa. A third sensor would come in handy to see if there is a line or not, but in this case it wouldnt really help because it would just stop.

Categories
Tag Cloud
Blog RSS
Comments RSS

Void « Default
Life
Earth
Wind
Water
Fire
Light 