PBP projects for R/C models

[Kenjones1935]

On page 251 of DS33014K in Appendix A. is the list of ASM instructions.
I had printed out that document last winter. Until now I did not find this list. (Except in a book printed by MikroElectroika in Belgrade.) I think this list ought to be the first thing in Chapter One!

Thanks, all. Gotta "hit the books".

Ken
Ken

[Kenjones1935]

I have not yet had to fall back on ASM code.

I did discover:

1. My PIC was resetting because of regressive subroutine calls. Changing a couple GOSUB's to GOTO's solved that.

2. My car was not being driven smoothly because of occasional zero responses from the SRF05's (or at least one of the SF05's). Implementing a - check again if the sensor says zero - routine after polling the sonar sensors smoothed things out.

I did notice that adding an IF THEN statement to the PBP code increased the size of the HEX code considerably. I still feel I need to understand the two compile processes.

[Kenjones1935]

Today I gained access to an abandoned gymnasium.

Immediately I realized that to make this project 'interesting' to middle school students I must greatly increase the speed. I will need to adjust the distances which trigger the car's autonomous maneuvers. My next video will be of this car racing and toggling between PIC and RC control.

Ken

[Kenjones1935]

Not going well at all.

When I up the speed the car does not respond quickly enough. At a corner Instead of seeing (hearing) ahead and turning, it crashes into the on coming wall, backs up, and tries again. Part of my problem is not understanding the machine language code behind the PICBASIC PRO commands. Another part is the PIC getting into little loops or resetting and thereby ignoring the real time signals. Lastly I need to expand the distances to which the code reacts. If the velocity is greater, it must start turning or braking sooner.

On the bench, the machine seems to behave as expected, but on the race track. NOPE.

Ken

[mackrackit]

Hi Ken,

I may have a solution to your problem, or part of a solution...

I picked up a PING module the other day and did some playing and watched the last video you posted very close.

My conclusion is you need to run the PIC at 20MHz.
I am running a very basic code to calculate distance so my findings may not be a total solution.

Watching the video it appears the car is pointing more at the corner the first time through, and the second time when it does not hit the wall it is just a bit to the right and a little more straight on. When I try corner targets the reading becomes very erratic. Maybe for you have the front sensor pivot slightly from left to right. Could be done with a spring and a cam bumping on the wheels?

Back to the software. I am using a PIC running a 20MHz.
When I set the PULSOUT at 10 giving the 20us you have in your code the readings become inaccurate with a great deal of fluctuation and slow to respond.

When I set the PULSOUT at 2 giving a 4us pulse the accuracy is within an inch and very very quick to respond.

[Kenjones1935]

First, my oscillator. I have been using the 16F887's internal oscillator. I think if I do nothing my prescaler is set at 4:1. The PIC has an 8mhz internal oscillator. Figure 4-1 on Page 61 of DS41291F (the x887 gospel) indicates that by setting OSCCON = %01110111 I can get the internal 8mhz oscillator and the prescaler of 1:1. Does this seem correct to you all? I will try this evening.

What do I need circuit-wise to implement the 20Meg external crystal oscillator?

Second, the placement of my forward looking SRF05. I thought I found that slanting them to the left just a bit makes less possible reflection from the side wall coming into the front pingers. That seemed to work on the bench, but again confusion in the real world. I have not thought through what the side pingers should be hearing while the car is turning left. For racing I have moved the desired track out to 24 inches away from the side wall.

Using a carpenters measuring stick I have calibrated my pingers. They seem consistent (again on my bench).

Ken

[rmteo]

First, my oscillator. I have been using the 16F887's internal oscillator. I think if I do nothing my prescaler is set at 4:1. The PIC has an 8mhz internal oscillator. Figure 4-1 on Page 61 of DS41291F (the x887 gospel) indicates that by setting OSCCON = %01110111 I can get the internal 8mhz oscillator and the prescaler of 1:1. Does this seem correct to you all? I will try this evening.

Ken

