Hi John, well that's a little better now. There seems to be an error in the schematic as you have the capacitor in series with the battery supply but I know what you mean. Have you used one of the PWM objects in the OBEX? I don't know what you mean by a 1M resistor though because at 8V you will only have 8ua which isn't even enough to make an LED glow. Probably the 8V you are seeing is just your meter reacting to the pulsing and the inductance and back emf etc??? The motor controller will do what you ask so there is never a need to use a resistor, it's absolutely the wrong thing to do. PWM will pulse to the maximum voltage and back to zero so you are depending upon the duty cycle to provide the "average" voltage assuming you run this in the right frequency range to suit the load. Too low a frequency will result in vibration or too high will prove ineffective due to the motor's inductance etc. A really low frequency pulsing will do just that, run the motor hard for the on time, and cut the power for the off time, so you see the frequency is important too.
Baralaba's a bit far but still what we would call "in the country" rather than "outback"
BTW, just to answer your original problem - If your frequency is too low then the motor will draw a lot of current at the ON voltage which will be close to the battery voltage. It sounds like you were saying indirectly that the motor is a 3V motor so you will find that the battery will probably not be able to supply the current and so the battery voltage droops. Increasing the "PWM" frequency will alleviate this problem. You probably need to isolate the logic supply from the motor load by using a diode fed into a capacitor which will hold enough charge to supply the controller when the battery voltage droops (any diode plus a 470uf or more capacitor perhaps).
'Tis a bit far, and as you said, maybe not quite the "outback", but it is certainly small, it's population is about 200 people.. a far strech from Brisbane's [FONT=arial, sans-serif]2,043,186... On the QAS's "remoteness scale" it rates a 6 out of 7.
Sorry about that cap schematic flaw, it was meant to be paralleled across the battery terminals. And yes, the 1M resistor was another mistake... Need to refine it, will get back to you on that.
Thanks for your help anyhow, I will try to fix everything. Mind you... if I need any parts, the local Jaycar is 2 hours away...
Thanks anyway,
-John
P.S. Interesting fact, "Baralaba" is spelt like "Banana" in the way that every second letter is an "a". Funnily enough there is a town nearby (about 20 minutes) by the name of Banana... But it wasn't actually named after the fruit, it was named after a bull.
[/FONT]
No need to refine the resistor value as it is not needed or desired as explained.
Here's a quick schematic of that supply filter which may in conjunction with the proper PWM signals alleviate voltage droops from resetting the Prop. All it does is hold a charge on the capacitor but the diode prevents it from feeding back to the motor supply which comes direct from the battery. You may find that the 1,000uf cap you already have would be better off being used in this manner.
I just found a PWM obj that I like, it seems to be working. Having said that, since my previous motors suffered "abuse" from high voltages, I think they have given up on me, not to worry though, I have 2 spares. Assembling them now to put them on.
"Baralaba" is spelt like "Banana" in the way that every second letter is an "a". If you remove one L from Parallax then every second letter is an A too, just a play on words, or in this case, letters.
"At the moment, everything seems to be operating as per normal. Note, I forgot to add in the schematic that the battery is 7.4v @ 3.6 AH. I am wanting to add in a 1M resistor inline with the motor as the driver is pumping out 8V when it should be only 3V. I have tested with a multimeter and a variable resistor, and a 1M resistor is the closest match to what I need (that I currently have)."
You cannot pad down the h-bridge/controller output with resistance, that would limit the heck out of current.
If you cannot use a lower voltage for that then you have to use diodes.
It's inefficient as all get out, but if you're stuck on this 7V battery pack then that's how it is. Each diode results an approx 0.8V drop, 5 would be 4V, 7.4V - 4V = 3.4V (close enough, or add another diode each way).
If you've been zapping that 3V motor with 7V, the result will not be pretty, long term.
It is advantageous when PWM'ing motors to run them off a higher supply than what the supply is rated at. DC motors are pretty forgiving anyway and you also never want to introduce voltage drops intentionally. If the PWM frequency is high enough then the inductance of the winding prevents the current from going too high. The higher voltage allows higher PWM frequencies to be used. Think of a switch-mode regulator which might run from 24V and supplies 5V out and all it's basically doing is PWM'ing 24V through the inductor in conjunction with the schottky diode and filtered on the output with a capacitor. So you would never insert extra voltage dropping diodes in this circuit either.
It is advantageous when PWM'ing motors to run them off a higher supply than what the supply is rated at. DC motors are pretty forgiving anyway and you also never want to introduce voltage drops intentionally. If the PWM frequency is high enough then the inductance of the winding prevents the current from going too high. The higher voltage allows higher PWM frequencies to be used. Think of a switch-mode regulator which might run from 24V and supplies 5V out and all it's basically doing is PWM'ing 24V through the inductor in conjunction with the schottky diode and filtered on the output with a capacitor. So you would never insert extra voltage dropping diodes in this circuit either.
Thanks,
I was just able to vary the voltage of the motor drivers via the duty of the PWM any how, I find about a 50% duty gets me right about the right voltage for the motors.
I believe that the problem is solved now Thanks for all the help
If the problem's solved then what was the problem? You know you owe the group that much. I reckon that you were running your test PWM at too low a frequency and also too high a duty cycle 5:1 and so suffered voltage droop when the battery couldn't supply the current.
If the problem's solved then what was the problem? You know you owe the group that much. I reckon that you were running your test PWM at too low a frequency and also too high a duty cycle 5:1 and so suffered voltage droop when the battery couldn't supply the current.
I reckon that you would know more than me what fixed the problem... But anyway, I have said a number of times that the problem has been fixed... then it appeared again...
I have just dissasembled my robot due to the gear boxes needed replacing. Once I get the robot back together, with the new gearboxes, a new battery strap, and a PS/2 port, I will do some more extensive experiments.
I assume that it was the drop in voltage that caused the prop to reset, as its appears only logical answer to the problem.
Apart from the wiring that I had in place, I changed the code to a library that I found on the OBEX. I don't really know what the library was called.. but it does a great job with PWM
-John
P.S. I probbably wouldn't dismiss this problem that quickly as it has happened to me so many times that it isn't funny. I started about 1 month ago with dual serial motor drivers... I had problems with them... Then I moved to H-Bridge drivers.. then I had problems with them... I wish I knew more about this stuff so I could fix it more readily :} Well anyway, you learn from your mistakes, so although I'm havin' this problem now, I probbably won't have this problem again
It is advantageous when PWM'ing motors to run them off a higher supply than what the supply is rated at. DC motors are pretty forgiving anyway and you also never want to introduce voltage drops intentionally. If the PWM frequency is high enough then the inductance of the winding prevents the current from going too high. The higher voltage allows higher PWM frequencies to be used. Think of a switch-mode regulator which might run from 24V and supplies 5V out and all it's basically doing is PWM'ing 24V through the inductor in conjunction with the schottky diode and filtered on the output with a capacitor. So you would never insert extra voltage dropping diodes in this circuit either.
That's all relative to many factors, freq, pw, motor XL -- all of which which are, in this context, Unknown, as many other specifics.
DC motors aren't forgiving, quite the opposite, and more so the little crappy sort.
7V to a 3V motor is excessive, especially when somebody has no idea what he's doing.
The diodes are like training wheels.
I guess there'll be more "it's fixed"/"no, it's not fixed" stuff down the road.
Blindly doing this and that, incorporating unknowns from the obex, hoping something might happen, and wondering why nothing ever works just isn't making it.
Have fun, boys!
John's pulling his hair out so I guess he is having fun
Anyway I doubt very much that the voltage was as high as John measured it as he is relying on a cheap meter and trying to measure a pulsing motor without understanding what he is seeing. It's a bit like someone measuring 4V on the output of a 5V regulator and assuming the regulator is faulty when the input is measuring 8V. What they are missing is that the DC meter is reading the average of a lot of ripple due to a dried out electrolytic. Switch the meter to AC and it comes alive. The fact is that the board would cut out very quickly and the motor will not be destroyed that quickly will it?. You really need to overheat it which will only come about with too much current for too long.
I knew the resistor wouldn't work as I walking out my door. My own noob-ishness showing through. Just had a chance to jump on and promote the diode voltage dropper. This will save a huge amount of time, and cost of motors. Good luck and keep having fun! Even after you're bald.
John measured it as he is relying on a cheap meter
Good thing I was using my father's meter... or you'd be quite right. How can you assume that the meter I was using was wrong? At any rate, you are probbably right.
Heh, I reckon I'd better "lay low" for a while, seems like I've made a few "enemies".
Don't worry, there's always some friction, only way to totally avoid it is to avoid the forum, but that would be silly. It's not about "one-upmanship" or getting the last word in as this is a forum and we can bounce ideas off each other as well as assist where we can. If for instance somebody thinks my suggestions are "dumb" or whatever then it is always far better to state why and also why another solution is better. That way it encourages ideas and gets the brain working, rather than the emotions putting people off-side.
So try not to see any bad or anything personal in what someone else says or how they react, it'll all blow over. Just keep waving and smiling and all friendly like, you know what I mean.
Anyway I said cheap meter, not bad meter as either will give you the same reading to a point, but really it comes back to knowing what the limitations of your test gear are and how to use them properly in different situations. That's why I gave a short example of measuring a faulty power supply with a meter. The results would be the same if you used an expensive meter but understanding a bit more about the device under test and the device observing the test certainly helps a lot. In your case bear in mind that DC motors are inductive and also generate back-EMF in which case an oscilloscope would be more beneficial to see what is going on. If I step in to correct a misconception, I will go to some lengths to explain why as you have seen but we are all busy and only have so much time so posting is a luxury and rather low priority normally I'm afraid.
One last thing, someone mentioned putting a diode in to run both prop and motors off the 1 batt, how can I do that?
Thanks,
John
Did you scan back through the posts at all???? The schematic shows the connections so it's only a matter of having a diode in series with the battery supply that runs to your VIN of the Prop board and then adding a large enough capacitor to the the VIN side. You might even be better off taking the large 1,000uf cap you have now and putting it on the VIN side. Diode anode is connected to Vbatt, diode cathode to VIN.
That's okay, I just didn't know whether it's just that you don't understand it or that unbelievably but maybe you haven't read back through your own thread It's even possible to insert a resistor in series with the diode to help filter any nasties but the value depends upon the maximum load etc so don't worry about that for now. If you had a value of 22R or so you could try that though.
As funny as it may sound... I don't have a diode...
In any case, I just tried a 6V torch battery as the processor's power supply, and the RC car batt as the motor's supply... still the same issue. They are both sharing the same ground. The power LED is flickering on the board, so some how the motor driver is drawing power from the chip.. I have no idea how.
As funny as it may sound... I don't have a diode...
In any case, I just tried a 6V torch battery as the processor's power supply, and the RC car batt as the motor's supply... still the same issue. They are both sharing the same ground. The power LED is flickering on the board, so some how the motor driver is drawing power from the chip.. I have no idea how.
Well, I'll keep working on it.
I hope you mean that they are both sharing the same ground AT the battery negative and not at the negative terminal of the logic board. The fact that your power LED is flickering seems to indicate that your battery supply is drooping and the difference between this board and the others could very simply be a matter of PWM duty cycle. If the Prop board is leaving the motor pulsed on for too long it can cause a problem. You want to make sure that output is correct and since you have basic test instruments *your Dad's meter" then I suggest disconnecting the motor and put a small 6V torch bulb in there for the moment. Measure the voltage across your bulb to ensure that the duty cycle is correct then substitute the lamp for the motor.
I hope you mean that they are both sharing the same ground AT the battery negative and not at the negative terminal of the logic board.
Well... a bit of a long story. I burned out (Somehow) the screw terminal block of the GG prop board. I now connect the power to the prop from the VIN and the GND sockets of the board. As of yet this hasn't had any ill effects. So in a sense, I am connecting both GND's at the logic board, but at the same token, it is kinda at the batt terminals.
Also, with the prop demo board, I can't connect both GND's at the battery terminals because it is using the mains socket. In this case I am connecting the GND to the logic board's GND.
You want to make sure that output is correct and since you have basic test instruments *your Dad's meter" then I suggest disconnecting the motor and put a small 6V torch bulb in there for the moment.
I'll see what I can cook up - but hopefully not cook...
Okey dokey! Time for a news flash! I one of my motor controlers on a demo board and mounted that to my robot, then I used a serial line to communicate between the two chips. This worked fantasticly - except it couldn't update fast enough. The serial communication was a bit to slow for my purposes, and although it worked, it has to update lightningly fast which this arrangement couldn't achieve. So, I went on to parallel style of communication which I got semi working before I burned out my last motor controller... t'was a sad moment. But anyway, a fresh batch of promising parts are arriving from Parallax! I found the HB-25 motor controllers a perfect match for what I want to do on the robot... and much more, so I ordered some and they should come within the next week or two! So these drivers should get my robot up and running in no time! By the way, if there is anything you reckon I should know about the HB's, please tell me - I really don't want to do something wrong with these ones...
Although this has been a long road (about 2 months), I believe it is comming to an end, and then I can start the *cough* glorious *cough* task of doing everything else... Having said that, I wasn't ever much good at electronics and mechanics, I'm more the programmer type, I guess I've been programming much longer than wiring
Hi John, thanks for the update. We are always curious as to how it all turns out but rarely are we fortunate enough in that department to be enlightened. The feedback does help us though when we are dealing with future problems.
I'm surprised that your serial communications was not fast enough but then I looked through the thread and found your code which was using a baud rate of 9600. Now that's fine for a little console debugging maybe but why go so slow? That object is fine up to 115.2K baud and I have plenty of objects which run at megabits/sec although you would not use archaic RS232 drivers for these speeds.
Don't think you've taken the trophy for long roads though as we have all experienced longer roads then this I think Take each trial and setback as a lesson learned and an opportunity to gain experience.
Don't think you've taken the trophy for long roads though as we have all experienced longer roads then this I think Take each trial and setback as a lesson learned and an opportunity to gain experience.
Will do As I said before, I'm not much of a wire-ist but I can do some nice stuff with computers. I've been programming in 8+ languages for over half my life - and I've only been wiring for a few years...
Okey dokey, you mentioned a different serial driver for the RS323 serial comms, where could I aquire this? Note: I did speed up the baud later on up to 115200, still didn't appear fast enough, maybe I'm doing something wrong, but it just didn't update fast enough for my liking. Well anyway, I think the switch to the HB-25 drivers will be a change for the better, I can't imagine how I would have any trouble with them... after all, I'm running at about a 300ma, and they are rated at 25A... They also have a very easy interface to use. Well, anyway, I hope this turns out well. Here's a bit more information about the base:
It is getting built for RCJA State Championships at Brisbane in August, for those not familiar with RCJA it basically comprises of the robot having to follow a line, making decisions at T-Junctions and going around obstructions. The most commonly used base at such comps are the Lego Mindstorms - that's why I need to win, to show them that it is possible to custom build such robots Well anyway, I don't think I need to explain the motor driver system! I am using 2 ColorPAL's for the line and color sensing, 2 Ping's for the obstruction sensing, it has an arm for picking up objects consisting of a 30kg torque, titanium geared, servo motor. 1-2 props for the brains, and 1x 7.4v 3.6AH Li-Po battery for the power source, 2 tamiya gear boxes for the drive motors, 3 omni-directional castors for the back stability, 2 bumper switches for detecting arm movement, a 2GB SD card for large storage, 1 serial LCD display for giving feedback, and more!
I think if I can get the base assembled well, and the programming working great I can throttle those mindstorms kids at the comp There is no way that the Mindstorm's 40MHz brain could keep up with a the staggering 1.28 GHz of the 2 props
Well anyway, time to get back to whatever I'm supposed to be doing, and I'll keep y'all updated.
Hi John,
Can you post your code because I would like to see where this communications bottleneck is as it may not have anything to do with the speed. Just as a note for now fast serial drivers also require fast access from Spin code for full throughput and many of these OUT and IN routines are bogged down with handling the FIFO buffers. To streamline that it is easier to read/write a variable which will have the latest character and status. It would be good if Spin had a single fast read and clear operation.
This might not be the most up-to-date version of the code, but it would be pretty close.
Server code (Demo board with motor driver on it)
{
Name: Jaws Serial Motor Driver Firmware
Author: John Board
(c) 2012 John Board
}
CON
_CLKMODE = xtal1 + pll16x
_xinfreq = 5_000_000
RxPin = 31 'Currently set to computer comms, can be set to other pins
TxPin = 30
Baud = 9600 'Was also tried set at 115200
OBJ
PWM : "PWM_32_v4.spin"
Serial: "Serial"
PUB Start | Duty, alarmCount
waitcnt(clkfreq/2+cnt)
DIRA[0..6]~~ 'Motor driver stuff
OUTA[3]~~
DIRA[16..23]~~ 'Motor driver stuff
DIRA[RxPin]~
PWM.Start
DIRA[23]~~ 'Demo board status LED
repeat until ina[RxPin]==1 'Wait for other chip to connect...
OUTA[23]~~ 'Demo board status LED
Serial.start(RxPin,TxPin,0,Baud)
SerialLoop 'Enter Main Loop
PUB SerialLoop | params1, params2, params3
repeat
params1 := Serial.rxdec
if params1 == 1 'Forward
Serial.dec(1)
params2 := Serial.rxDec
ForwardLeft(params2)
elseif params1 == 2 'Backward
Serial.dec(4)
params2 := Serial.rxDec
BackwardLeft(params2)
elseif params1 == 3 'Reboot
reboot
elseif params1 == 4 'Halt all systems
Halt
Serial.tx(3)
if params1 == 5 'Forward
params2 := Serial.rxDec
ForwardRight(params2)
if params1 == 6 'Forward
params2 := Serial.rxDec
BackwardRight(params2)
else
Serial.dec(100)
Flash
params1 := false
params2 := false
params3 := false
'Motor driver code from now on
PUB ForwardLeft(Duty)
OUTA[0..3] := %0011
PWM.Duty(0,Duty,5000)
PUB BackwardLeft(Duty)
OUTA[0..3] := %0101
PWM.Duty(0,Duty,5000)
PUB ForwardRight(Duty)
OUTA[3..6] := %1100
PWM.Duty(6,Duty,5000)
PUB BackwardRight(Duty)
OUTA[3..6] := %1010
PWM.Duty(6,Duty,5000)
PUB Halt
PWM.Duty(0,0,5000)
PWM.Duty(6,0,5000)
PUB Flash
OUTA[22]~~ 'DEmo board status LED
waitcnt(clkfreq/10+cnt)
OUTA[22]~
"Client" board. This is not quite the code that I was using on the robot, but it shows how I communicate with the other code
CON
_CLKMODE = xtal1 + pll16x
_XINFREQ = 5_000_000
RxPin = 6
TxPin = 7
Calibration = 20
OBJ
Serial: "Serial"
Ping: "Ping"
PUB Main | data, cm
Serial.start(RxPin, TxPin, 0, 9600) 'Baud configurable
waitcnt(clkfreq*2+cnt)
repeat
cm := Ping.Centimeters(15)
if cm < Calibration
CMD(1)
CMD(Calibration-cm)
elseif cm > Calibration and cm < Calibration*2
CMD(2)
CMD(cm-Calibration)
PUB cmd(command) 'Send dec commands to host board
Serial.dec(command)
Serial.tx(13)
waitcnt(clkfreq/10+cnt)
I think this is all correct, the actual code I was using is on another laptop that I don't currently have access to, but this is essentially the same code.
Comments
'Tis a bit far, and as you said, maybe not quite the "outback", but it is certainly small, it's population is about 200 people.. a far strech from Brisbane's [FONT=arial, sans-serif]2,043,186... On the QAS's "remoteness scale" it rates a 6 out of 7.
Sorry about that cap schematic flaw, it was meant to be paralleled across the battery terminals. And yes, the 1M resistor was another mistake... Need to refine it, will get back to you on that.
Thanks for your help anyhow, I will try to fix everything. Mind you... if I need any parts, the local Jaycar is 2 hours away...
Thanks anyway,
-John
P.S. Interesting fact, "Baralaba" is spelt like "Banana" in the way that every second letter is an "a". Funnily enough there is a town nearby (about 20 minutes) by the name of Banana... But it wasn't actually named after the fruit, it was named after a bull.
[/FONT]
No need to refine the resistor value as it is not needed or desired as explained.
Here's a quick schematic of that supply filter which may in conjunction with the proper PWM signals alleviate voltage droops from resetting the Prop. All it does is hold a charge on the capacitor but the diode prevents it from feeding back to the motor supply which comes direct from the battery. You may find that the 1,000uf cap you already have would be better off being used in this manner.
I just found a PWM obj that I like, it seems to be working. Having said that, since my previous motors suffered "abuse" from high voltages, I think they have given up on me, not to worry though, I have 2 spares. Assembling them now to put them on.
Thanks,
-John
...?
You cannot pad down the h-bridge/controller output with resistance, that would limit the heck out of current.
If you cannot use a lower voltage for that then you have to use diodes.
It's inefficient as all get out, but if you're stuck on this 7V battery pack then that's how it is. Each diode results an approx 0.8V drop, 5 would be 4V, 7.4V - 4V = 3.4V (close enough, or add another diode each way).
If you've been zapping that 3V motor with 7V, the result will not be pretty, long term.
Thanks,
I was just able to vary the voltage of the motor drivers via the duty of the PWM any how, I find about a 50% duty gets me right about the right voltage for the motors.
I believe that the problem is solved now
-John
I reckon that you would know more than me what fixed the problem... But anyway, I have said a number of times that the problem has been fixed... then it appeared again...
I have just dissasembled my robot due to the gear boxes needed replacing. Once I get the robot back together, with the new gearboxes, a new battery strap, and a PS/2 port, I will do some more extensive experiments.
I assume that it was the drop in voltage that caused the prop to reset, as its appears only logical answer to the problem.
Apart from the wiring that I had in place, I changed the code to a library that I found on the OBEX. I don't really know what the library was called.. but it does a great job with PWM
-John
P.S. I probbably wouldn't dismiss this problem that quickly as it has happened to me so many times that it isn't funny. I started about 1 month ago with dual serial motor drivers... I had problems with them... Then I moved to H-Bridge drivers.. then I had problems with them... I wish I knew more about this stuff so I could fix it more readily :} Well anyway, you learn from your mistakes, so although I'm havin' this problem now, I probbably won't have this problem again
That's all relative to many factors, freq, pw, motor XL -- all of which which are, in this context, Unknown, as many other specifics.
DC motors aren't forgiving, quite the opposite, and more so the little crappy sort.
7V to a 3V motor is excessive, especially when somebody has no idea what he's doing.
The diodes are like training wheels.
I guess there'll be more "it's fixed"/"no, it's not fixed" stuff down the road.
Blindly doing this and that, incorporating unknowns from the obex, hoping something might happen, and wondering why nothing ever works just isn't making it.
Have fun, boys!
Anyway I doubt very much that the voltage was as high as John measured it as he is relying on a cheap meter and trying to measure a pulsing motor without understanding what he is seeing. It's a bit like someone measuring 4V on the output of a 5V regulator and assuming the regulator is faulty when the input is measuring 8V. What they are missing is that the DC meter is reading the average of a lot of ripple due to a dried out electrolytic. Switch the meter to AC and it comes alive. The fact is that the board would cut out very quickly and the motor will not be destroyed that quickly will it?. You really need to overheat it which will only come about with too much current for too long.
Good thing I was using my father's meter... or you'd be quite right. How can you assume that the meter I was using was wrong? At any rate, you are probbably right.
Heh, I reckon I'd better "lay low" for a while, seems like I've made a few "enemies".
-John
So try not to see any bad or anything personal in what someone else says or how they react, it'll all blow over. Just keep waving and smiling and all friendly like, you know what I mean.
Anyway I said cheap meter, not bad meter as either will give you the same reading to a point, but really it comes back to knowing what the limitations of your test gear are and how to use them properly in different situations. That's why I gave a short example of measuring a faulty power supply with a meter. The results would be the same if you used an expensive meter but understanding a bit more about the device under test and the device observing the test certainly helps a lot. In your case bear in mind that DC motors are inductive and also generate back-EMF in which case an oscilloscope would be more beneficial to see what is going on. If I step in to correct a misconception, I will go to some lengths to explain why as you have seen but we are all busy and only have so much time so posting is a luxury and rather low priority normally I'm afraid.
One last thing, someone mentioned putting a diode in to run both prop and motors off the 1 batt, how can I do that?
Thanks,
John
Did you scan back through the posts at all???? The schematic shows the connections so it's only a matter of having a diode in series with the battery supply that runs to your VIN of the Prop board and then adding a large enough capacitor to the the VIN side. You might even be better off taking the large 1,000uf cap you have now and putting it on the VIN side. Diode anode is connected to Vbatt, diode cathode to VIN.
In any case, I just tried a 6V torch battery as the processor's power supply, and the RC car batt as the motor's supply... still the same issue. They are both sharing the same ground. The power LED is flickering on the board, so some how the motor driver is drawing power from the chip.. I have no idea how.
Well, I'll keep working on it.
I hope you mean that they are both sharing the same ground AT the battery negative and not at the negative terminal of the logic board. The fact that your power LED is flickering seems to indicate that your battery supply is drooping and the difference between this board and the others could very simply be a matter of PWM duty cycle. If the Prop board is leaving the motor pulsed on for too long it can cause a problem. You want to make sure that output is correct and since you have basic test instruments *your Dad's meter" then I suggest disconnecting the motor and put a small 6V torch bulb in there for the moment. Measure the voltage across your bulb to ensure that the duty cycle is correct then substitute the lamp for the motor.
Well... a bit of a long story. I burned out (Somehow) the screw terminal block of the GG prop board. I now connect the power to the prop from the VIN and the GND sockets of the board. As of yet this hasn't had any ill effects. So in a sense, I am connecting both GND's at the logic board, but at the same token, it is kinda at the batt terminals.
Also, with the prop demo board, I can't connect both GND's at the battery terminals because it is using the mains socket. In this case I am connecting the GND to the logic board's GND.
I'll see what I can cook up - but hopefully not cook...
Although this has been a long road (about 2 months), I believe it is comming to an end, and then I can start the *cough* glorious *cough* task of doing everything else... Having said that, I wasn't ever much good at electronics and mechanics, I'm more the programmer type, I guess I've been programming much longer than wiring
-John
I'm surprised that your serial communications was not fast enough but then I looked through the thread and found your code which was using a baud rate of 9600. Now that's fine for a little console debugging maybe but why go so slow? That object is fine up to 115.2K baud and I have plenty of objects which run at megabits/sec although you would not use archaic RS232 drivers for these speeds.
Don't think you've taken the trophy for long roads though as we have all experienced longer roads then this I think
Will do
Okey dokey, you mentioned a different serial driver for the RS323 serial comms, where could I aquire this? Note: I did speed up the baud later on up to 115200, still didn't appear fast enough, maybe I'm doing something wrong, but it just didn't update fast enough for my liking. Well anyway, I think the switch to the HB-25 drivers will be a change for the better, I can't imagine how I would have any trouble with them... after all, I'm running at about a 300ma, and they are rated at 25A... They also have a very easy interface to use. Well, anyway, I hope this turns out well. Here's a bit more information about the base:
It is getting built for RCJA State Championships at Brisbane in August, for those not familiar with RCJA it basically comprises of the robot having to follow a line, making decisions at T-Junctions and going around obstructions. The most commonly used base at such comps are the Lego Mindstorms - that's why I need to win, to show them that it is possible to custom build such robots
I think if I can get the base assembled well, and the programming working great I can throttle those mindstorms kids at the comp
Well anyway, time to get back to whatever I'm supposed to be doing, and I'll keep y'all updated.
-John
Can you post your code because I would like to see where this communications bottleneck is as it may not have anything to do with the speed. Just as a note for now fast serial drivers also require fast access from Spin code for full throughput and many of these OUT and IN routines are bogged down with handling the FIFO buffers. To streamline that it is easier to read/write a variable which will have the latest character and status. It would be good if Spin had a single fast read and clear operation.
Server code (Demo board with motor driver on it)
{ Name: Jaws Serial Motor Driver Firmware Author: John Board (c) 2012 John Board } CON _CLKMODE = xtal1 + pll16x _xinfreq = 5_000_000 RxPin = 31 'Currently set to computer comms, can be set to other pins TxPin = 30 Baud = 9600 'Was also tried set at 115200 OBJ PWM : "PWM_32_v4.spin" Serial: "Serial" PUB Start | Duty, alarmCount waitcnt(clkfreq/2+cnt) DIRA[0..6]~~ 'Motor driver stuff OUTA[3]~~ DIRA[16..23]~~ 'Motor driver stuff DIRA[RxPin]~ PWM.Start DIRA[23]~~ 'Demo board status LED repeat until ina[RxPin]==1 'Wait for other chip to connect... OUTA[23]~~ 'Demo board status LED Serial.start(RxPin,TxPin,0,Baud) SerialLoop 'Enter Main Loop PUB SerialLoop | params1, params2, params3 repeat params1 := Serial.rxdec if params1 == 1 'Forward Serial.dec(1) params2 := Serial.rxDec ForwardLeft(params2) elseif params1 == 2 'Backward Serial.dec(4) params2 := Serial.rxDec BackwardLeft(params2) elseif params1 == 3 'Reboot reboot elseif params1 == 4 'Halt all systems Halt Serial.tx(3) if params1 == 5 'Forward params2 := Serial.rxDec ForwardRight(params2) if params1 == 6 'Forward params2 := Serial.rxDec BackwardRight(params2) else Serial.dec(100) Flash params1 := false params2 := false params3 := false 'Motor driver code from now on PUB ForwardLeft(Duty) OUTA[0..3] := %0011 PWM.Duty(0,Duty,5000) PUB BackwardLeft(Duty) OUTA[0..3] := %0101 PWM.Duty(0,Duty,5000) PUB ForwardRight(Duty) OUTA[3..6] := %1100 PWM.Duty(6,Duty,5000) PUB BackwardRight(Duty) OUTA[3..6] := %1010 PWM.Duty(6,Duty,5000) PUB Halt PWM.Duty(0,0,5000) PWM.Duty(6,0,5000) PUB Flash OUTA[22]~~ 'DEmo board status LED waitcnt(clkfreq/10+cnt) OUTA[22]~"Client" board. This is not quite the code that I was using on the robot, but it shows how I communicate with the other code
CON _CLKMODE = xtal1 + pll16x _XINFREQ = 5_000_000 RxPin = 6 TxPin = 7 Calibration = 20 OBJ Serial: "Serial" Ping: "Ping" PUB Main | data, cm Serial.start(RxPin, TxPin, 0, 9600) 'Baud configurable waitcnt(clkfreq*2+cnt) repeat cm := Ping.Centimeters(15) if cm < Calibration CMD(1) CMD(Calibration-cm) elseif cm > Calibration and cm < Calibration*2 CMD(2) CMD(cm-Calibration) PUB cmd(command) 'Send dec commands to host board Serial.dec(command) Serial.tx(13) waitcnt(clkfreq/10+cnt)I think this is all correct, the actual code I was using is on another laptop that I don't currently have access to, but this is essentially the same code.
-John