TreadBot

so... i havent forgotten about this, im still working on it. I have just had a lot of work and other stuff to do lately. when i use:

For speed = 0 TO 80
'speed up motor to full speed
SerOut2 lcd, baudlcd,[254,"G",1,4,#speed," "]
'display speed on lcd
SerOut2 motor, baudmotor, [$80, 0, lfwd, speed]
'left motor forward
SerOut2 motor, baudmotor, [$80, 0, rfwd, speed] 'right motor forward
Pause 150
next

both motors will speed up to around 45 or 50, and then just shut off. nothing seems to be overheating, and the voltage doesnt drop. the PIC still keeps running because the LCD will still show the Speed Variable increasing. i have tried pulling the reset pin low and then high again at the end of each cycle of code, but that doesnt help either.

if i tell it "speed = 80" then it will run fine, and have no problems.. i think maybe there is an issue with the motor controller recieving too many serial commands in such a short time, or something is getting messed up in the commands.

do hopefully by the weekend, i will have the ultrasonic sensor working and it driving around...

thanks for all the advice everyone...

If you are using the Pololu motor controller, make sure it's reset pin is held high. If it dips to 0V, it will reset the controller to its inital state (motors off).

If you are using the Pololu Low voltage Dual serial controller:
The green leds on the controller should also be on for forward settings, see if they are still on when the problem occurs.

It looks like you have enough of a delay after the motor serial commands.

--John

Maybe try a little bit of 'DEFINE CHAR_PACING'?
It add x ms between serial characters on the output.
Maybe at the higher settings it doesn't like having x characters in a short amount of time...who knows...

yeah, i have been keeping the reset pin high. i have also tried to reset it after every loop...and i can get it to slow down from 80 to 0 using the same program without a problem.

so i got the motors workign by changing the caps across the leads. i found out a couple days ago that the drawers i keep my caps in got messed up, so i ended up putting in 22pf caps instead of 1uf caps.

so now i added on the parallax ping ultrasonic sensor, and its messing something up. heres the short code for the sensor:

PulsOut ultra, 5
PulsIn ultra, 1, ping

"ultra is the port, and ping is the distance variable. the pulsin line seems to work, and the LED lights on the ping sensor, but everytime i send the pulsout command, it sends wierd characters to the LCD, and the "ping" variable doesnt change from 0.... the LCD is on portf.0 and the ping sensor is on portf.1.... the traces are fairly far apart, and there is nothing touching them.

if i delete the pulsout line, everything displays where its supposed too, and the ping var = 0...

i know i didnt describe it the best, but if anyone has any ideas, please let me know...

Quote:

---

Originally Posted by dragons_fire

so now i added on the parallax ping ultrasonic sensor, and its messing something up. heres the short code for the sensor:

PulsOut ultra, 5
PulsIn ultra, 1, ping

"ultra is the port, and ping is the distance variable. the pulsin line seems to work, and the LED lights on the ping sensor, but everytime i send the pulsout command, it sends wierd characters to the LCD, and the "ping" variable doesnt change from 0.... the LCD is on portf.0 and the ping sensor is on portf.1.... the traces are fairly far apart, and there is nothing touching them.

if i delete the pulsout line, everything displays where its supposed too, and the ping var = 0...

---

Those ultrasonic transducers generate some fairly high voltages while doing their work. I can easily see one of those dumping current across traces and causing your problems. Maybe try putting a series resistor inline with portf.0 and see what happens. Don't run the transducer, start low on the resistance, work your way up until the LCD doesn't work anymore, then back off one or two values. Then fire up the transducer and see what happens...
Have you ever been 'bit' by one? I wouldn't touch the bare metal on it while it's doing it's 'transducing'.

Did you set the ultra pin to 0 before using Pulsout?

Pulsout works by toggling the pin twice. To get positive pulses, the pin needs to be set low first. (if it wasn't already there)
<br>

yes, i took it low before doing anything. heres a little more of the code:



trigger con 5
baudLCD CON 32 'baud rate for lcd
lcd VAR PORTF.0 'lcd port
ping VAR byte
ultra VAR PORTF.1
PORTF.1 = 0
ping = 0


SerOut2 lcd, baudlcd,[254,"G",1,1,"Ping Test"] 'display test on lcd in position 1,1

start:
Pause 1000

PulsOut ultra, trigger 'send trigger to ping
PulsIn ultra, 1, ping 'wait for ping variable

Pause 1000
SerOut2 lcd, baudlcd,[254,"G",2,2,#ping," "] 'display pin var in position 2,2

GoTo start
End



so wheni take out the "pulsout ultra, trigger" line, everything works great (except the ping sensor cause it doesnt get its pulse). i added in long pauses so i could tell where the problem is. my LCD will display "ping test" in the correct position, then waits a second, displayes a wierd character, waits another second and then displays a couple wierd characters and then the ping variable. when it shows the wierd characters and ping variable, it just adds them right behind "ping test", not in the position its supposed to be in..

Try this out and see what happens:

trigger con 5:baudlcd con 32:lcd var portf.0: ping var byte:ultra var portf.1: portf.1=0: ping=0:SerOut2 lcd, baudlcd,[254,"G",1,1,"Ping Test"]

start:
Pause 1000
PulsOut ultra, trigger
PulsIn ultra,1,ping
flags.0=0
Pause 1000
SerOut2 lcd, baudlcd,[254,"G",2,2,#ping," "]
GoTo start
End

The flags.0 = 0 basically resets the LCD, might help, might not...never know...

EDIT: And as mister_e noted below, flags.0 don't help here...DOH!!!

:( FLAGS work ONLY with LCDOUT... :(

DragonFire, did you set the TRISF as well? unless PORTF.1=0 won't do anything as the default setting for PORTF 'should' be input ... yeah i love guessing ;)

So OR you set TRISF.1 = 0 at the top of your code, OR you can use LOW PORTF.1. LOW/HIGH will do it for you.

It's up to you.

NOW, you can't use PULSIN/PULSOUT as you did, PULSOUT is not working in background, so it will finish to do it's job, then your program will execute PULSIN. As the pulse is already gone, it won't read it.

Of course, an interrupt would do the trick... of course with DT instant interrupt, not PBP ON INTERRUPT.

What i figure to be working, in your ISR, you start a timer, you change the interrupt trigger type (rising/falling edge), then at the next interrupt, you read the Timer value.

Still possible to use the CCP module... it's design for it.

I suggest you to read the following Tips 'n Tricks doc of Microchip. It's all there
http://ww1.microchip.com/downloads/e...Doc/41214a.pdf

EDIT: i saw you READ/WRITE to the same pin (ultra)?

SEROUT2 should be used with DEC modifier instead of #... maybe this is why you have some weird character.

I heard some LCD may need some CR or LF character to work properly.. not sure if this could apply to yours.

i just gave that a try, and it does the same thing.... im going to haved to play around with it a little more later...

the pijng sensor im using, only has one I/O pin, it actaully takes the "trigger pulse" in and then waits 200uS and then sends out the ultrasonic pulse, so that part of the code was copied right out of their demo code for the BS2. i have had it working before on a 877a, so i just copied my code from that.. im sure its just a stupid little thing...

it actually seems like maybe the baudrate is just a tiny bit off, but i can send the first command fine...

Quote:

---

Originally Posted by dragons_fire

i just gave that a try, and it does the same thing.... im going to haved to play around with it a little more later... the pijng sensor im using, only has one I/O pin, it actaully takes the "trigger pulse" in and then waits 200uS and then sends out the ultrasonic pulse, so that part of the code was copied right out of their demo code for the BS2. i have had it working before on a 877a, so i just copied my code from that.. im sure its just a stupid little thing... it actually seems like maybe the baudrate is just a tiny bit off, but i can send the first command fine...

---

Can you slow down your SERIAL LCD? (notice how I remembered it was a serial lcd this time?) Run it at 2400 baud instead of 9600, or maybe slower, and see what happens?

when i use: pulsin portf.0, 5
it should put pin f.0 high for .005 seconds right??? i am really realizing how much i dont know about this stuff. most of my robots have been made by trying different code until it works. on this one, i am learning a little more code but i still dont know how all this works..
heres the code:

DEFINE OSC 20
TRISF.1 = 0

'variables
'----------------------------------------------------------------------------------

baudLCD CON 32 'baud rate for lcd
lcd VAR PORTF.0 'lcd port
ping VAR WORD
ultra VAR PORTF.1

Low PORTF.1
High PORTF.0
ping = 0

'Startup Program
'-------------------------------------------------------------------------------------- 'start motor driver

Pause 3000 'pause for LCD startup screen 'reset motor driver 'wait a few seconds
SerOut2 lcd, baudlcd,[254,"X"] 'clear screen
Pause 100
SerOut2 lcd, baudlcd,[254,"X"] 'clear screen again
SerOut2 lcd, baudlcd,[254,"P",140] 'change resolution
SerOut2 lcd, baudlcd,[254,71,1,1,"Ping Test"] 'display test on lcd in position 1,1

'main program
'----------------------------------------------------------------------------------------

start:

PulsOut ultra, 5 'send trigger to ping
PulsIn ultra, 1, ping 'wait for ping variable

Pause 1000

SerOut2 lcd, baudlcd,[254,71,5,3,DEC ping," "]

Pause 1000

GoTo start
End


and heres a video or whats happening...
http://s163.photobucket.com/albums/t...adbotultra.flv
unfortunately, its not easy to see the LCD screen, so it may not help much


thanks for all the help...

RF0 is AN5
RF1 is AN6/C2OUT

So these might help.

Code:

---

ADCON1 = $0F
CMCON = 7

---

<br>

once again, you are amazing!!! i know somehow that makes then digital instead of analog, but i havent ever figured out how all that works...

maybe there will be a video later on...

Then I wouldn't worry about the A/D stuff right now. So far none of your project will be using analog. So you can just leave them turned off.

I think you've got "Bigger Fish to Fry".

If you do add analog stuff later, just take a look at the ADCON1 register (19-2) in the data sheet. There's a table that shows what values to use for whatever analog inputs you need. Same for CMCON.
<br>

i definately have a lot of "frying" to do!!! i enjoy the challenge of trying to make this stuff work but sometimes its nice to have help from you guys that know what you are doing.

i have another small problem right now. i used if/then (i know they arent the best way to do stuff, but its easy) statements so if the distance is more than "900" then it will drive fast, if its lower than "900" then it will slow down, and if its lower than 350 it will stop and turn, then drive fast again until it senses something..

so it will drive fast, and then when it gets to under "900", it slows down, but then it stays at that speed, and it doesnt send out pings.

im almost positive that im either missing something or things arent in the right order.

im going to play around with it a little more before i "officially" ask for help. that way i can learn all the things that dont work!!!