The oscillator (whether internal or external) frequency is always divided by 4 in these PIC's to get the instruction clock - it does not have anything to do with pre-scalers. Also, OSCCON.3:1 is read only.

[Byte_Butcher]

Yep, you got it. But no point in setting bits 1&2... they're read only.
This is what I use to set the 16F887 to 8MHz.:
OSCCON = %01110001 'Set Osc to 8MHz.

And don't forget to add to your define list: DEFINE OSC 8


For external xtal you will need a 20MHz crystal connected to OSC1 & OSC2 (RA7, RA6) and a small capacitor from each pin to ground. The recommended capacitor size will be in the xtal data sheet, but is typically a couple dozen pF or less.

steve

[mackrackit]

When bumping up to 8MHz try

pulsout trigfront,1

That should give you 5uS trigger. I was doing 4.

For external OSC I like ceramic resonators, good and bad to everything but with these you do not have to mess with capacitors, that is why I like them.
http://www.allelectronics.com/make-a...ATORS/-/1.html
The two outside pins will go to RA6 and RA7, the center to the zero rail (ground).
The problem with the 44 pin demo board is Micro Chip did not "ground" the via between RA6 and RA7, so you will have to run a jumper if you go this route.

[Kenjones1935]

Bed time here on the east coast.

I tried both
OSCCON = %01110111
and
OSCCON = %01110001

I got the PIC to read the PWM signal from the radio channel 3 by doubling the threshold for differentiation. I can toggle between PIC and radio control.

