Dave
Always wear safety glasses while programming.
Dave,
do you keep the *.bas, *.pbp in the default directory? Does compiler have any problem with the path?
I am considering to keep my files there too.
Ioannis
Ioannis,
I let PBP and MPLAB install to their default directories, but my actual code and related project files are kept here.
C:\MAC\My Dropbox\PIC PROGS\"project name here"
Cad/CNC files and such are in a sub directory of the above.
Another benefit from having an off site backup... My CNC machine's PC is also DropBoxed so the machine always has the latest files automatically.
No problems with the path, the path name is still under the length limit this way.
Dave
Always wear safety glasses while programming.
Ladies and gentlemen - I am bamboozled. My 1/10 toy level car seems to be a bit confused also. Garbage in. Garbage out. The old give-no-quarter rule of programming. Is the issue response time? Is the issue inconsistent friction? Is the issue - no it couldn't be - my PBP code? I believe the electronics are consistent and the hookup wires are stable ( I used Silicone household sealant)
In the video I say, "As soon as it starts to turn right, it's in trouble." That now seems not to be the problem. After it successfully negotiates a corner-caused left turn and it is too close to the new wall, it turns left to get out to desiredtrack, but never straightens out.
The code is at: http://www.employees.org/~kjones/ToyCarKickTurn4.htm
Any insight would be greatly appreciated.
Ken
Its really cool!! It has come a long way, in a very positive way.
When its stuck, I see 2 distinct possibilities. the first time when the car was perpendiculer to the wall, my guess was it was too close, therefore the front sensor missed the echo. the second and third times, when it was trying to go forward into the wall, my guess is the angle was just right so as the reflection of the sonar bounced off the wall and kept going forward so the car thought it was all clear ahead.
One time towards the beginning it ran head on into the wall. it went straight back, I am not sure if it bounced or if the car said reverse.
Overall it seems like response time may be the issue. are you able to slow the car when the front is blocked and needs to turn? If so, maybe cut the speed to half when the front is blocked. then on the all clear go back to full ahead. I don't think the car is able to make the turn, check the front, check the side and continue forward.
-Bert
The glass is not half full or half empty, Its twice as big as needed for the job!
http://foamcasualty.com/ - Warbird R/C scratch building with foam!
I suppose an echo has a significant energy distribution pattern which is a function of the angle on incidence. I do not know the physics but it certainly seems reasonable.
Thank you!
Ken
You got it Ken. Your ICSP pins are RB7 and RB6. I think I have the definitions right for you. So you should be able to get it to talk pretty easy.
Last edited by ScaleRobotics; - 31st January 2011 at 01:54.
Friction is sure a problem with your car along with others...
Try to increase the friction with this simple idea.
Cut from a kitchen glove the fingers and place the cut parts on your wheels. I think these will last for a test run, at least.
With the increased friction you will get over the overturning of the car.
Ioannis
1. I cobbled together the working parts of two DELL 8600 lap tops and created one that works!! I installed the PBP tools and have a strong new battery. I will be able to modify my code in the building - sans electricity and heat - where I test.
2. I found that putting a cardboard right up to the front SONAR makes it behave as if there is nothing within range. Sooo up real close is far away as far as it is concerned.
Hi Ioannis,
Yes, it takes TTL True, so Ken can do debug something like this for his setup:
Code:DEFINE DEBUG_REG PORTB 'This is set to match the ICSP pins DEFINE DEBUG_BIT 7 'PIC sends data to the PC on this pin DEFINE DEBUGIN_BIT 6 'Can be used to receive data from the PC DEFINE DEBUG_BAUD 38400 'This is the highest baud rate Pickit2 can handle 'It seems to work ok with my 8 mhz stuff and higher DEFINE DEBUG_MODE 0 'Sets debug to True levels (1 for inverted)
Last edited by ScaleRobotics; - 30th January 2011 at 22:08. Reason: Edited for Ken's hardware
My PICkit2 communicates with my PIC on its pins 4 and 5 already. Are you saying that after it is downloaded and running, my code can use the same USB wire to talk back to the PC? And I can display what it says using the DEBUG tool.
Ken
As Walter stated, exactly that Ken!
So, this is a great tool. I wonder why Pickit3 does not support this handy idea.... Mysterious way Microchip works...
Ioannis
It's in there ... about 1/4 the way through.
Code:;**************************************************************** ;* HPWM : Output a pulse width modulated wave in hardware * ;* * ;* Input : W = channel 1 - 5 * ;* : R1 = frequency * ;* : R4 = duty cycle * ;* Output : None * ;* * ;* Notes : * ;****************************************************************
Hi Ken,
DIG is for digit. Nothing in there needs any include file. Dig is covered in the manual, but you have to look around a little bit for it. DIG returns the value of a decimal digit.
C var byte
D var byte
C=123
D = C DIG 0 ; Makes D = the lowest digit of C (3)
When I mentioned debug, I meant the DEBUG command. It lets you send serial out of any one of your PIC's pins. Then you can use the Uart tool on your Pickit2 to read any value you want. Much simpler than Mplab debugger if you ask me.
![]()
Hi Walter.
I saw this picture of Pickit2 with UART connection. Does the PIC connect to Pickit2 as TTL level serial link?
Ioannis
Bookmarks