I printed out the bluprints and cut the pieces today for the body. I found the very big or very small plexiglass cuts are the hardest but overall its pretty easy. I printed out one of the bluprints wrong and made the sides about 15mm too small which sucks but oh well. I hope I’ll be able to fix it up somehow later because as it is now the frontmost wheel is back too far which will give too much slack in the track.
Welding the plexiglass pieces was pretty easy too. It bonds quick so they dont move and then it gets really hard after a few minutes. The first shape I made was a L shape and after about 15 minutes it was almost like one solid piece. The solvent should not be used to fill in gaps but as long as most of the edge is straight enough 80% of the piece bonding is still really strong.
As far as the placement of the idler wheels and such I’m not able to really test them because I’m still waiting for the motor box.
The circuit board fits inside well, should be plenty of room.
While I’m waiting for the motor and gearbox to show up I’m going to remake some of the modules. Hopefully when the motors show up I can make something that I can drive around.
I hope to make a blog entry on how I made the 3d model and upload all that, I spent a long time designing all this in cad software before cutting anything. I have the whole track and wheel set you see in the picture in cad (solidworks) if anyone needs it. I recreated all the pieces to scale.
Just noting some things that are wrong with the board so far. I’m happy to find these now instead of when i have twenty of these boards in my hands.
Basic notes, just stuff i found through further study that i dont want to forget.
Pin 7 on the wireless module is “reserved” and in the datasheet it says you can leave it disconnected or “can be pulled up by a resistor to vcc”. I dont know why they have it connected to a mcu pin on their diagram in the datasheet
The pic transmits it signal on the 4th pin on the wireless connector on the jinx mcu board, so it transmits on the tx pin. This is common sense but it can sometimes get confusing what is transmitting and what is receiving.
Power Circuit 2
I revised the power circuit to use all N mosfets. I thought I could just not allow the battery or charger to the ground so it would not make the loop needed for current to flow. Unfortunatley I had the indicator lights hooked into the same transistor as the batt / charger, this caused the loop too be made anyway. Then I decided to not allow the 7805 to go to ground using a transistor, this partially worked. The problem with it was even if the 7805 is not connected to ground it still lets a little current flow, barley enough to light a led dimly. So its a better solution but not a perfect one. I guess I’ll have to rework it again.
In the latest power circuit I had the switch switching the gate of the mosfet to ground not to the high of the battery as it should be. Its fixed in the multisim document but not on the ultiboard circuit.
In the rs232 circuit the tx / rx were backwards compared to the ones on the jinx mainboard, also the lights seem to be on all the time and just blink when sending. This is only for plugging directly into the mainboard but it is convenient to have them this way.
For the rcr and rct we need filter caps and an antenna the antenna can be just a straight wire of 170mm length. Also the transmission should be inverted so the transmitter is normally off, it also has to be converted on the receiving end. This is just for rcr/rct which we wont be using in the final design.
The power supply for the transmitter is at 5v which is fine for the rcr/rct but will burn up the expensive transducers that we will be using in the final design. We can get some voltage drop by using diodes. We could use a jumper to switch between the 5v or 4v.
Put diodes and other things on the basic hbridge circuit, look at the latest circuit there was no ultiboard circuit. Its written in the lab notebook though.
Solder the jumpers/headers upright straight to the board dont drill holes or bend the pins at 90 degrees it just makes it more fragile.
If the copper pad is too small around where a pin is to be soldered to the board it will eventually come loose and make a bad connection ! Make the pads big.
On the wireless module connector pin5 is enable if we want to turn off the wireless module with the pic we should control that with the pic, right now its just connected to ground. Also pin 6 is rts it will let us know when the buffer is full and allow us to drop the cts line so it can send the info, as is its just connected to a “busy” light. As far as i can tell no pull up/down is needed on the output from the pic to the wireless. Since we might only set the channel every once in a blue moon we might want to make pin8 (fqset) a manual switch. The website says you cant change the channel anyway but we might be able to, anyway it does not warrant a mcu pin.
Transmit and recieve on the mcu board should be switched since pin3 rx and pin4 tx are swapped with pin3 rx and pin4 tx on the wireless module. The mcu tx pin should go to rx (pin3) on the wireless module and the mcu rx should go to tx(pin4) on the wireless module. We will switch it in software for now … DONT FORGET!
When the motors turn on it draws too much power and the mcu wigs out, the solution is to put a large cap between vdd and ground to reduce the dip. Be sure to include a 100uF cap just after the 7805 on the power circuit. This worked well and eliminated that problem.
The voltage divider part is connected to the +5v from the 7805 and should be connected to the batHV+ instead. I fixed it manually on board but we need to fix it before the boards are made again.
BattHV might be a little to HV for the tiny tamaya motors we are using, maybe some diodes to get a vdrop and reduce junk coming back into the circuit ? We have 8v we want about 3-6v i would think. We want the reduction on the Hbridge module not the power module, this way we still are able to see the exact battery power and maybe use it for other things?
The first thing I did was hook this up to the connector on the jinx mcu board … this provides 5+V to the module. I saw a little bit of smoke and it bubbled up a little. I thought I had ruined it but it turns out it still functions, not sure if perfectly but it does tx/rx.
First lesson, it needs MAX 4.2v so you cannot use your 5v source !! It can run off of +2.4V to +4.2V and it needs 100mA. So If you were to use a voltage divider it might work. I used a lm317 to get a voltage source of about 3v. But if you wanted to do a voltage divider you could use a 47 ohm resistor as r1 in a voltage divider that would give you 5/47=106mA. In the basic voltage divider formula Vin*(rk/(rk+r1))=vout solving for 3v gives us 70 ohm as rk. That should give us 100mA and 3 v but you still have to make sure you wont burn up your resistors and in turn burn up the whole module.
I programed the pic to transmit at 19200 baud then I looked at the output from the other wireless module through the scope. Looks like the signal went through just fine.
The only weird thing is on either module connecting the scope to the rx or tx both give the output from the pic. So if i was transmitting on the tx pin on one module then on that same module i connected the scope to the rx pin (pin3) i would see the same signal I’m sending out. Also on the module thats receiving the signal through the air is outputting it on the tx and rx pins.
It says nothing in the datasheet about full duplex or anything so looks like we will have to experiment to figure it all out. This puts thoughts into my head about ack signals and such, I need to start thinking about how the two devices are going to communicate.
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
With all the headaches involved with the circuit the main reason it needed to be started before I work on the body is so that I can see how big the circuit board will be before i make the body. So basically what kind of rectangle am I going to need to accomodate in the middle for the circuit board.
Now I know the circuit board will be max about 72×63mm, or at least thats what it was on the board where I had everything on it. But we should give ourselves some space around that just to be sure. 73mm is 2.87 inches so we will call it 3inches. And 63mm is 2.4 inches so we will call that 2.75. So, we have a rectangular board that is 3×2.75 inches, thats not bad at all.
There is another element to the board size, since we have the modules that plug in at a 90 degree angle from the actual board our space must be pretty high to accomodate them. This works out ok if you think of a Johnny 5 type robot with a rectangular base. So our space where the board sits must also be at least 1.5 inches tall to accomodate the modules.
So to sum it all up
Circuits
MCU board (2.8in by 2.4in)
Modules max height from bottom of header to top of board 1.5 in
Body
at least a 3in x 2.75in x 2in to accommodate the circuit.

Categories
Tag Cloud
Blog RSS
Comments RSS

Void « Default
Life
Earth
Wind
Water
Fire
Light 