But I have not been able to get the HPWM to behave. I tried using the original duty cycle. This made the wheels go backwards very fast no matter what was in the HPWM command. I tried doubling the duty cycle (to account for cutting in half the clock rate and the wheels did not turn at all. The Electronic Speed Control wants this PWM signal to arrive at 50 hz. In fact it is probably at 489Hz (according to page 87 of MicroEngineering Labs' PICBASIC PRO book). I'll put a 'scope on it tomorrow.

I think the book says that HPWM channel, 127, 50 will be a square wave of 489Hz. Does that agree with you guys' thinking?

I also have not gotten the PING echos to mean anything. The little red lights on the SRF05s are blinking. But my code is not making sense of the echo responses. I thought that all I would need to do was to double the expected echo pulse duration numbers.
Ken

[Byte_Butcher]

Bed time here on the east coast.

I tried both
OSCCON = %01110111
and
OSCCON = %01110001

I got the PIC to read the PWM signal from the radio channel 3 by doubling the threshold for differentiation. I can toggle between PIC and radio control.

But I have not been able to get the HPWM to behave. I tried using the original duty cycle. This made the wheels go backwards very fast no matter what was in the HPWM command.

did you add :

DEFINE OSC 8

to your code somewhere near the top?
Otherwise the PIC thinks you're still running at the default 4MHz.


steve

[rmteo]

The Electronic Speed Control wants this PWM signal to arrive at 50 hz.

Ken

No matter how you cut it, to get 50Hz (20mS period) using hardware PWM, the maximum clock frequency you can use is 0.819MHz (819KHz)

[mackrackit]

Darn,
I thought the SRF05 was the same thing as the PING. Now I see that the SRF05 takes a different trigger pulse.

So it looks like I just wasted your time on that part.

I guess on the good side rmteo noticed another possible problem.

I wonder if a While/Wend loop using PWM would be the answer?

[Kenjones1935]

Originally Posted by Kenjones1935 View Post
The Electronic Speed Control wants this PWM signal to arrive at 50 hz.

I was not clear in my last posting. The Electronic Speed Control PWM specification is for a single positive pulse no less than 1ms and no more than 2ms once per 20 ms, ie 50 pulses per second. The one to two millisecond pulse width is divided into 256 parts. 1.5 ms corresponds to 128 which corresponds to neutral in a servo.

Neutral is steering straight on a steering servo. Neutral is stopped on a wheel driving servo.

I discovered that using HPWM with the 4mhz default oscillator a pulse width of 100 to 110 gets the behavior of 'neutral' on my car. For example "HPWM 1, 100, 50" turns the front wheels of my car to straight. See the attached picture. Channel 2 is the HPWM version of neutral. Channel 3 is what the radio receiver sends.

Ken

[Kenjones1935]

I have found a way to make short, 10 to 80 usec pulses while using the 4mhz oscillator. The SRF05 proximity detector wants at least 10 usec. If I give it super long pulses catching the following echo measurement can be a problem for PULSIN.

Sooo the following makes an 80 usec positive pulse.

SYMBOL trigright = PORTB.0
LOW trigright
HIGH trigright
HIGH trigright
HIGH trigright
LOW trigright.

One thing at a time.

Ken

[Kenjones1935]

I now have the sonic ping devices (SRF05's) flashing continuously. There is no blockage in the PIC's processing.

Now the car is reacting too quickly. There is a bit of code that used to guarantee a 1/2 second backing up when backing up was necessary. Now the count down for this delay is instantaneous. While turning a corner the proximity sensor data gets confusing. Both the side sensors and the forward sensors are hearing important echos. I might need to adjust the positions of the two SRF05's or write some code especially for that situation. I am not sure - elusive. Like I said.


Ken

[Ioannis]

Hope you are not activating both sensors at the same time, right? Be sure to give some time for the echo to decline enough before confusses the other sensor.

Ioannis

[Kenjones1935]

I've added a PAUSE of 1/10sec between the front trigger and the side trigger. This noticeably slows down the flashing of the LEDs on the SRF05s. In the audible range I can easily hear echos in a room. I have no experience with ultra-sound in the range that the SRF05 emits. The spec shows a time line in which the pulses seem to be a square wave of 2usec cycles. That is a little burst of 500,000 cycles per second sound that appears to last about 20 usec.

This little project keeps gets interestinger and interestinger!

If there were five cars racing near each other on this gymnasium track, would their SRF05's get confused. I don't think so, but I am not sure....

Ken

[Ioannis]

If there were five cars racing near each other on this gymnasium track, would their SRF05's get confused. I don't think so, but I am not sure....

They SURE would. That is what I noted on my previous post. Your sensors are hearing echoes that keep coming long after the transmission stopped. No matter which of the SRF05's did the transmission. Keep note of that.

Maybe an IR sensor would be more appropriate here. Also faster.

Ioannis

[Kenjones1935]

If I went with IR proximity sensing, the reflections would be from brick, wood and cardboard. Distance one to five feet should do it. Any suggestions?

Ken

[ScaleRobotics]

I have not used them, but here is one that is within your measurement range GP2Y0A02YK:

http://sharp-world.com/products/devi...gp2y0a02_e.pdf

One thing that isn't so good, is that you will get a false reading if you are closer than 8 inches.

[Kenjones1935]

Today I took some cardboard boxes to my gymnasium race track. I arranged them in the middle of the floor about six feet from the walls.

The car did not behave as expected. It is futile to try to describe what it did. I shall video tape it (probably not for public consumption) and try to analyze what is happening.

The SRF05 flashing LEDs are constantly illuminated. That should be good.

My present code has only two 'regular' states.

1. Going forward being guided by the side looking SRF05. The forward pings are monitored for something close enough to merit turning hard left while still going forward.

2. Going backward and turning to the right because the front looking pinger sees something too close. The backward state is left by either timing out, or by the forward looking pinger saying that the obstruction is no longer there.

With the car on blocks and me manipulating a large piece of card board, the wheels move true to concept. In the gym was something else.

Interesting stuff, real time control code. I made my living in data communication hardware and software development. Nothing actually 'moved' in the common sense of the word.

Ken

[Kenjones1935]

I made this video of my car on my "race track"

As I speed up the car the behavior becomes less consistent.

Take a look see if you like. It's only a couple minutes long and the car does work correctly sometimes.



Ken

[Kenjones1935]

I want to use the interrupt system to make my Pulse Width Modulated pulses output at 50hz. I am hoping that will give me finer control of the wheel speed and maybe a quicker steering response.

I understand that I need to preset TMR1 with a number so that it rolls over every 20 ms. thereby triggering the interrupt. How do I figure out what that preset number should be and how do I set it using PBP?

Ken

[rmteo]

Looking at the datasheet:

6.7 Timer1 Interrupt

The Timer1 register pair (TMR1H:TMR1L) increments
to FFFFh and rolls over to 0000h. When Timer1 rolls
over, the Timer1 interrupt flag bit of the PIR1 register is
set. To enable the interrupt on rollover, you must set
these bits:
• TMR1ON bit of the T1CON register
• TMR1IE bit of the PIE1 register
• PEIE bit of the INTCON register
• GIE bit of the INTCON register
The interrupt is cleared by clearing the TMR1IF bit in
the Interrupt Service Routine.

With a 4MHz clock, (TMR1H:TMR1L) increments every 1uS. To generate an interrupt every 20mS, you want it to count 20,000 - so preload (TMR1H:TMR1L) with 65535-20000 = 45535 or FFFFh-4E20h=B1DFh.

[Kenjones1935]

I think a big part of my problem is peripheral vision (hearing) of the front
sensors. As the car sped up I had to increase the frontdanger threshold. Now if the car gets turned a little to the left while running down the straight
it 'sees' the cardboard and turns left thinking that it is coming to the
corner. Solutions?

The simple one is to place the cardboard further away from the side wall.

I could rewrite the code so that hard turning left only is allowed when close to the side wall. Trouble with that is if the car ever got free in a room it would crash straight into walls.

I could add left side SRF05's. That would make staying in the middle of the lane easier and minimize the effect of peripheral hearing.

What do you all think?

Ken

[Kenjones1935]

I have added a left looking SRF05. This gives the car great new autonomous potential. I shall stick to the first problem first. Disappear behind a card board wall and come out the other end at speed.

My first thought is to stick to the path half way between the solid wall and the card board wall using the right and left sensors for guidance. If I can keep the car pretty much following that line without oscillating then once the front echo says, "DANGER", the car will know that it must be approaching a corner.

Algorithm suggestions are welcome.
Ken

[Ioannis]

You do have oscillations don't you?

Well, the best way to avoid them is the PID suggested again earlier.

Give it a try and see the beauty of automatic control. You cannot do it other way.

Ioannis

[Kenjones1935]

I think this video does a pretty good job of showing the potential of this PIC controlled car.

)

With the three sensors this car might be able to negotiate a true maze.

What do you think?

Ken

[mackrackit]

Ken,

I think the PIC® drives better than you do

Looks great!!
That should really get the kids interested.

[Kenjones1935]

I need the correct PWM signals to be going to the wheels (Electronic Speed Control) and to the steering (servo) at all times.

I have programmed a PAUSE 500 to guarantee sufficient time for the car to back up out of trouble after hitting a wall.

Am I correct is thinking that since PAUSE 500 is not re-entrant my interrupt driven PWM pulses will not occur for that 1/2 second? The car will not back up as planned.

I need to turn my PAUSE into a time consuming DO LOOP. True??

Ken

[Kenjones1935]

Sorry, folks, I've been distracted trying to figure out how to "kit" this "educational tool" (toy). The Microchip PICKit2 board only costs $23.99. It has a small surface mount proto area. I do not understand how to make use of it. I need to mount my Zettler relay and my TI sn7407n plus a bunch of mini EMS connectors for the radio, the three SRF05's the steering servo and the electronic speed control. sssissshhh!

Today I eliminated the need for channel 3 on the radio system. Which is very good cost-wise. Regular Ready to Race hobby cars come with only two channels on their radios. Adding the third is quite expensive. The PIC can know it is inside a maze given input from three proximity sensors. If there is something close to the right and to the left then it must be in a maze. The first run of this new algorithm showed it flawed. The PIC thinks it is out of the maze when it comes to a corner.

Back to the drawing board. Any suggestions?
Ken

[mackrackit]

Is darkening the maze an option? Then maybe a light sensor would work??

[Kenjones1935]

My first attempts at toggling between PIC and Radio control automatically have not gone well. I figured that the PIC could know from the proximity sensors that it was inside the maze. There seems to be too many variables.

If I were to use a light sensor to distinguish, which sensor and at what wave length makes sense. Remember I am imagining the cars to be racing - going fast even in the maze. This set up would be in a middle school gymnasium - a basketball court maybe. If I could imagine making a maze out of BIG cardboard boxes with roofs I could use simple light detection. But I don't see how to make that elaborate a maze. Is there a light detector that does not see ordinary ambient indoor lighting, but does see some kind of special light source? Could I run a string of these light sources the length of the maze? Inversely I could run a string of these light sources outside the maze where the cars would see them.

Thanks for your attention.

Ken

[mackrackit]

I was thinking a "tunnel" type thing, but now I see that is not going to work. Maybe the light idea is not the way but still on that thought.

Have you seen a "line follower" setup? An IR sensor follows a black line...
What about having the floor in the maze black and an IR looking down on the front of the car?

Or...

A horizontal IR beam at the beginning of the maze and one at the end. Sees IR once the car is on auto, sees IR the second time and it is back on manual.

[Kenjones1935]

I've been having trouble testing this new feature. First, the car behaves as if there is noise in the SFR05 responses. I have no idea if that is truly the case. The car toggles when I don't think it should. AND when that happens it takes off on its own. It is way too fast to catch It dodges all around in inside my garage. When I used channel 3 I had an over ride. Not now. (even as I write I ask myself why not, for testing purposes, reactivate channel 3) Dumbo - of course!

I like the IR beam idea. How do I implement that? Do I purchase a heat lamp? Is that the IR wavelength that the sensors recognize?

Ken

[mackrackit]

Yup, gotta have an emergency stop button. Remember HAL ?

For the IR parts use something like the ones at the bottom right of this page.
http://www.rentron.com/PicBasic/RemoteControl.htm
Same basic IR stuff that is used in TV remotes.

And this page has several IR projects to look at that might get you going with the idea.
http://www.rentron.com/remote.htm

As always, keep us posted.

[rmteo]

You do have oscillations don't you?

Well, the best way to avoid them is the PID suggested again earlier.

Give it a try and see the beauty of automatic control. You cannot do it other way.

Ioannis

Good advice here.

[Kenjones1935]

How's this sound. Two 100 watt bulbs inside reflectors. One mounted close to the beginning of the maze and the other at the end of the maze. I think I could get a standard photocell to detect the difference between that light intensity and ambient room level. The rule for the PIC would be, "See the light, TOGGLE."

Here's the spec for the PHILMORE photocell 10807:

"A typical use is for switching on lighting after dark. These are also used in alarm systems, exposure meters, flame detectors, opto-couplers etc. This cell has a dark resistance of 5,000 ohms and 300 ohms in bright light (100 cds. or more)."

If this technique were used in my car an emergency TOGGLE device would be a powerful flashlight.

What do you think? I have the 10807's. I think I need to experiment. An old fashioned Triplett multimeter should to the trick.

On the old subject of oscillations. These were oscillations in the motion of the car. They were caused by my not correctly selecting the thresholds on the SRF05 proximity detectors. I felt I solved that.

The idea of a WHILE WEND loop is a good one. I sort of do that already. The PIC triggers the SRF05's many many times per second. My car continues to do one thing until the three echo pattern changes, then it does something else. If there is a bit of noise in one set of readings, it is smoothed over by the next set coming in a few milliseconds. I do not have an error signal.

When I first read Ioannis' PID suggestion I thought of a PID system based on position of the servo. My mistake. He is really suggesting that I devise an error signal to minimize. I gotta think more about that.

Ken

[mackrackit]

The photocell should work, not sending data, just a simple HIGH/LOW..

Just in case you do not have the link.
http://www.picbasic.co.uk/forum/showthread.php?t=5874