PBP projects for R/C models [Archive] - Page 2

Kenjones1935

- 8th April 2010, 21:47

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

- 14th April 2010, 02:28

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

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

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

http://www.youtube.com/watch?v=bx8KKDknAx0

Ken

Kenjones1935

- 14th April 2010, 04:18

rmteo

- 14th April 2010, 05:46

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

- 14th April 2010, 19:53

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

- 16th April 2010, 03:14

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

- 16th April 2010, 15:36

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

- 17th April 2010, 05:03

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

http://www.youtube.com/watch?v=KDUWyGh8eIo:)

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

What do you think?

Ken

mackrackit

- 17th April 2010, 07:23

Ken,

I think the PIC® drives better than you do :)

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

Kenjones1935

- 18th April 2010, 04:12

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

- 29th April 2010, 20:23

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

- 29th April 2010, 23:55

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

Kenjones1935

- 2nd May 2010, 01:01

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.:rolleyes:

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

- 2nd May 2010, 02:35

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

- 2nd May 2010, 02:48

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!:cool:

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

- 2nd May 2010, 03:08

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

- 2nd May 2010, 03:20

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

- 2nd May 2010, 20:40

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

- 2nd May 2010, 21:18

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

Kenjones1935

- 4th May 2010, 03:18

I'm not getting my analog voltage comparator act together.:confused::eek:

I want the teacher, at race time, to certify that each car will respond correctly to the bright lights at the beginning and end of the maze.
The photoresister R/C to PIC toggling threshold should be calibrated per car.

The PICkit2 comes with a built in pot attached to pin RA0. Each car while being exposed to the bright light could have its pot turned with a long handled screw driver (avoiding shadows) to the point that the car's control toggles.

This translates to a voltage comparison between the input of RA0 and RA1. The photoresister 10807 reduces its resistance in bright light from 5k down to near 500 ohms If I build a voltage divider with a 5k resistor to Vss = 5V and the 10807 to Gnd and attach it to RA1 will that do the trick? It would give the PIC a swing of about 2V not figuring the input impedance of the PIC.

I've got a some of questions.

First, does the above make sense?
Second, do any of you know some PBP code that does a similar comparison?
Three, I believe I will need to smooth out noise during the transition as the car comes into and leaves the bright light? How would you suggest I do that?

Ken

mackrackit

- 4th May 2010, 14:39

First, does the above make sense?Yes.

Second, do any of you know some PBP code that does a similar comparison?I do not have any code but here is how I might try setting it up.
First add a switch on the car and code for the switch at power-up. Also add a LED for calibration indicator.
If switch is HIGH then ADC_SETUP routine. The code will go here once and never loop back to it.
Inside the SET_UP routine have the drive wheels turned off and sub loop reading the ADC from the light and the "calibration" pot.
Have it coded so when the reading from the light and pot are equal with in a certain amount (exact will be difficult) the calibration LED come on.
Then when the calibration switch is turned off the code will go to EXIT_SETUP. This routine will save the ADC reading from the pot to EEPROM then goto the main program.
Now the main program will read the EEPROM to get the value to use for light checking. The reason for EEPROM writing is you will only have to "setup" once and not have to do the setup every time the car is turned on. Maze changes do another SET_UP.

Three, I believe I will need to smooth out noise during the transition as the car comes into and leaves the bright light? How would you suggest I do that?Turn to the students and say "SSHHH" :)

Are you meaning light noise? If so this is where the ADC needs to be with in a certain amount so a small range of "bright" light will do the triggering. This partwill take some experimentation for car speed and othe on site variables.

Kenjones1935

- 6th May 2010, 03:47

I took the car to a TV studio today. It was going to be on Access television. I brought the laptop computer and the USB connector. I forgot the battery charger. The car had not been charged for a couple of days. Big mistake.

At the beginning it did just as I thought I had told it, but then as time went on it crashed more, got stuck more. I chose not to do the TV shoot. It sort of worked, but not quite.

I think as the battery discharges, even with the 5volt voltage regulator in the electronic speed control box, everything degrades before it finally refuses to move. I know the DC wheel power motor uses lots of juice

Sound correct to you all?

Ken

mackrackit

- 6th May 2010, 03:58

Sounds correct to me. When the voltage drops below a certain point all kinds of strange things can happen. The PIC ® is probably running "OK" at 8Mhz, but the 5 volt peripherals are probably not happy.

malc-c

- 6th May 2010, 17:57

To be honest I would never use the same power pack to power the electronics. Even when using electric helicopters I would use an RC pack for the receiver, with the main flight pack used just for driving the main motor. 4 x 1.2v Nicads provides a decent supply for the electronics

Kenjones1935

- 6th May 2010, 21:48

I too initially designed with two battery packs. One for the servos and the other for the electronics. My problem is one of packaging. Getting a cheap kit that fits easily into a HPI Racing Touring Car Ready to Race package is way beyond my expertise. Why the HPI car? That is what I have. Also Ten80 Education

( Which I know as http://www.ten80eduction.com)

specializes in using radio control cars for curriculum and lesson plans supporting STEM in our schools. One of that company's sponsors is HPI Racing. I hope to get ten80 support. One battery is much easier to mount than two.

I took my car again for a run. It is using the "there is nothing within four feet of me, I must be under radio control" toggling algorithm. I liked the effect. It is important that the room have lots of room. Clearly a gymnasium fits that criteria. Adding the photoresistor system is more than I can deal with at this time.

Two projects are looming. 1. Get help and advice on packaging (surface mount prototyping). 2. Create a video story board then shoot a video showing what I have built, why I built it, how to modify the code and why I think middle school students will jump to learn.

I discovered a neat trick today. The studio has a small push cart with roller skate sized wheels. I put my car on the cart (back end facing me - it has no sonar sensor) and pushed it around the maze. I could easily see the reaction of the car to each position. It made very clear that the problems are speed, momentum and reaction time.

Ken

Kenjones1935

- 13th May 2010, 02:57

Today after watching my car behave very differently when actually running on the floor as compared with its wheels spinning freely on a pedestal I decided that I need to install the second battery pack and its 5volt regulator. Nuts, more micro-soldering.

Ken

Kenjones1935

- 23rd May 2010, 16:19

Please suggest your ideas on competitions that could be implemented with my PIC and/or RC controlled hobby level car. Right now all it does is go through a left turning maze. Programming for both right and left turns is the most obvious extension.

What if I added different sensors and maybe some kind of emitter. I am thinking of a game of tag. Somehow the rest of the cars in the group would need to know which car is "IT".

What fun could be had with a group of these cars?

Ken

Kenjones1935

- 27th May 2010, 17:51

I have installed a second battery pack -- four AA batteries now power the PIC and all the electronics except the radio receiver. The original 7.2 volt NiCad battery power only the servo, the electronic speed control and the radio receiver.

The inconsistent behavior in autonomous control may have been because of noise, but then it could be because of slow reaction time relative to speed travel. Not sure yet.

I need suggestions on how to prototype this package. There appears to be shops that offer short run PC cards. PCB-POOL advertises in the SERVO magazine. You all have any preferences?

Ken

mackrackit

- 27th May 2010, 18:05

I have used these folks.
http://www.expresspcb.com/
Only thing I do not like is you have to use there software. But very happy with the three boards for $51.00. Nice work and quick turn-around.

Kenjones1935

- 6th June 2010, 03:45

Mucho frustrations followed by some successes. The PC board proto challenge is beyond me for now. Created instead a car that toggles itself between radio and PIC control without using a third radio channel and negotiates a maze that includes both right and left turns.

The auto toggle is a function of the car being out in the clear - not in or too near the cardboard maze. The right and left turns were pretty obvious after numerous stupidities.

I hope to post a video next week.

Thanks again for all your support.;)

Ken

Kenjones1935

- 18th June 2010, 20:28

I think the code is pretty solid. Now the problem is response time, size of maze passageways and RC car speed. A fraction of a second does not seem very long when the car is up on blocks, but it is enough time at speed to crash into a far wall when it should have detected a turning opportunity and done its thing.

I think I need:
1. Techniques using PICBASIC Pro for recording data in memory that can be read back into my PC for analysis. How do I do this? I have not the faintest idea what app to use.:confused:

mackrackit

- 19th June 2010, 03:06

This is a tough one.

If the trouble is speed and timing then using more MCU cycles might make it worse.

You can look at writing data to the on-board EEPROM.
http://melabs.com/resources/samples/pbp/eeword.htm

ardhuru

- 19th June 2010, 05:59

I think I need:
1. Techniques using PICBASIC Pro for recording data in memory that can be read back into my PC for analysis. How do I do this? I have not the faintest idea what app to use.:confused:

This thread might help:

http://www.picbasic.co.uk/forum/archive/index.php/t-13317.html

Regards,

Anand

Kenjones1935

- 19th June 2010, 21:15

Thanks for your attention and replies.

I think the PIC is plenty fast enough. I think the SFR05's are responding quickly enough judging from their flashing LED's. My guesses are either SFR inconsistencies and/or weakness in my jury rigged PWM signal.

The servo and the speed control want PWM pulses at 50 per second. I have not been able to do that with my PIC. I get the pulse width correct, but I can not get the rep rate down to once each 20 millisec.

Ken

Kenjones1935

- 19th June 2010, 23:35

The PIC KIT2 programmer has, at the bottom, reference to EEPROM. It has addresses 00 - FF.

I think that if I use the PBP WRITE command at run time I can store data in the inchip EEPROM space. 00 to FF in size. I can then manually read this out with PIC KIT2 programmer.

Sound correct??:D

Ken

mackrackit

- 20th June 2010, 09:38

Sound correct??
Yup, that will work.

Kenjones1935

- 25th June 2010, 22:09

I need to be able to connect my PICkit 2 to three SRF05 sonar sensors. The easiest way would be to solder J or JR (or whatever - I do not know one connector from another) headers to the board.

I looked carefully at the connectors that came with my radio control car. The pin separation does not match the hole separations in my PICkit 2 forty four pin demo board. Do any of you know the name of the connector header - if it exists - that would solder directly into that row of holes along the sides of my proto card? They are definitely not 1/10 inch centers. I have no means to measure their separation accurately.

Ken

Byte_Butcher

- 25th June 2010, 23:23

They're on 2mm (0.079") centers.

Digikey has a whole variety of them. Here's one flavor with 12 pins, right angle.

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=S5802-12-ND

Steve

flipper_md

- 26th June 2010, 21:13

on the power topic, I've read that most current electric R/C plane systems uses a BEC to run all servos/receiver from the main battery pack(Mostly LiPo these days).
BEC usually have a safety function that will choke power to the motor, but keep servos alive in case that you are running out of juice.

Kenjones1935

- 3rd July 2010, 23:34

I'll catch you all up a bit.

I have changed tack.

I am trying to go from a hobby level car with PWM controls to a toy level car most of which have simple DC wheel and servo controls. The purpose is to reduce the cost of kitting for school students. In addition to reducing the cost, DC control of two wheel drive makes it easier to implement a sporty racing-like skid steering.

I purchased (at K-MART) two 1/10 scale toy cars on sale each for $25.95. Their original prices were $50. The 1/10 size gives me more room for adding microchip electronics. The wheels and the steering if driven simply by DC with reversing current are easily controlled using DPDT relays controlled via current drivers by my PIC .

WRONG! :o The steering servo contains both a DC motor and an angle measuring device which is read by the electronics that comes with the car. A total of six wires go to this servo. Where can I read how this works? Should I just go back to the store and buy 'proper' toy level cars? Your suggestions would be greatly appreciated.

Thank you thank you for the oscilloscope. Without it I would not have the faintest.

Ken

mackrackit

- 3rd July 2010, 23:44

A total of six wires go to this servo.
That sounds like a stepper.
A picture of the setup might help...

Kenjones1935

- 4th July 2010, 04:13

Toggling between autonomous control and radio control is much more complicated for the toy level car than for the hobby level car. Why? Toy level drives the steering servo and the wheel motor each with DC in both directions. This requires four wires. There is no common ground. Hobby level cars use pulse width modulation signals for these two jobs. Only two wires are required. The grounds are common.

Toggling between PIC and R/C in toy level requires switching eight wires - four from the radio receiver and four from the PIC. The same operation on PWM wires requires switching only two wires.

Hmmmmm...... That's a pretty good argument for sticking to the expensive machines.

Ken

Kenjones1935

- 5th July 2010, 20:30

I have some Radio Shack solderless prototyping boards. With 22 guage solid wire I can create a fairly robust kit. I need to connect ten signal wires from the PICkit 2 to the solderless board. The Digi-Key S5752-12-ND header might work. The question is whether 22 gauge solid wire will fit and stay in this device. If not #22, then what gauge will work? Or is there a crimp-on male connector that will do the job.

What did the Microchip engineers have in mind when they designed the PICkit 2 printed circuit board? Any ideas?

Ken

mackrackit

- 5th July 2010, 22:23

22 gauge will be snug and if you do your breadboarding like Darrel does it all should stay put.
http://www.picbasic.co.uk/forum/attachment.php?attachmentid=4592&d=1278267329

ScaleRobotics

- 5th July 2010, 22:29

What did the Microchip engineers have in mind when they designed the PICkit 2 printed circuit board? Any ideas?

A compact USB device that programs all their MCU's, using 5 to 6 connections?

But what do you mean Ken?

On a tangent, here is what they were thinking for the pickit3:

http://www.youtube.com/watch?v=3YUvlrVlNao&feature=watch_response

mackrackit

- 5th July 2010, 22:39

A compact USB device that programs all their MCU's, using 5 to 6 connections?
I think Ken was getting at the 44 pin dev board. It is kind of useless... Mine got the most use helping Ken get started. It is back to collecting dust.

Kenjones1935

- 5th July 2010, 22:49

This describes what I found when I took the "servo" apart. (I got it back together with much struggling so this is from memory.)

It has 2 wires that go to the motor and 4 wires that go to some kind of rotating position sensor. On a small board are 2 etched concentric circles which are in contact with a 4-pronged device mated to the spinning gear. I think 2 of
the 4 prongs touch the outer circle, the other two the inner circle.

Have any of you come across such a device? Any idea its purpose and how I control it. Other cheap cars just go bang bang into the steering motor with a little spring plus the caster effect to bring it back to neutral.

Ken

mackrackit

- 5th July 2010, 23:01

Now I remember seeing one of those.
It is a reversing/limit switch. The cheaper cars are either turn or no turn. Not much in between.

If I remember correctly...

Kenjones1935

- 5th July 2010, 23:10

22 gauge will be snug and if you do your breadboarding like Darrel does it all should stay put.
http://www.picbasic.co.uk/forum/atta...2&d=1278267329

My 16F887 is attached to a Microchip PC board. It is the PICkit #2. My problem is getting ten signal wires off that board an onto a solderless proto board like Darrel used. Are you all suggesting that I do the whole job on a solderless board? If I were to do that, where do I get the solderless header that fits my Microchip provided USB connector? I'm pretty sure my 44 pin square shaped PIC will not fit. I need the long rectangle shape.

Ken

mackrackit

- 5th July 2010, 23:19

I use these with bread boards and the PicKit2
http://www.allelectronics.com/make-a-store/item/SHR-40/HEADER-1-X-40-RIGHT-ANGLE//1.html

The long rectangular chips are what they call a PDIP package. Much easier to solder when you get to that point.

I would develop the project on a bread board with PDIPs and that might be the way to go with the kit also. It would low the students to experiment...

Kenjones1935

- 6th July 2010, 00:56

Looks like all I need to connect to a PDIP 16F887 on a solderless board are the six wires from the USB device and two .1uf caps between Vcc and Gnd. The rest of the Microchip PICkit 2 schematic I do not use. (Some LED's would be nice.) Don't forget two isolated batteries. One for the DC motors the other for the logic.

This is little considering the six Zettler relays, the SN7407, and a 5v regulator. Hmmmm

Does this seem correct to you?

Ken

Kenjones1935

- 6th July 2010, 01:02

Power, Ground, Trigger and Echo to/from three sonars. Interconnections with the radio receiver and the wires that go to the DC motors and/or the Electronic Speed Control.

If this could all be on one board and the board could fit inside a little car.....

Ken

mackrackit

- 6th July 2010, 01:18

You may also want to look at the 16F886. Same chip as far as programming goes, less I/Os smaller foot print, 28 pins. Same data sheet as the 887.

The same outfit with the headers has a 400 hole bread board that can snap together with others if you need more room.
http://www.allelectronics.com/make-a-store/category/105/Breadboards/1.html

Kenjones1935

- 6th July 2010, 02:18

Here is a proto board that will carry all my parts and then some. Each board has two rows of 62 pairs of bussed 0.1" centers pin holes.

http://www.circuitspecialists.com/prod.itml/icOid/6888

I need 20 paired pins for the forty pin 16F887, 48 paired pins for the 6 sixteen pin DPDT relays, 7 paired pins for the fourteen pin SN7407, 6 isolated pins for the USB device and three isolated pins for the 5v regulator.

The board is 6 and 1/2 by 3 and 1/8 inches. That fits fine on my 1/10 scale hobby level SPRINT (the belt up the middle driving the front wheels is a problem that can be overcome) and my toy level 1.10 and 1.12 scale toy cars.

Is that a plan, or what? :cool:

Ken

Kenjones1935

- 10th July 2010, 22:37

New unexpected problem.

I have not been able to find socket headers that are compatible with the solderless proto board technology. All the headers are designed for PC use. This makes it very difficult to connect my six pin 0.1" centers USB connector device. It also makes it difficult to connect the servo PWM three pin cord, the Electronic Speed Control three pin cord, and the connectors needed for the radio receiver three pin male headers.

I could cut and strip six 1/2" #22 lengths of solid #22 gauge wire and stick then into consecutive holes. The female connector would come in perpendicular to the board.
This is not as reliable as 90 degree square header stock, but what choice do I have?
Remember this is for middle school students.

Suggestions anyone?

ken

mackrackit

- 11th July 2010, 02:41

Are you saying the breadboard you have is not 0.1 centers?
Up in post 311 I gave a link to a place with headers with 0.1 centers.

Kenjones1935

- 11th July 2010, 18:59

The 90 degree headers do not have long enough stems. They do not reach to the springs in the proto board holes. I solved this by bending them straight, but I would rather have the connectors coming in horizontal.

BIG REAL PROBLEM!! My PBP 2.6 version DEFINE pulsin_max
command does nothing. I can see this from the speed at which the sonar LED's blink. I am using a PULSIN command to detect whether the radio transmitter is powered on. If no PWM signal comes in, the power is off and the PIC is on its own to guide the car. This is my new TOGGLE system, but it does not work. When power is off the LED's flash about once per second no matter what I set pulsin_max to be. When power is on they flash many times per second.

Any rumors around campus to which I am not privy?

Ken

Kenjones1935

- 11th July 2010, 19:30

pulsin_max does not cut short the time used by PULSIN? It makes PULSIN ignore everything that happens after pulsin_max duration but the next command in line is not implemented until PULSIN has gone through all its 65,535 ticks.

If this is the case, what can I do to detect within, say, 25 millisec something that happens every 20 millisec or not at all?

Ken

mackrackit

- 11th July 2010, 20:06

I think COUNT might work better in this case...

Those 90 degree headers should be long enough when the plastic that holds them together is slide close to the bend. Works for me that way.

Kenjones1935

- 11th July 2010, 22:53

COUNT is the solution. This is BIG. My target RC car is the HPI Sprint. In comes in a Ready To Run package for around $200 including a two channel radio system. I have been using channel three to make the TOGGLE between R/C and PIC control. This is an expensive variation. Now a plain vanilla RTR Sprint should do the job! THANK YOU.:D

Ken

mackrackit

- 11th July 2010, 23:18

COOOOOL!!!!!

I can not wait to see new videos.
:D

Kenjones1935

- 12th July 2010, 22:39

I have "16 BIT LANGUAGE TOOLS GETTING STARTED" DS70094E. My 16F887 is an 8 bit machine. What is the best way for me to learn ASM for my PIC? I have not been able to get MPLAB IDE v8.33 to work. Is that because I am dealing with an 8 bit PIC?

Ken

mackrackit

- 12th July 2010, 23:14

MPLAB should work with any PIC. What is it not doing?

Assembly???
Hang out here
http://www.piclist.com/techref/piclist/index.htm

Kenjones1935

- 13th July 2010, 14:00

I gave MPLAB IDE some .asm code created by MicroCode Studio. It claimed too many errors. That was many months ago. I'll try again.

Ken

mackrackit

- 13th July 2010, 14:22

In the Project drop down from the tool bar - select language toolsuit, select:
Microchip MPASM Toolsuite

That should then compile ASM generated by PBP.

Kenjones1935

- 13th July 2010, 15:58

That's the way I have been compiling.

When I cut and paste a .asm that was created by the compiler into the MPLAB IDE application window it refused to assemble. I think there are some idiosyncrasies that I need to learn.

Ken

mackrackit

- 13th July 2010, 16:03

Maybe the wrong PIC was selected?
Toolbar-Configure-Select device

Kenjones1935

- 13th July 2010, 16:34

I've built my first solderless proto using a 40 pin 16F887.

As far as I can tell I have duplicated the actions that up until now have worked. The PICKIT 2 Programmer "Check communication" says "PICKIT 2 found and connected" "PIC device found"

However when I click the Write button using the 40 pin PIC, the PICKIT 2 Programmer application says "Programming failed at program memory address LOCATION 0x000002"

Any ideas?

Ken

mackrackit

- 13th July 2010, 16:56

Some possible causes. Maybe...
Are both VDDs and VSSs connected?
Do you have capacitors across both VDDS and VSSs?

Kenjones1935

- 14th July 2010, 01:24

No sure what was wrong. Maybe a solderless connection was not tight.

Got a couple warning windows about voltage must be 4.5v.
Strange since the power is coming from my PC via the USB port. Then that went away. Got a couple of red "Code Protect" statements. Had to restart the application to get ride of them.

Twice in a row it loaded my .hex file successfully. Good!! Now to adding sonars, SN7404 and the DPDT relay.

Thanks for the support. It really helps!

Ken

Kenjones1935

- 22nd July 2010, 02:46

How do I learn exactly what the 16F887 does when given a HPWM PBP command? Seems to me the car's electronic speed control (and hence the car) reacts slower to PIC PWM signals than to radio control PWM commands.

I was wondering if throwing a LOW at the PWM output port might slow the car down quicker than just changing HPWM commands from 'forward' to 'reverse'.

Is this a potentially worthwhile path of inquiry? Something is slower than it should be and it is not the sensor trigger rate.

Ken

mackrackit

- 22nd July 2010, 07:24

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?:confused:

Ken
I wonder if something like this could be made to work for you?
http://www.picbasic.co.uk/forum/showthread.php?t=7393
or
http://www.picbasic.co.uk/forum/content.php?r=217-MIBAM-(Mirror-Imaged-Bit-Angle-Modulation)

ScaleRobotics

- 26th July 2010, 17:36

After reading about some of Bruce's cool projects with the 18F2431 series chips, I have been playing around with them for a little while. One thing that caught my eye is that they can do Power Control PWM as low as 19 hertz (while running at 40 mhz). Something you have to bring other chips OSC down to 0.5 mhz to do. This, and a few more of it's features, make it pretty nifty for creating PWM servo output. I mocked up a quick test, and have been able to do about 10bit PWM 1 to 2ms pulses at the proper 50 hertz spacing on 3 pins with the 18F2431. The larger chips of this series can do 4 pin PCPWM. I will post a little code once I get it cleaned up a bit.

Kenjones1935

- 28th July 2010, 02:42

I received a brand new HPI Racing Sprint car. This is the same model which I have been using. It is just the most recent version.

I am having a problem with the new Electronic Speed Control a SC-15. It has some kind of mind of its own. My old code which told my old car where to go is not working with this new ESC.

Do any of you have the contacts to get me the specs on this "SC-15 ESC WITH REVERSE SPORT CONTROL".

Does is have a PIC? Is it programmable? What are its design algorithms?

Ken

ScaleRobotics

- 28th July 2010, 18:42

The 18F2431 makes it slightly easier to perform servo PWM because it's PCPWM module can go down to 19 htz while maintaining fast OSC rates, unlike other PIC chips HPWM. Here is an example of using the PCPWM to output 3 servo signals. This specific example senses the pulses (up to 5 channels) by using the CCP1 capture pin. To get 5 channels into one pin for PW capture, channels 1, 3 and 5 are input using small signal diodes. Then, since this drops the signal down to under 3 volts, I used two 2n3904 transistors. One to boost up the voltage, and the other one to invert the signal back to normal. (It was all I had lying around). Somehow, you will need to boost your signal after the diodes for the CCP1 capture to sense the incoming pulses.

Note: Because the PCPWM was used, this will not work on any chip outside of the 18F2431 family.

;This only works on a 18F2431 family device with Power Control PWM (PCPWM)
;By Scale Robotics Inc.
; The input signal should look something like this:-
;
; |<------------------ 1 frame (~20mS) -------------->|
; |<1~2mS>
; ______ ______ ______ ______
; _______| |______| |______| |________________| |____
; gap ch1 ch2 ch3 ch4 ch5 sync gap ch1 etc
define OSC 40
asm
__CONFIG _CONFIG1H, _OSC_HSPLL_1H
__CONFIG _CONFIG2H, _WDTEN_OFF_2H & _WDPS_512_2H
__CONFIG _CONFIG4L, _LVP_OFF_4L
endasm
clear
ADCON0 = %00000000
ADCON1 = %00000000
portb=0
trisb = %11000000
trisc = %00000110
trisa = %00000000
DTCON = %00000101 'dead time for complimentary ouputs
PTCON0 = %00001101 '1:1 postscale, Fosc/4 1:64 prescale, Sincle Shot mode
PTPERL = 255 '
PTPERH = 251
PWMCON0 =%01010000 'PWM[5:0] ouputs enabled
PWMCON1 = 1 'updates enabled, overrides sync w/timebase
PTCON1 = %10000000 'PWM timebase is on, counts up
FLTCONFIG = %00000010 'disable fault A, cycle by cycle mode
CCP1CON = %00000101 'Capture mode; every rising edge

duty1 var word 'width of outgoing pulse1
duty2 var word 'duty values 625 to 1250 = 1 to 2 ms pulse (Center at 625)
duty3 var word
risetime1 var word 'Rise Time for incoming pulse1
risetime2 var word
risetime3 var word
falltime1 var word 'falltime for incoming pulse1
falltime2 var word
falltime3 var word
pulsewidth1 var word 'pulse width for incoming pulse1
pulsewidth2 var word
pulsewidth3 var word
pulsewidth4 var word
pulsewidth5 var word
pulseNumber var byte
pulseNumber = 1 'tells which pulse we are reading
CCP1CON.0 = 1
timerone var word
timerone = 60315 ;

INCLUDE "DT_INTS-18.bas" ; Base Interrupt System
ASM

INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler TMR5_INT, _PulseOut, ASM, yes
INT_Handler CCP1_INT, _PulseMeasure, ASM, yes
INT_Handler TMR0_INT, _TimeOut, ASM, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM

T1CON = %00110001 ;Timer1 used by CCP1 capture
T5CON = $01 ;used as pulseout timer
T0CON = %11000111 ; Prescaler = 8, TMR1ON

@ INT_ENABLE TMR5_INT ; Enable Timer 1 Interrupts
@ INT_ENABLE CCP1_INT ; Enable Capture Compare for pulse width measurement
@ INT_ENABLE TMR0_INT ; deadtime (sync gap) indicator for lull between pulses
Main:
pause 10
'do something to these values if you want to filter, center, etc
'Below we are just passing values through
duty1 = pulsewidth1 >>1 'send channel 1 out PCPWM on PortB.1
duty2 = pulsewidth3 >>1 'send channel 3 out PCPWM on PortB.3
duty3 = pulsewidth5 >>1 'send channel 5 out PCPWM on PortB.4
GOTO Main

'---[TMR5_INT - interrupt handler]------------------------------------------
PulseOut: 'set up pulse width values for pulseout and reset single shot bit
TMR5L = timerone.byte0
TMR5H = timerone.byte1
PDC0L = duty1.lowbyte
PDC0H = duty1.highbyte
PDC1L = duty2.lowbyte
PDC1H = duty2.highbyte
PDC2L = duty3.lowbyte
PDC2H = duty3.highbyte
PTCON1.7=1 'resets single shot PTEN bit
@ INT_RETURN

'---[CCP1_INT - interrupt handler]------------------------------------------
PulseMeasure:
if CCP1CON.0 = 1 then ; Check CCP1M0 for rising edge watch
select case pulseNumber
case 1
TMR0L = 0 'reset timeout timer0
TMR0H = 0
risetime1.lowbyte = CCPR1L
risetime1.highbyte = CCPR1H
case 2
TMR0L = 0 'reset timeout timer0
TMR0H = 0
risetime2.lowbyte = CCPR1L
risetime2.highbyte = CCPR1H
case 3
TMR0L = 0 'reset timeout timer0
TMR0H = 0
risetime3.lowbyte = CCPR1L
risetime3.highbyte = CCPR1H
End select
@ BCF CCP1CON, CCP1M0 ; Now capture the trailing edge
Else 'check for falling edge time
@ BSF CCP1CON, CCP1M0 ; Re-set for trailing edge capture
select case pulsenumber
case 1
falltime1.lowbyte = CCPR1L
falltime1.highbyte = CCPR1H
pulsewidth1 = falltime1 - risetime1
case 2
falltime2.lowbyte = CCPR1L
falltime2.highbyte = CCPR1H
pulsewidth2 = risetime2 - falltime1
pulsewidth3 = falltime2 - risetime2
case 3
falltime3.lowbyte = CCPR1L
falltime3.highbyte = CCPR1H
pulsewidth4 = risetime3 - falltime2
pulsewidth5 = falltime3 - risetime3
end select
pulsenumber = pulsenumber + 1 'get ready for next channel

endif
@ INT_RETURN
'---[TMR0_INT - interrupt handler]------------------------------------------
TimeOut:
pulsenumber = 1 'if pause between pulse in exceeds about 7 ms, get ready
'to receive pulse 1 (senses dead time between pulse bursts)
@ INT_RETURN
To see a similar project, but using SPWM, look here: http://www.picbasic.co.uk/forum/showthread.php?t=12657

Kenjones1935

- 29th July 2010, 02:47

Yes, the 18F2431 looks like a winner for my PWM construction. It is included in my PICkit2 programmer.
It comes in a 40 pin package. It would easily replace my 40 pin 16F887 on the solderless protoboard. To use it effectively I need to master ASM coding. I have not succeeded in cracking that nut.

Here is my latest stumbling block. I have an arrangement with some folks who are willing to contribute brand new HPI Racing Sprint cars to my project. I received my first new car last week. HPI has drastically changed the Electronic Speed Control. This is the package that translates incoming PWM signals (from the radio receiver or from my PIC) into outgoing DC current for the motor that drives the wheels. I am not doing well with the HPI WEB site getting technical information about this SC-15 WITH REVERSE SPORT CONTROL.

Ken

ScaleRobotics

- 29th July 2010, 03:15

Here is my latest stumbling block. I have an arrangement with some folks who are willing to contribute brand new HPI Racing Sprint cars to my project. I received my first new car last week. HPI has drastically changed the Electronic Speed Control. This is the package that translates incoming PWM signals (from the radio receiver or from my PIC) into outgoing DC current for the motor that drives the wheels. I am not doing well with the HPI WEB site getting technical information about this SC-15 WITH REVERSE SPORT CONTROL.

Hey Ken,

Congratulations on getting the donation! It is a great idea you have, and I am glad you have stuck with it. As for your newest stumbling block, what code are you currently using? You might be running into the same problem of not having a standard R/C output pulse going to the controller. And MIBAM will not work, because it is meant for lighting, and will confuse your speed controller even more.

All analog servos (not the newer digital ones) use a standard protocol. A pulse width from about 0.9mS to 2.1mS or so, pulsed every 20 mS. Since this controller does not say digital on it, I would bet that it is analog, and works the same as all the servos in my house. Since it has reverse, as well as forward, I would bet that somewhere in between .9mS and 1.1 mS is neutral. Less is probably reverse, and more is forward.

I don't think you need a manual for it. Just start feeding it some PWM that matches that protocol, and you will be good.

Assembly is a tough nut to crack. It's just one of those things, the more you use it, the more you learn. But one of the things I learned this week from the forum, was that I could have an instant ASM interrupt without using any ASM. No, I didn't know that when I wrote some similar code for the 12f683. So in my example above, I only used two lines of assembly code. a BSF and a BCF. (Bit set and bit clear). So you can have almost no nuts with this code, or you can change them to PBP code if they drive you ... um ..... nuts.

I think you already know this, but I just found the gif file, and I like it, so I'll post it here. - Walter

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=4651&d=1280369726

malc-c

- 29th July 2010, 08:58

All analog servos (not the newer digital ones) use a standard protocol. A pulse width from about 0.9mS to 1.1mS or so, pulsed every 20 mS.

I was always led to believe it was typically 1ms to 2ms with a 20ms frame rate this gave 1.5ms pw for centre stick, at least that's what I've always based my SSC type projects on.

Kenjones1935

- 29th July 2010, 14:50

I agree with both of you on the size, shape and frequency of standard PWM signals. I have been running my car (an older version of this same HPI Sprint) successfully for the last couple of months. With the exception of frequency my HPWM pulses agree with your specs. I found the correct HPWM commands by trial and error.

This new Transmitter, Receiver, ESC combo is different. Leaving out my PIC for the moment if I on the radio transmitter I give full forward (trigger full back) and suddenly go to full reverse (trigger full forward) the car goes from full forward to stop (neutral in the PWM sense) and stays there until I bring the trigger to neutral for at least two seconds. Then giving it full back will work fine.

Somewhere in the system is protection against slamming the DC motor with reversed polarities. That is good, but when I tried to emulate that system in my code it did not work.

Thank you sooo much for your support and interest. Oh, yes, the electronic speed control wheel driving system is not a classic servo. Steering is. Wheels used to be - in the day - but no longer.

Ken

ScaleRobotics

- 29th July 2010, 15:14

I was always led to believe it was typically 1ms to 2ms with a 20ms frame rate this gave 1.5ms pw for centre stick, at least that's what I've always based my SSC type projects on.

Edit: oops, yes I meant to say 2.1 as the highpoint, not 1.1. Thanks Malc!

Hey Malc,
Yeah, me too! As a basic rule it works. But then I built my first passthrough device, I built it for that range and it got discombobulated when the signals from my transmitter exceeded the 2 mS. My transmitter has endpoint adjustments, so it allows you to go beyond the 1 to 2 mS. Some transmitters will only give 1.1 to 1.9ms.

Check out the HiTech web site regarding the signals:

Q. What signal do servos require to operate? (http://www.hitecrcd.com/support/product-support/faqs/servos/general-servos/#)
A. All Hitec servos require a 3-4V peak to peak square wave pulse. Pulse duration is from 0.9ms to 2.1ms with 1.5ms as center. The pulse refreshes at 50Hz (20ms).

You are probably right, I just was not sure if a forward and reverse speed control would be centered at 1.5 mS. My planes don't have reverse.http://www.picbasic.co.uk/forum/images/icons/icon10.gif

ScaleRobotics

- 29th July 2010, 15:35

Leaving out my PIC for the moment if I on the radio transmitter I give full forward (trigger full back) and suddenly go to full reverse (trigger full forward) the car goes from full forward to stop (neutral in the PWM sense) and stays there until I bring the trigger to neutral for at least two seconds. Then giving it full back will work fine.

Somewhere in the system is protection against slamming the DC motor with reversed polarities. That is good, but when I tried to emulate that system in my code it did not work.
Ken
Well, that's a completely different problem than what I thought you had. Why not talk to your friends at the R/C store and find out if they know of any controllers that let you go reverse from full forward. If they do, sell the controllers you have on Ebay, and buy the ones you want with the money?

You might also be able to hack the speed controller if it is for a brushed motor. But you run the risk of breaking a $55 speed control. You could also build your own controller for a brushed motor, but easier to find one off the shelf that will do what you want, if it exists.

Kenjones1935

- 29th July 2010, 18:34

I have been successful in attracting some support for my project. Check out
http://www.ten80education.com (http://www.ten80education
.com)

They use HPI Sprint cars.
If I can design a 'simple' enough PIC kit to add to the standard HPI product, the schools might get a pretty good deal. My new car was a support gift cost me nothing.

Ken

malc-c

- 30th July 2010, 08:43

This new Transmitter, Receiver, ESC combo is different. Leaving out my PIC for the moment if I on the radio transmitter I give full forward (trigger full back) and suddenly go to full reverse (trigger full forward) the car goes from full forward to stop (neutral in the PWM sense) and stays there until I bring the trigger to neutral for at least two seconds. Then giving it full back will work fine.

Ken

Electronic braking system. - You might be able to go into the programming mode and disable this function.

malc-c

- 30th July 2010, 08:50

Electronic braking system. - You might be able to go into the programming mode and disable this function.

Uhmm maybe that's not an option. I can't see anything on programming the end points on this controller :(

Kenjones1935

- 5th August 2010, 21:28

OKAY,

I have discovered through the use of my oscilloscope that PAUSE stops the HPWM output pulses. In order to emulate the radio system I want to try giving the ESC two seconds worth of neutral PWM between switches back and forth between forward and reverse. This is a race car. It will not be going backwards very often, but it is necessary sometimes. Looks like I need to figure out how to set a two second interrupt. Hmmmm. NUTS!

Ken

ScaleRobotics

- 6th August 2010, 02:13

I have discovered through the use of my oscilloscope that PAUSE stops the HPWM output pulses.

Hey Ken, welcome back to town.

Do you mind posting some of your code for us to figure out what is going on? The HPWM command, or using the CCP hardware PWM with your own commands should both work independently of your code. I have a 2 second pause that is repeated, but HPWM keeps pumping out pulses the entire time. But if I repeatedly call HPWM and set it using PBP, it can give me some screwy results. Probably better setting the registers directly, like Bruce shows in this example: http://www.picbasic.co.uk/forum/showthread.php?t=9449&p=61478#post61478

What PIC hardware are you using?

Thanks,

Walter

Kenjones1935

- 6th August 2010, 03:29

Here is the first couple commands of my code. I deliberately start HPWM then PAUSE for four seconds. My oscilloscope shows a flat line for four seconds then springs in PWM action.

I just looked at it again. I am no longer as certain as I was. Once I get into my code it seems to behave as I expect. I'll get back to you all tomorrow.

Thanks, Ken

Kenjones1935

- 6th August 2010, 21:58

The outputs of PORTC.1 and PORTC.2 are high all the time.
Why? In other code snippets PAUSE seems to allow action to continue. I hope you guys see that I am being stupid.

' PORTC.0 'High is R/C. Low is PIC control
TRISC = %11110000

main:
low portc.0
gosub straightforward
pause 4000
goto main
end

StraightForward:
pwm 1,120,50
pwm 2,120,50
return

Kenjones1935

- 6th August 2010, 22:00

As soon as I typed "submit" I saw that I had left out the H in HPWM. Thank you sooo much!

Ken

ScaleRobotics

- 6th August 2010, 22:41

Glad to hear it. The bad news is that HPWM doesn't go down as low as 50 hertz, unless you use a really low osc speed. You have to go down to 0.5 mhz to get there. And, unfortunately you have to tell pbp that it is running at 4mhz. This will make a pause 2000 16 seconds. It can be compensated for, but a bit of a pain. And it limits you to 32 steps of speed. I think I talked about this back on post 199. Maybe that's why you tried to go back to PWM. But as you saw, PWM is effected by blocking commands, like pause.

http://www.picbasic.co.uk/forum/showthread.php?t=12039&p=85908#post85908

I don't have a 16F887, but I just ordered a sample, so I can help test some options for you.

Walter

Kenjones1935

- 6th August 2010, 23:04

First I used my 44 pin PIC (with no PICKIT 2 board) on a toy level car. Toy level means bang-bang control. It worked.

Now I am running a model level car with PWM control. I miss wired CCP1 and CCP2. Steering was going to the wheels. Driving was going to the steering servo.

I thought I had double checked this. Clearly my double checker was flawed. I shall rewire and report back.

Thank you for your patience.

Kenjones1935

- 7th August 2010, 02:30

Yup,

Now when it sees something in front it stops then goes backwards. :) And when nothing is in front it goes forward for all its worth. Such a difference getting the steering servo and the wheel electronic speed control signals actually going to the servo and the ESC.:o

Now to calibrate HPWM for this fancy ESC. It seems very similar, but not exactly like the old not-so-fancy ESC. There are still funny rules around switching from forward to reverse and visa verso.:)

Ken

Kenjones1935

- 7th August 2010, 03:30

Another 'minor' problem. The new HPI Sprint has the steering servo mechanically opposite my older car. With this car steering right is smaller PWM pulses. Steering left is larger.

Soooo Things are working as they used to. My problem now will be getting a reaction time that is reasonable given the speed of the car. I have not taken it to a gym or outside. When I hold a big cardboard in front of the car it does turn. Soon enough? We'll see... I can slow down the wheels, but this is supposed to be a race car.

Ken

Ken

Kenjones1935

- 9th August 2010, 03:04

It worked better before I went in and to get my video camera. However, you can get the idea from this clip. There are still some mysteries :confused: with the HPI's new Electronic Speed Control SC-15.

http://www.youtube.com/watch?v=4oFTzyMuSjA

Little by little....

Ken

Ioannis

- 9th August 2010, 14:10

I think the car is been autonomous enough and wants to escape now! Was very funny how it got away under the white car!

Keep up the good work Ken.

Ioannis

Kenjones1935

- 11th August 2010, 03:36

This afternoon I taped a two minute video in which my new HPI Sprint car ran autonomously around and around the inside of our garage. The radio transmitter was turned OFF during the whole episode. At no time in this piece did I interrupt the PIC control with the radio control. I was operating the video camera.

Go to:
http://www.youtube.com/watch?v=jI5JEeT_FDE

What do you think?

Ken:):)

mackrackit

- 11th August 2010, 03:44

Very nice!!!
Almost looks like it was "thinking" after it hit something.

Kenjones1935

- 14th August 2010, 18:45

If I have recorded the checksums how can I know which version of code is on my PIC?

The PIC KIT 2 programmer has a READ button. Does that read the contents of my program memory and display for me to see its checksum?

I have not figured out on-line debugging. Actually I have not figured out a great deal of stuff in this system.

Ken

ScaleRobotics

- 14th August 2010, 18:56

If I have recorded the checksums how can I know which version of code is on my PIC?

Yes, it will display the checksum after it reads the code from the PIC chip.

You could use the verify button. It will compare the file loaded onto the pickit from your computer to what it reads on the PIC chip. It will notify you of any differences.

mackrackit

- 14th August 2010, 20:54

Will not help for you old stuff...

Write a value to the EEPROM representing the version using DATA then all you have to do is read the EEPROM.

Kenjones1935

- 17th August 2010, 02:17

mackrackit

- 17th August 2010, 04:08

MCS is just a fancy text editor and PBP just turns the basic code into ASM so neither one will do a checksum on the hex.

DATA not changing the checksum?
Not sure about that one :(
Will look into it though.

ScaleRobotics

- 17th August 2010, 06:29

How do I get MicroCode Studio PIC BASIC PRO compiler to tell me the check sum. All I have found is to go to the PICKIT 2 Programmer and look what it calculates then go back to the compiler to put the check sum into the DATA command. Why did doing that not change the check sum? Is EEPROM not part of the calculation?
Ken

Hey Ken, the check sum doesn't care about the eeprom data area, just program memory. So any changes to DATA will not change the checksum. Just out of curiosity, why do you need to see checksum (other than finding what version is in your chip)? Seems like this should only happen once in a while.

Kenjones1935

- 17th August 2010, 14:21

I've got three cars: one older HPI Sprint model level, one brand new HPI Sprint model level, and one toy level. The two model levels work with PWM signals. The toy car requires DC current switching. Each has its own idiosyncrasies. My version control system sucks. My memory sucks. Checksums to differentiate just came to mind.

Ken

ScaleRobotics

- 17th August 2010, 15:12

My version control system sucks. My memory sucks.

Unfortunately, I can relate to that.

However, I did remember reading a version control system here, and I found it too! I never used it, so my version control still sucks. But you might find it a possible solution.

http://www.picbasic.co.uk/forum/showthread.php?t=2641

It still won't tell you what is in the car though :)

Kenjones1935

- 21st August 2010, 03:36

I wish to email my PBP code. I want the BOLD commands to remain BOLD as they do in Microcode Studio. I have a PC running XP. When I select, copy and paste the BOLDness disappears.
Any suggestions?
Ken

mackrackit

- 21st August 2010, 04:58

Use the Save As *.RTF option.

Kenjones1935

- 23rd August 2010, 04:02

In order to get someone or something interested in helping make my robocar available to school kids I need a better quality video. I have two HPI Racing Sprint cars.

I have access to an outdoor street hockey rink. Same size and shape as ice hockey only asphalt covered for in line skates. I'm going to see if I can race my cars. Both on the track at the same time hugging the right wall going around turning left. One lap. The probability of the sonars getting their echos interchanged is remote I hope.

They can go up to thirty mph. Real speed - not scaled speed. My PIC may not be able to react fast enough. I create PWM signals using HPWM. The robocar's reactions seem slower than my fingers on the trigger of the radio transmitter. This is going to be VERY interesting. You guys got any suggestions to add to the excitement?

Ken

Kenjones1935

- 23rd August 2010, 21:03

My first robocar includes a PICKIT 2 proto board. It has a built in potentiometer. I would like to use that pot to control my code's PWM signal from PORTC.0.

Presently I preset the constant FORWARD to a number between 115 and 123. That number is one of the arguments to my HPWM command for PORTC.0. If 123, the car goes very fast. If 115, the car creeps. I would like to make FORWARD a variable which is set within these limits on-the-fly as a result of the position of the pot.

This will force me to use ASM code which is good. This also forces me to think which can be a problem. I am not good SEARCHing this forum. Any pointers would be most welcome.
Ken

Kenjones1935

- 24th August 2010, 04:44

My first robocar includes a PICKIT 2 proto board. It has a built in potentiometer. I would like to use that pot to control my code's PWM signal from PORTC.0.
Ken

Here's my first shot. I compiled fine, but did not work at all. Assuming I got the PORTs and
registers correct, am I on the correct path? I am trying to break the 256 possible values of
the Pot reading down to seven that make sense to the Electronic Speed control.

pot PORTA.0,127,Potread
if Potread < 36 then
Forward = 112
endif
if Potread => 36 and Potread < 73 then
Forward = 113
endif
if Potread => 73 and Potread < 109 then
Forward = 114
endif
if Potread =>109 and Potread < 146 then
Forward = 115
endif
if Potread => 146 and Potread < 182 then
Forward = 116
endif
if Potread => 182 and Potread < 219 then
Forward = 117
endif
if Potread => 219 then
Forward = 118
endif
write 2,word Forward
write 4,word Potread

mackrackit

- 24th August 2010, 09:12

You would be better off using ADC to read the pot and SELECT CASE for the comparisons.

Kenjones1935

- 25th August 2010, 00:04

Here is my latest on reading the PICKIT2 pot and selecting PWM pulse width.

Checkpot:
adcin PORTA.0, Potread
write 4, word Potread
select case Potread
case Potread < 36
Forward = 112
case Potread => 36 and Potread < 73
Forward = 113
case Potread => 73 and Potread < 109
Forward = 114
case Potread =>109 and Potread < 146
Forward = 115
case Potread => 146 and Potread < 182
Forward = 116
case Potread => 182 and Potread < 219
Forward = 117
case Potread => 219
Forward = 118
end select
write 2, word Forward

The word Potread follows the pot turns perfectly from 10 00 to FF 00 in addresses 4 and 5.
The word Forward is always 70 00 in addresses 2 and 3. SELECT CASE always chooses CASE 1
above. ie the CASE where Potread is deemed less than 36. Any ideas? I think I have problems
with using WORDs when I am only interested in BYTEs, but I am not allowed to declare a BYTE
sized VAR. I suspect my selecting "left justified" is confusing it, but I do not see in what manner.

Ideas?? Ken

ScaleRobotics

- 25th August 2010, 02:37

Since it doesn't have to be exact, you could simplify your code.

Instead of:

Checkpot:
adcin PORTA.0, Potread
write 4, word Potread
select case Potread
case Potread < 36
Forward = 112
case Potread => 36 and Potread < 73
Forward = 113
case Potread => 73 and Potread < 109
Forward = 114
case Potread =>109 and Potread < 146
Forward = 115
case Potread => 146 and Potread < 182
Forward = 116
case Potread => 182 and Potread < 219
Forward = 117
case Potread => 219
Forward = 118
end select
write 2, word Forward
something like:
8 bit ADC:

Checkpot:
adcin PORTA.0, Potread
Potread = Potread/37
Forward = Potread+112

10 bit ADC:

Checkpot:
adcin PORTA.0, Potread
Forward = Potread/147 + 112

Kenjones1935

- 25th August 2010, 04:16

I chose your first suggestion:
Potread = Potread/37
Forward = Potread+112

It works beautifully. :D Tomorrow I shall make a video of my car on blocks in its "going forward" state with me making it go faster and slower by twisting the pot's knob. At least I intend to do that tomorrow.

THANK YOU!!!

Kenjones1935

- 2nd September 2010, 16:03

Sorry for the delay. I have been discouraged. The new HPI Sprint R/C car has an ESC-15 that thinks for itself. The HPI manufacturing/sales organization refuses to give me the behavioral specs. This is a STEM educational project. Not a by guess and by golly exercise in inductive reasoning.

One solution is to make an ESC on my solderless proto board. (Complete with cooling fins?)

My PIC (like the R/C receiver) makes appropriate PWM digital signals. The car wheels want appropriate PWM bi-directional current pulses. Have any of you seen a design I could copy?

Ken

Kenjones1935

- 3rd September 2010, 03:33

My PIC already produces quality PWM signal streams. Why can't I put this signal directly to a MOSFET circuit thereby producing a current switched wheel motor driving signal. My pic could use two HPWM's for the wheels. One for forward, the other for backward. It could steer the correct MOSFET signal with a third 'direction' output. Only trouble is I do not know how to detail design what I just typed.

Ken

ScaleRobotics

- 3rd September 2010, 05:54

Usually an H bridge is used for forward and reverse. It is pretty much what you describe, only using two more fets. Microchip has an application note about one here: http://ww1.microchip.com/downloads/en/AppNotes/00893a.pdf . It shows a nice diagram of the different states of forward and reverse on page 3.

In your post, I don't understand the " It could steer the correct MOSFET signal with a third 'direction' output." part though.... Don't you steer with a servo?

Kenjones1935

- 3rd September 2010, 21:53

When I wrote, "It could steer the correct MOSFET signal with a third 'direction' output."
I was thinking of simplifying the speed control functionality by separating out the FORWARD and BACKWARD aspect. HPWM can easily create a PWM signal between one and two millisec. A second digital HIGH and LOW could dictate rotation direction. I've seen reference to something like this, but I did not think it through.

Ken

Kenjones1935

- 7th September 2010, 03:24

I think I have the ESC nailed. I have a procedure for powering up that seems to give predictable robocar behavior.

Do you all have some creative ideas for things to do with this little car. Right now it follows a wall counter clockwise looking down at a leisurely pace. High speed introduces response time problems. :o Two sonar proximity sensors can be placed looking anywhere from the car and a pot controls the top forward speed the half forward speed.

I can show you all the code if you like. It is crude, but it works.

Ken

mackrackit

- 7th September 2010, 09:04

You say looking down. Do you also have it looking for drop offs? Along that line maybe something like a seeing eye dog/bot?

Kenjones1935

- 7th September 2010, 14:54

There is a new car out that parallel parks itself. My car could do that if I put one sonar on the back bumper.

It could also detect motion if it were standing still. A relay race? I just thought of that. I like it....

Ken

Kenjones1935

- 26th September 2010, 03:02

The model level car is too expensive for middle school use. It seems to be too fast for my level of software and SF05 sonar sensing. I have found a commercially available electronic speed control that has no 'smarts', but that's $50 added cost to the package.

The 1/10 size gives me more room under the plastic car body for my solderless protokit plus an extra 4 AA battery package. This $50 toy car comes with a 7.2 volt rechargeable battery. There is still a mystery. How can the PIC detect that the RC transmitter is turned on? Presently turning on the transmitter with the trigger in a particular position stops the car in its tracks, but does not toggle to RC control.

All this sounds soo good. But.... go look at:mad:

http://www.youtube.com/watch?v=oQqVkef0DTs

It is not good. This has been frustrating. You can hear the car spin its wheels on the cement floor. I've not been able to get it to follow the wall. It turns too far when making what should be small adjustments. Could be my code. I'll share it if you want.

On the plus side this car cost $50 retail. It is light and very robust - as you can see. All my solderless kit easily fit underneath the plastic shell with holes for the sonar sensors.

As of right now It does seem that the model level car with the POT to adjust the speed is the way to go.

Ken

Ioannis

- 27th September 2010, 09:34

Hi Ken.

I would like to ask, is the steering servos linear in control or just like ON-OFF switch?

I mean can you control the amount of turn, or the angle that the car will turn? Or is it full right, full left and center?

Also I cannot see if you really have speed control over the car. It seems that it accelerates fully in every direction.

Anyway, sure it is very nervous in reactions. I will repeat my self and tell you to have a look at PID control. It is the only way to have smooth control of the speed and steering.

Ioannis

Kenjones1935

- 27th September 2010, 16:24

Yes, the difference between the 1/10 scale TOY cars and MODEL cars is proportional controls and $150. The original idea came from the URL below. In it is a 1/12 scale TOY car (cost about $25). He took out the radio control electronics completely.

http://letsmakerobots.com/node/696

I put my toy car up on blocks and used a large cardboard to simulate the presence of a wall on its right. I could not, even with me in control of the distance, get the car to steer straight ahead. Using my model level car it was easy. My code gives a window of 12 to 24 inches from the right hand wall for which the car should steer straight.

Ken

Kenjones1935

- 29th September 2010, 04:03

I think the model level car is getting close to understandable. Not so the toy. This video shows one under control, not the other.

http://www.youtube.com/watch?v=Emsf46WpctI

One more step for the model level - get it more up to speed. This needs a bigger room. I've got that, but it needs cleaning. The toy level needs my understanding of the servo that drives the steering. Presently the car does not easily go straight hugging the wall. It just goes left or right. I will clean up and post my code.

Ken

Ioannis

- 29th September 2010, 11:46

It looks like your sensors are not detecting long distance and that is why it hits the walls.

Can you make a test program and see with RS232 or LCD the distance it actually measures? And then use both sensors as it may interefere each other.

Ioannis

Kenjones1935

- 30th September 2010, 03:32

I took the car to an old gymnasium this morning. I had adjusted the "frontfree" distance from four feet to five feet.
That's the proximity response from the front sonars which triggers the code to turn sharply left.
I left the potentiometer at the speed that was too fast for my garage. In the gym it negotiated the corners fine, but could not hug the wall.

I may need to recalibrate the steering, but more likely I need to restructure the wall hugging code.

Here's a link to the code I am presently running. The only difference between the toy car code and the model car code is the servo and DC motor driving commands. For the model code I use the HPWM PicBasic command. For the toy level I command certain pins to be HIGH or LOW.

http://www.employees.org/~kjones/HPI2_left_SyRen02.htm

Ken

Kenjones1935

- 2nd October 2010, 00:57

I made a video today of my model level robocar going about 1/2 speed inside an old deserted gymnasium. It largely works. I am now pretty much at the end of my road. YOUR IDEAS???

1. The kit fits underneath the body skin. It is reasonably robust.
2. The kit costs less than $80. The model car costs ~$200 assuming we do not have to purchase the HPI ESC-15 and we can swap in the SyRen ESC.
3. PICBASIC code is not too difficult for middle school students.
4. A potentiometer controls the speed. No need to go back to the USB port for that adjustment.
5. Pulse Width Modulation is necessary ( and understandable).
6. Each car needs PWM calibration of its steering.
7. The characteristics of sound (sonar) must be understood.
8. This is a good example of 'how things work' in the 21str Century

http://video.yahoo.com/watch/8324343/22230090

Ken

mackrackit

- 2nd October 2010, 01:46

Do not forget the cost of PBP.

Kenjones1935

- 2nd October 2010, 16:59

Yes, the PBP is not freeware. But from the point of view of a middle school club or group project it is a 'one of'.

I did not anticipate the complexity of upping the speed of this car and only asking it to follow the wall. This has been a good lesson for me.;)

Ken

mackrackit

- 2nd October 2010, 20:45

Yes, the PBP is not freeware. But from the point of view of a middle school club or group project it is a 'one of'.
You may want to read the back cover of your manual.

Something like this came up before, no group license.
That is why I get kids started with some basic ASM and/or what they can do with the demo version.

Ioannis

- 2nd October 2010, 21:20

Hmm, have a look at the videos at YouTube about line followers with and without PID control of the robot.

Behaviour of non PID is similar to your nervous car. The same robot with PID control slides smooth on the line (or in your case follow the wall in a steady distance).

Why not give it a try?

Here is the same robot with and without.

http://members.jcom.home.ne.jp/felm/ltc_p.mpg
http://members.jcom.home.ne.jp/felm/ltc_pd.mpg

Ioannis

Kenjones1935

- 2nd October 2010, 21:29

I just read the above mentioned Software License.

I'd rather use LOGO. But that does not seem forthcoming. Hmmm...

Ken

mackrackit

- 2nd October 2010, 21:33

I would contact MeLabs, maybe they will work a deal with you.

Kenjones1935

- 2nd October 2010, 21:54

Of course you are correct. Classic robotics is error signal driven.

My problem with PID is my lack of confidence. I do not know the capabilities and limitations of PBP and the 16F887. I have not figured out how to debug the stuff in real time on the bench etc. I have been lazy regarding the 300+ page PIC Owners Manual. I never mastered MPLAB.

Can you point me to some simple PID code in a familiar language - C or C++ (complete with libraries) for example.

Ken

Kenjones1935

- 3rd October 2010, 00:53

My wall following code is state machine code. I am going forward. The right facing sonar tells me a distance. I compare that to constants and to the previous measurement. Given where I am relative to a line parallel to the wall and whether I am getting closer to or farther from the wall, I steer right, left or straight.

Here's the code:

keepgoingforward: '----Compare to right wall
IF oldrangeright = rangeright THEN
HPWM 1,Straight,50
ENDIF

IF rangeright > outertrack THEN
HPWM 1,HalfRight,50
ENDIF

IF rangeright < desiredtrack AND oldrangeright < rangeright THEN
HPWM 1,Straight,50
ENDIF

IF rangeright > desiredtrack AND oldrangeright > rangeright THEN
HPWM 1,Straight,50
ENDIF

IF rangeright > desiredtrack AND oldrangeright < rangeright THEN
HPWM 1,HalfRight,50
ENDIF

IF rangeright < desiredtrack AND oldrangeright > rangeright THEN
HPWM 1,HalfLeft,50
ENDIF

GOTO main

Given my limitations this seemed the easiest path to take.

Ken

Ioannis

- 3rd October 2010, 21:50

No need to go far away from your PBP lanquage.

Have a look at Henrik's routines here http://www.picbasic.co.uk/forum/showthread.php?p=54846

It is not easy as A-B-C but also not too hard to follow. May the difficult part would be to tune the PID parameters.

Ioannis

Kenjones1935

- 4th October 2010, 00:23

I sort of understand using PID to set a POT value via a DC motor. The feedback is stable and static.

My robocar needs to stay in a path while moving. The feed back - change in the echo response from the wall - is dynamic and is a function of the car's speed and direction. The PIC is plenty fast. The sonar response is not "dynamic" in this sense. My response delay problem is in the physical reality of the steering mechanism and the physics of car motion.

Another issue may be that the HPWM signal is not "really" to radio control spec. It is not a 50Hz pulse of width varying between 1msec and 2msec with 256 gradations. The frequency is more than 50 per second. The arguments I use for HPWM I arrived at empirically. I do not have an appropriate oscilloscope to accurately measure what I am producing.

I need a better understanding of what you are suggesting.

Ken

Ioannis

- 4th October 2010, 07:48

In your case the "pot" signal would be the US Sensors signal. The result of the PID controller would be the steering signal. If the whole system is tuned correclty, the steering would be much more smooth.

You do not have to mess with the speed of the car at this point. May be later if all are working as expected.

As for the HPWM, why not use the DT-INTs with a 20ms timer to have it within specs? With 4MHz clock and TMR1 you can produce an interrupt every 20ms (50Hz) and then update the value to PWM module.

Ioannis

Kenjones1935

- 4th October 2010, 20:57

I need to do some studying - PBP - ASM - 16F887.

My original purpose for this project was to devise a kit and a collection of lesson plans that might hook middle school students into the thinking and documentation processes common to Science Technology Engineering Math.

I hoped to give them an insight into, "How things work" this, the 21st, Century.

Thanks again. I have my work cut out for me.

Ken

mackrackit

- 4th October 2010, 22:32

Just some thoughts...
You seem to be very close with your code, the kids are going to love it.

Have you seen this?
http://www.picbasic.co.uk/forum/content.php?r=171-LCD-serial-backpacks
What if you did something similar, a "car backpack" ?
Then the parameters that the kids need/want to change to make it their own could be done with the demo version of PBP.
http://melabs.com/pbpdemo.htm
They would not have to learn the whole car code but learn enough to get started.

Kenjones1935

- 5th October 2010, 01:44

I do not know the term "back pack".

Are suggesting that all the students' cars contain standard PBP code (one license). To experiment with sonar calibration and steering reaction time relative to changes in car velocity and 'race' course size each student has a set of definitions that can be downloaded via MPLAB or PIC kit 2 programmer?

I have learned how to write data in the EEPROM section to be read whenever I hit the READ button. That's all the interaction I have mastered.

Ken

mackrackit

- 5th October 2010, 03:16

With a serial LCD backpack the chip that runs the LCD is "attached" to the LCD. Parallel LCDs use at least six pins from a MCU so a lot of times the project MCU does not have enough spare pins.
Use one pin from the project MCU to send data to the LCD MCU serially.

Are suggesting that all the students' cars contain standard PBP code (one license).
Yes, base code written by you.

To experiment with sonar calibration and steering reaction time relative to changes in car velocity and 'race' course size each student has a set of definitions that can be downloaded via MPLAB or PIC kit 2 programmer?
Yes again, these commands will be downloaded to a second MCU that communicates with the main MCU that you programmed.

The students will be able to use the free demo version and not be able to "mess up" the main chip.

Kenjones1935

- 5th October 2010, 03:49

If I can down load to another PIC why can I not download to my main PIC? I have no problems with pin count. I am not using a PIC KIT. I am using a naked 44 pin 16F887 and a solderless prototype board.

It would seem that part of my code could react to some signal from the USB serial port and download parameters into itself. I have not the faintest idea how, however.

Another thought: My code is written so that all the constants are defined in the preamble before "main:". A class of eight to ten students, I imagine, would be broken into four or five teams. They could change parameter values using a text editor, burn into a thumb drive (or use the school's internal network), cut and paste the data into their PBP code on the licensed machine, compile, plug the USB connector into their car, and download using PICKIT programmer. WRONG? Against the rules?

I never got MPLAB to work as a ASM compiler and chip programmer.

Ken

Ioannis

- 5th October 2010, 08:57

Ken,

1. Why are you bothering with assembly? Do you need it?

2. If you have to work on one licensed PBP, then do this. Connect an LCD on the PIC (I think you have plenty of pins) and 2-3 buttons and let he students change parameters with a menu driven software on the PIC. Then the LCD can be disconnected and leave the PIC running with new parameters.

3. To program a chip you need a programmer. Which one is your favorit?

Ioannis

mackrackit

- 5th October 2010, 09:00

Sorry Ken, I did not mean to confuse things.

I was trying to find a way for the kids to be able to work on a portion of the code with out having to use one machine (PC) to do it. Sounds like you have a work around for that.

MPLAB should do ASM with a standard install. The language may need to be set under the projects tab.

Kenjones1935

- 5th October 2010, 20:10

A couple of things:

1. Part of STEM at middle school level is "How things work". Computers including PIC's are "digital" - 1's and 0's. Each step away from pure machine language hides this basic fact. That physical phenomena like sound and light can be represented by 1's and 0's is my point. What is analog? What is digital? These are not part of this project, but it shows where I am thinking. (What is an echo and how can its response time be characterized in binary. What is hexadecimal?)

My PIC is on a prototype board inside the plastic body of a radio control car. This car body has holes for the two sonars, the six lead connector to which the USB connects, and for screw driver access to the speed controlling potentiometer.

Velocity is of the essence. Speed is the hook. That and the model level RC car's miniaturization of automobile mechanics. Turn over a model level RC car. Get in a grease pit and look up at a modern car.

The 1997 Cadillac Deville has 13 or more computers on board depending on which options in contains. Imagine the 2010 version. I think the 2010 Lexus car can back itself into a parallel parking spot. HOW DO THINGS WORK?

Ken

Kenjones1935

- 6th October 2010, 16:28

ScaleRobotics

- 6th October 2010, 16:41

Is there a freeware version of C available for the 16F887? Is there a library available?

Is there a freeware version of C available for another more sophisticated PIC? I think I see something in the "MPLAB C18 C" reference in the MPASM Assembler HELP GUI. Is there a PICKIT that carries a PIC for which there is an available C package?

Ken

I've never used any of the Hitech compilers, but there is Hitech C Lite version:

pic10-16 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en542849

And for more power full chips..... But for your project, I don't see why you would need anything more than a PIC18, or PicBasic for that matter.

PIC32 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en542866

Then, there is alway StickOS, which I think would be great for your kids starting out to learn how to control a MCU in basic, with no cost for development tools. Only problem is you can't (as far as I can tell) do anything else while you are sending a servo a signal. But might be interesting as another tool, or to talk to a main (backpack like) chip. Easier to learn than PicBasic.

http://www.cpustick.com/

mackrackit

- 6th October 2010, 16:47

Not C...
I have been wanting to try this
http://www.crownhill.co.uk/level3.php?cat=270&sec=1
http://www.myamicus.co.uk/content.php?117-Documents

cncmachineguy

- 6th October 2010, 16:59

Great find Dave, and if I read correctly, still makes use of PBP:)

mackrackit

- 6th October 2010, 17:05

Great find Dave, and if I read correctly, still makes use of PBP:)
Or this
http://www.myamicus.co.uk/content.php?245-Free-AMICUS18-Compiler
FREE!!!

Kenjones1935

- 6th October 2010, 18:33

scalerobotics wrote:

Only problem is you can't (as far as I can tell) do anything else while you are sending a servo a signal.

That's OKAY. Right now all I do is:

LOW trigright
HIGH trigright
HIGH trigright
HIGH trigright
LOW trigright
PULSIN echoright,1,rangeright 'measures the range in 10uS steps
PAUSE 10 'Wait for ringing to stop - read SF05 spec.

This seems to work flawlessly.

Ken

ScaleRobotics

- 6th October 2010, 19:12

Here is some more info about StickOS with some youtube videos by the guy the wrote it. Pretty cool stuff.

http://www.picbasic.co.uk/forum/showthread.php?t=13221&p=89397#post89397

Kenjones1935

- 6th October 2010, 19:14

http://www.cpustick.com says in its 2nd paragraph:

Additionally, when coupled with an optional Freescale MC13201 ZigFlea™ Wireless Transceiver, the MCU may be remotely controlled by another MCU, via a telnet/rlogin-like interface, eliminating the need for a direct connection to the host computer altogether. Also, BASIC programs may trivially remotely access variables on other MCUs, enabling the use of “remote pin variables” or other forms of inter-MCU communication.
Do you think I could get the robocars to communicate with each other using this? This could add greatly to the number and types of games or competitions we could devise. All this with 8K of program memory? Really?

Ken

ScaleRobotics

- 6th October 2010, 19:27

I don't know how far the zigflea can transmit and receive. But StickOS makes it pretty easy to connect devices that control each other. The first and I think the second video talk about hooking the remote zigflea up.

Here one piece of hardware you could use:
http://www.sparkfun.com/commerce/product_info.php?products_id=9645

And pretty soon the ZigFlea should be available for it:
http://overtone-labs.ning.com/forum/topics/zigflea-for-cui32

I don't know how much room you are left with with StickOs, but you need to get up to PIC32MX4 to use it. The chip has 512K programmable memory and 32K ram.

Kenjones1935

- 6th October 2010, 22:47

My cars use the same solderless protoboard as CPUstick uses here:

http://dev.emcelettronica.com/files/u4/article__html_m16d2111d.jpg

On the tail end I have velcro'd the RC radio receiver. There is plenty of room inside the car's outer body to add a horizontal zigflea if I can rig the connection as 0.1" centers.

I do not understand the above package. How about I start with this from EMCelectronica? It looks like it will plug into my protoboard and not give me stuff I do not need. At ~50EUR it is not inexpensive. Do you think I could put the thing together myself as I have done with the 16F887?

http://store.emcelettronica.com/images/cpustick_stickos.JPG

Ken

ScaleRobotics

- 6th October 2010, 23:14

EMCelectronica's price is ok, but their shipping really gets you. The CPUStick is 49 Euros, but shipping is 52 Euros ... ouch! Of course, it could be their store is set up wrong, and shipping wouldn't really be that expensive.

Here is one that fits your breadboard better than the other Sparkfun device:
http://www.sparkfun.com/commerce/product_info.php?products_id=8971

I have trouble with some 44 pin devices, so I am a little scared of soldering one of these big guys. I would use an off the shelf product for testing, then if it looks like it would do the job, you could have some boards made and try some soldering.

Kenjones1935

- 7th October 2010, 02:37

Thanks for the tip. The board looks OKAY, but only if I can solder pins into those holes and plug the thing into a solderless proto board. Of course some of the pins across the bottom would not have matching holes.

Oh, I see. The picture of the red board in your "http://www.sparkfun.com/commerce/pro...oducts_id=8971" is the same as the picture of the green board in my previous posting. True? Do you think? The price there is OKAY if shipping is reasonable.

Ken

mackrackit

- 7th October 2010, 02:46

There is a link on Sparkfun's web site going here
http://www.schmalzhaus.com/UBW32/

ScaleRobotics

- 7th October 2010, 02:57

Yes, these are the same devices. 0.1" on the spacing. They are made for breadboards. More about them here:
http://www.schmalzhaus.com/UBW32/

4814

Kenjones1935

- 7th October 2010, 03:17

What else do I need? I am confused but very impressed by the young man in the video. I'll get the ZIGflea later.

Ken

ScaleRobotics

- 7th October 2010, 03:44

What else do I need? I am confused but very impressed by the young man in the video. I'll get the ZIGflea later.

Yes, me too!

That should be all you need. However, this one does not come with StickOS installed. But you can use your PicKit2 to install StickOS firmware into it. And, by doing that, you will get the latest 1.80 version. You will need to download a windows driver from this page CPUStick.inf : http://www.cpustick.com/downloads.htm

But with that, and hyper terminal, you can start writing some code. Oh, and you won't get a manual either, so you will have to print one.

Walter

Ioannis

- 7th October 2010, 09:43

Hi Ken. I do not see why you should leave PBP and start another similar language and your project all over again.

If you do need RF communication between nodes maybe a Zigbee modules or RF transceivers can give you a good solution without almost a line of code.

Look at Digi modules (Zigbee or not, does not matter) for out of he box communication. Other brands also exist, many I can say.

Ioannis

ScaleRobotics

- 7th October 2010, 14:26

I do not see why you should leave PBP and start another similar language and your project all over again.

I wouldn't normally suggest it, as PBP can do just about anything. But here is why I think it might be a good idea in this case.

Configs are confusing for adults, I would hate to frustrate middle school students. This would keep them from having to worry about those.

PBP kind of expects you to read and understand the data sheet. StickOS would just require them to get read the device pinout. They could just start with the data sheets for their sensors, and not be overwhelmed by a 200 to 500 page data sheet.

They would not have to worry about setting ADCONx, trisx, cmconx etc...

With StickOS, they can just say:

10 dim pot as pin an5 for analog input
20 print "potentiometer= ",pot
Now here is some PBP code that does a similar function:

Define ADC_BITS 10 ' Set number of bits in result
Define ADC_CLOCK 3 ' Set clock source (3=rc)
Define ADC_SAMPLEUS 50 ' Set sampling time in uS

adval Var Word ' Create adval to store result

TRISA = %11111111 ' Set PORTA to all input
ADCON1 = %10000010 ' Set PORTA analog and right justify result

mainloop:
ADCIN 0, adval ' Read channel 0 to adval
serout2 PORTC.6,396,["Value: ",DEC adval,13,10] ' Display value
Pause 100 ' Wait .1 second
Goto mainloop ' Do it forever

EndAnd pretty high up there in my opinion is the cost. I know the school my son goes to has trouble buying pencils and paper. They would pretty much need everything donated to be able to do it. I think Ken said the cars were $80, this CpuStick is about $40. The PBP software is $250. So the cost per unit is $120 with StickOS vs $370 for PBP. That's over three times the cost. So, for the same cost of having 30 students share 10 PBP units (one kid does the work, while the other two watch), they could have one for each kid in the class.

Kenjones1935

- 7th October 2010, 16:14

There is already an educational oriented company, www.Ten80Education.com, which uses model level 1/10 scale radio control cars. They focus on automobile related engineering, toe-in, tire friction, gearing, power usage, damping, suspension. The car they use, the HPI Sprint, costs about $200 retail. Coincidentally I chose this same car for my project. I hope to integrate my PIC car into their curriculum.

It is the add on cost for my project that must be controlled. The sonars cost $28 each. It is really too bad that the PBP cost is just for a one PC license.

Big question?? What kind of games could our robocars play if they could talk to each other over zigFLEA?

Ken

Kenjones1935

- 7th October 2010, 16:32

I use the model level car because its steering and wheel drive is based on proportional PWM signaling. This I need for the wall following (at speed) trick.

The much cheaper ~ $50 ~ 1/10 scale toy level car has bang-bang steering that motor control. If that is all we need for the learning game, then the total cost comes way down. These cars are FAST.

Ken

Ioannis

- 7th October 2010, 18:48

These cars are FAST.

Yeah, but with very little control on the steering. Like you described it as bang bang (to the walls)...

The fuse settings, or settings in general may be solved by an include file made by Ken and students all have to do is just ... include it.

So they are left with the main body of the software. Which comparing to stickOS is a little more difficult. But you have interrupts and much faster execution time...

About the cost, well, OK. 250 is much money, but good things cost... :(

Ioannis

cncmachineguy

- 7th October 2010, 19:06

I have been folowing this thread. I have a question about the steering: I get it's bang bang, but what actuates it? is it a spring returned solinoid or a motor? I am thinking there should be a way to pulse the steering to simulate proportinate control. Does it really go full left or right with just 1 frame of command?

Also, as Dave suggested, can you create it so the demo version could be used? Maybe write some subroutines to "include" so all the power of PBP isn't required.

Then if some of the students are really intrested and want to go further, they can be pointed to PBP for their parents to purchase? As a parent, I would gladly buy a copy for my kid(s) if they were to show me they actually wanted to play with it. It would be far better than an x-box orother such stuff.

Kenjones1935

- 8th October 2010, 02:27

The 1/10 toy level car has a spring loaded servo for steering.

The steering servo and the DC motor for the wheels are driven by + - 7.2volts. I have four coil driven DPDT relays doing this job. They are not fast, but they are robust and reliable.

Today I am thinking about teaching the teachers. I need to come up with lesson plan #1. I am imagining kitting some of my cars then asking the teachers to implement "HELLO WORLD" (whatever that is for one of my RC car PIC systems.)

Question for you all.
What would be a HELLO WORLD for a 1/10 toy level PIC'd car?

Ken

mackrackit

- 8th October 2010, 04:47

Question for you all.
What would be a HELLO WORLD for a 1/10 toy level PIC'd car?
Maybe one of the things you did for a Hello World?
Go to the end of a hall, turn around and come back.

Kenjones1935

- 8th October 2010, 22:43

I am considering doing a teach-the-teachers gig. The attendees would get Professional Development points. They should be allowed to take home their kitted cars.

The least expensive RC toy cars are about $25 retail. The most expensive thing in my present kits are the sonar sensors. What can I sense for less money?

Ken

Kenjones1935

- 8th October 2010, 23:02

Could a 'Nicera' IR Detector designed, "especially to detect body heat" enable my toy level cars to swarm together playing follow the human?

Imagine a teach-the-teacher class in a gymnasium where the HELLO WORLD application makes the students' cars follow the teacher as he or she tries to out wit it. (The teacher must be wearing a bikini while the students would all be dressed in their warmest winter finery.)

My 'All Electronics' catalog has IR DETECTOR for $3.90 each. Would this work? How sensitive are these things?

Ken

mackrackit

- 9th October 2010, 00:01

A light sensor would probably be the cheapest and easiest.
But the bikini thhhing is interesting... :p

rmteo

- 9th October 2010, 00:27

How about something like this to get kids interested in microcontrollers?

http://www.youtube.com/watch?v=ZkK9zUM0Jlw

Kenjones1935

- 9th October 2010, 01:42

That seems the best so far. I have some light sensors.

The teacher has an open 150watt incandescent bulb and an extension cord. Hmmmm....

Try again,

The teacher has a portable roadside emergency light. He or she runs around the gym, the toy cars follow. Maybe the gym lights need to be dimmed.

The fact that TOY cars have bang-bang controls ought not to inhibit the PIC control code.

I like it. Why won't it work?

Ken

Ioannis

- 9th October 2010, 10:30

What is this thing americans have about this fish?

Maybe the culture is different, but I really cannot understand it.

Anyway as a project has fun!

Ioannis

mackrackit

- 9th October 2010, 10:46

What is this thing americans have about this fish?
I do not understand "fish".

Ioannis

- 9th October 2010, 11:43

Oooh well, I did it I guess!

I was watching another thread and answered this instead off. The other had a video with a talking fish....

Sorry!

Ioannis

mackrackit

- 9th October 2010, 15:03

Oooh well, I did it I guess!

I was watching another thread and answered this instead off. The other had a video with a talking fish....

Sorry!

Ioannis
I do not get the talking fish craze either.
But Sponge Bob is kinda funny at times :p

Kenjones1935

- 11th October 2010, 18:34

The New York Times published this article last weekend about a car made by Google that can drive itself.

http://www.nytimes.com/2010/10/10/science/10google.html

Kenjones1935

- 12th October 2010, 03:05

I received two 32bit Whackers today.
Can I attach them to my PICkit 2 Programmer? :cool:

Will the following get me started?

http://www.schmalzhaus.com/UBW32/

New project. 1/10 scale toy car bang-bang controls. Follow the bright light code. Three PHILMORE 10807 photo cells sticking out the top where the taxi sign belongs aimed - depending on the10807's reception pattern - forward, leftish and rightish. (I image 45 to 60 degrees from straight ahead.)

If the car can see the light at all, then it can follow it. If the car can not see the light it must turn a 360 until it finds it.

I see this as the HELLO WORLD of a teach-the-teacher robocar professional development seminar. Maybe I'll use the new Whacker because it has embedded development code. Maybe the PIC16F887.

Your thoughts?

Ken

ScaleRobotics

- 12th October 2010, 08:20

I received two 32bit Whackers today.
Can I attach them to my PICkit 2 Programmer? :cool:

Yes, jumper J5 will accept your PicKit2, so you can program the device. You should only have to do this about once. All other upgrades of firmware can be handled though the StickOS, using the USB cable.

Will the following get me started?

http://www.schmalzhaus.com/UBW32/
I hadn't noticed before, but it looks like it is preloaded with some other "language". I think you are better off with StickOS though. So I would dowload it from here: http://www.cpustick.com/downloads/StickOS.UBW32.F512L.v1.80c.elf.hex and load it into the UBW32 with your PicKit2.

And follow the StickOS documentation, located here: http://www.cpustick.com/downloads/stickos.v1.80.2p.pdf

All above located on this site: http://www.cpustick.com/downloads.htm

Kenjones1935

- 12th October 2010, 21:52

scalerobotics, I thought that you suggested that J5 will work with the PICKIT USB connector.

I can not find J5 on the board. I can find J6 but not J5. I downloaded the .pdf file which is a picture of the board. It is sooo messy that I can not find J5 on it either.

HELP.....

KEn

Kenjones1935

- 12th October 2010, 21:58

J5 is the tail end of the board...

Hmmm.

KEn

Kenjones1935

- 12th October 2010, 23:04

My PICkit2 Programmer makes the blue LED glow. When I ask for a READ it presents me with a GUI that claims voltage error and the LED goes out.

Is there a similar document to the MICROCHIP explanation of the PICkit 2 hardware?

The documentation for this PIC32 chip is 631 pages. That is more than the 500 pages of documentation referenced by the young guy in the video.

What now, coaches?

Ken

Kenjones1935

- 12th October 2010, 23:59

The six pin USB connector that I am using is called a PICkit2.

Are you all saying that you use that connector, but then use MPLAB IDE programmer for to talk to the PIC32 Whacker? I assumed you were using the PICkit2 Programmer.

Confusion reigns.

Ken

Kenjones1935

- 13th October 2010, 01:35

I rediscovered in PICkit2 Programmer the DEVICE FAMILY pull down. There is an entry for the PIC32MX460. I selected that. Low and behold....

Ain't life grande.
Ken

Kenjones1935

- 13th October 2010, 02:58

CPUStick Basic sounds good. Let me guess at what I must do to get it.

1. Establish the connection between my PICkit2 Programmer and my new PIC32 Whacker.
2. Download from http://www.cpustick.com/downloads.htm one of the StickOS HEX images. Which image is the correct one for my PIC32?
3. Load this .hex image into my Whacker board FLASH using the PICkitr2 programmer.

My observation (from a READ command) is that the 512K of FLASH is blank. This surprised me because I thought the PIC32 Whacker came with embedded software.

Am I guessing correctly?

Ken

ScaleRobotics

- 13th October 2010, 03:09

Low and behold....
Ain't life grande.

Hey Ken,

Sorry I couldn't answer earlier. Are you all sorted out, or are there still questions? I think you may have answered yourself on all the above. But just in case:

Since I pointed you to a hex file, you will not need anything except your PicKit2 to load it into your UBW32. Sounds like you found the J5. Really I don't know where it is either, I just saw it clear as day on the schematic. You would think it might be labeled. I have played a bit with the CUI32, but not the UBW32. The CUI32 is very clearly marked for each pin. Sounds like that may not be the case with the UBW32.

Too bad it is not silk screened. That would have been helpful. I assume you are looking at this. Which could be a lot clearer. http://www.sparkfun.com/datasheets/DevTools/PIC/UBW32_MX460_v262.pdf

Are you able to upload the .hex firmware into the device with the Pickit2?

ScaleRobotics

- 13th October 2010, 03:15

Kenjones1935

- 13th October 2010, 03:58

My browser insists on displaying your 'download' .hex file as if it were .txt.

I captured the SOURCE file and wrote it as a .hex file.

I have not looked at an actual .hex file in ages. Did I do the right thing?
Ken

ScaleRobotics

- 13th October 2010, 04:02

That may work as well, but I would right click, and save link as..... You should get to keep it in its hex format. Although it might be called xx.hex.txt . You can just delete the .txt if this is the case.

ScaleRobotics

- 13th October 2010, 19:40

Just for fun, here is a quad copter that does some pretty amazing stunts. I am fond of the one with velcro. I guess it helps if you have your speakers on. It doesn't sounds quite autonomous. The 20 cameras are static in the room.

Sorry Ken, I just thought it was really cool. These students are older. (And they appear to have a much bigger budget!)

http://www.youtube.com/watch?v=MvRTALJp8DM&feature=player_embedded

And through moving hoops

http://www.youtube.com/watch?v=geqip_0Vjec&feature=player_embedded

Kenjones1935

- 13th October 2010, 22:12

I WROTE my .hex file into the PIC32. It did not object too much. Now what? Small addresses in the FLASH remained 'FF'. Here's a shot of the transition.

1D0069C0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
1D0069D0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
1D0069E0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
1D0069F0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
1D006A00 0F401A8E 00000000 0F4073A0 00000000
1D006A10 1000FFFF 00000000 27BDFFE8 AFBF0010
1D006A20 40046800 0F402166 00000000 8FBF0010
1D006A30 03E00008 27BD0018 27BDFFD8 AFBF0020
1D006A40 AFB3001C AFB20018 AFB10014 AFB00010
1D006A50 3C0204C4 3451B400 0F4073EA 24130005
1D006A60 00409021 24030040 3C02BF88 AC432004
1D006A70 02201821 00008021 3C02FE36 34453C80

Now What? Does it dance and sing? Do I connect a hyperterminal via an old fashioned USB cable to the provided USB connector? Do I push the RESET button and the PROGRAM button? Any ideas?

I'm in a bit of a rush. I'll look at your videos later this evening.

Ken

ScaleRobotics

- 13th October 2010, 22:41

Ok, so now we plug the usb cord into the computer, and see what happens. If you have windows 7, there is a .inf file to download first. It's LED's may dance and sing, but you may have to configure that, to let it know where the heartbeat LED is. If you don't have windows 7, and it is not recognized when you plug it in, you might need to download the FTDrivers at http://www.ftdichip.com/FTDrivers.htm

Check out page 13 of the manual. In your computer, goto the Device Manager screen and see what port gets added to your computer. Should be an extra USB Serial Port (comx). Use hyperterminal or similar program to connect to comx.

You should get a nice welcome message like on page 14 or so of the manual.

Kenjones1935

- 14th October 2010, 03:43

Kenjones1935

- 14th October 2010, 03:46

My PICkit2 seems to communicate successfully to the BITWhacker board. Can it act as a terminal per StickOS expectations?

Ken:confused:

Kenjones1935

- 14th October 2010, 03:55

OKAY, I found the UART tool. What speed? I picked 9600 and get no response. I am not sure that I am supposed to get a response. I do not trust the .hex file completely.

I find the StickOS Basic User's Guide V1.80 to be a bit ahead of my level.

Ken

ScaleRobotics

- 14th October 2010, 04:05

My Hyperterminal only gives me COM1, COM3 TCP/IP or dial-a- number access. I see no USB capability. Do I need to buy a COM3 to USB adapter or some kind of driver which fixes my hyperterminal? I did not expect this.

Ken

The StickOS creates a serial port emulated by USB. What happens when you plug the usb cord from the UBW32 to the computer? You should hear a da ding, and see something like "new hardware detected" blah blah. And in your computer under the device manager, under ports, you should see an extra serial port show up. You should then see which com port it is numbered.

You can't use your Pickit2 for com port connection. It needs to be the mini-usb connector on the UBW32 to the computer's usb port. If your hyperterminal can't select the port number for your UBW32, then, like the manual says, you can download something like Tera Term from http://www.logmett.com

But are you seeing a port get added. You should either see it configure new hardware, or not recognize the hardware. You need to see something.

Kenjones1935

- 14th October 2010, 04:29

My Device Manager sees no PORTs change whether or not the USB is plugged in.

I do not trust the StickOS .hex file that I have. My browser would not download it per a usual (say .pdf) file. The browser insisted on displaying it as if it were html text. I could try ftp, but I am sure StickOS would ask for a username and password. All I know for sure is that the little blue POWER LED comes on when I click on the power tab in PICkit2. Other than that all is dead.

Gotta go to bed. Tomorrow progress. Sorry about all this. I am just not getting started.

Ken

ScaleRobotics

- 14th October 2010, 04:56

Not a problem Ken, this is definitely the hardest part. And the manual doesn't really pull it all together for me either. Once you have a connection, you almost don't have to worry about those parts again though.

Here is the hex file you need. I have it in a zip file attached. It also has the driver you need. You must install the driver into your computer. Right click the driver, and select install. Then hopefully when you plug the USB cord from the UBW to the computer, you hopefully will see something happen.

We will get it going, or die trying. Hopefully the former.

Kenjones1935

- 14th October 2010, 15:46

Thank you scalerobotics!

The .hex file you sent compares exactly to the one I used. At least each displayed using 'notepad' are identical. The .inf file you sent enticed WINDOWS XP PRO into displaying a GUI warning me against installing it as it had not passed the WINDOWS LOGO test! Do you think I should ignore the warning?

Ken

ScaleRobotics

- 14th October 2010, 15:51

Yes, ignore the warning. That is a default if Windows doesn't know what the file is.

Kenjones1935

- 14th October 2010, 15:58

scalerobotics:

I was hoping I would find in my MicroCode Studio Target Processor pull down menu a reference to the PIC32 that we are using. Nope! Do they sell an appropriate BASIC compiler?

Ken

ScaleRobotics

- 14th October 2010, 16:53

scalerobotics:

I was hoping I would find in my MicroCode Studio Target Processor pull down menu a reference to the PIC32 that we are using. Nope! Do they sell an appropriate BASIC compiler?

Ken

No, they do not. I think you are limited to C, assembly, or StickOS with the 32 bit devices. I thought you were going to try StickOS though? If so, you really don't need to learn too much about the chip. StickOS does most of background stuff for you.

rmteo

- 14th October 2010, 16:54

AFAIK, no one makes a BASIC compiler for the PIC32 (or any other 32-bit MCU for that matter). Your best bet is to go with C which is pretty the de-facto language (not a lot more difficult to learn/use but far more powerful/flexible/reliable).

ScaleRobotics

- 14th October 2010, 17:09

Your best bet is to go with C which is pretty the de-facto language (not a lot more difficult to learn/use but far more powerful/flexible/reliable).

In my opinion, C would be a lot harder for the middle school students to learn. C isn't very readable if you ask me.

For one you have to teach them
{why all the
}
{darn brackets
}
{are all over the place}

Then why the main code is void, but works.

I think StickOS is a bit easier for them for their first intro to micro controllers. But that may be because I don't understand why the brackets are all over the place.

Kenjones1935

- 14th October 2010, 17:16

The .hex file does not load. It says that MAXIMUM must be greater than or equal to zero. In fact it is -7xx or so. Here's the error printout.

************** Exception Text **************
System.ArgumentOutOfRangeException: Value of '-749' is not valid for 'Maximum'. 'Maximum' must be greater than or equal to 0.
Parameter name: Maximum
at System.Windows.Forms.ProgressBar.set_Maximum(Int32 value)
at PICkit2V2.FormPICkit2.ResetStatusBar(Int32 maxValue)
at PICkit2V2.PIC32MXFunctions.P32Write(Boolean verifyWrite, Boolean codeProtect)
at PICkit2V2.FormPICkit2.deviceWrite()
at PICkit2V2.FormPICkit2.writeDevice(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventAr gs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.O nMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.W ndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Kenjones1935

- 14th October 2010, 17:31

I can read the embedded .hex file using READ from the PICkit2. It appears to be all in place save one byte at the very end, byte 'c5'.

I do not understand why I need to attach a USB cable to the PIC32 card when the UART tool in PICkit2 looks like it is supposed to do the same thing. Do I need to push some of the buttons (PROG, RESET, USER) to get this thing started?

KEn

ScaleRobotics

- 14th October 2010, 17:57

I do not understand why I need to attach a USB cable to the PIC32 card when the UART tool in PICkit2 looks like it is supposed to do the same thing. Do I need to push some of the buttons (PROG, RESET, USER) to get this thing started?

I can get this far here, but I do not have one to program, so I can't go to the next step. Can you get to this point, and then your errors come when you try to program it?

4831

I am not sure if the warning is something to worry about or not. But right now you are having so many other errors, let's now worry about my warning yet.

You might be able to use the PicKit2 as your command-line transport. StickOS does allow either usb or serial command-line transports. If that is working for you, then very well. But it sounds like it is not. I have hooked up to a PIC32 with serial on different hardware. But I have never tried it through a Pickit2. The USB is the preferred method, and might give us a clearer indication if we are on the right track.

What did you try to do just prior to getting all those error messages?
1. Did the Pickit ide automatically select the right pic32 device, or did you select it manally?

2. Then did you hit the write button to get all the errors?

I have a pic32 device, so I will try loading it with the latest firmware as well, and see what happens. I might have to try it tonight, as I am late for work already!

Walter

ScaleRobotics

- 14th October 2010, 18:22

For what it's worth, on my Explorer 16, with a PIC32MX360F512L mpu:
It accepts the hex file (different one of course) from my Pickit2.
I can get a command line interface with my serial port (this chip does not have usb on it).
When I try to connect command line interface with my PicKit2, I get almost no response. I do get a square box at some baud rates, but that is about it.

Not a very good test, since there are a lot of differences, but it might be better to stick with USB for now.

Kenjones1935

- 15th October 2010, 01:55

scalerobotics - Mine looks just like yours!!

4832

Kenjones1935

- 15th October 2010, 01:59

mine is C0D3
yours is C15A

Weird!

Ken

Kenjones1935

- 15th October 2010, 02:04

That came after I hit the WRITE button. I was asking it to load that .hex file. It seems to load mostly correctly, but comes up with that funny error.

Ken

ScaleRobotics

- 15th October 2010, 02:44

Are you sure your pickit is plugged in right because it should be verifying the I'd. Mine was verifying air, so that's why mine has that waring

Kenjones1935

- 15th October 2010, 03:22

The BIT Whacker schematic shows the connections from the 4 pin USB port [UBUS and USBID] to be different than the connections from 5 pins into J6 [PGB,PGC and RB2]. When "Writing Device PROGRAM FLASH and BOOT FLASH" it just sits there with the little red BUSY light flashing on the PICkit2 connector. Forever.....

I tried to use the USB port. Both to load the .hex file and to communicate. No success of any kind. Notta.

At least PICkit2 through J6 illuminates the blue POWER LED.
And apparently embeds the EEPROM.

I tried loading HELLO WORLD.hex. No luck at all. Same error message but no success loading EEPROM.

I do not know what to do. I can write fine in C. But I have no idea where or how to start. The only communication I get with the BITWhacker is with my PICkit2 USB connector.

I am getting discouraged. The only reason for leaving the original 16F887 was the cost of multiple PBP licenses. I really don't need the 32bit power just to move my robocar.

Ken

rmteo

- 15th October 2010, 03:47

I am getting discouraged. The only reason for leaving the original 16F887 was the cost of multiple PBP licenses. I really don't need the 32bit power just to move my robocar.

Ken

Take a look at this mikroBasic PRO for PIC (http://www.mikroe.com/eng/products/view/9/mikrobasic-pro-for-pic/)
You can download a fully functional FREE demo version (and all relevant documentation) of the software. The only limitation is that the compiler output is limited to 2,000 words of generated PIC code - you code will probably fit within this limitation so any number of students can use the compiler legally for free. Over 415 PIC microcontrollers are supported (PIC12, PIC16 and PIC18). There is a also a C compiler available which I highly recommend over BASIC to get your students started on the right track from the get go.

http://www.mikroe.com/img/compilers/mikrobasic/pro/pic/gallery/compiler_ide_01.png

ScaleRobotics

- 15th October 2010, 04:14

The BIT Whacker schematic shows the connections from the 4 pin USB port [UBUS and USBID] to be different than the connections from 5 pins into J6 [PGB,PGC and RB2].

I think you are sticking your Pickit in the wrong port.

I know they are not spelled out as nice as the schematic, but, your pickit goes on J5 (same one I mentioned earlier). Later, after programming, you can try to plug in the usb host cable. The other 5 pin spots on the board are for USB.

4833

Here is where it goes. Should be a lot happier now...:

4834

Kenjones1935

- 16th October 2010, 01:39

I think my PICkit2 is correctly connected. I may have typo'd J5 and/or J6. Here's what I have been doing.

48434844

If I attach the USB and the PICkit2 I get the blue POWER light. My Hyperteminal does seem to see the PIC. If I eliminate ASCII echo and I type 'hello' I do get 'hello' on my Hyperterminal GUI. That is GOOD. Trouble is I disconnected the PICkit2 and reconnected and HELLO no longer appears.

I did not connect PICkit2 pin6. That is used as an input to the "LOGIC TOOL".. Everything seems normal except for that error message (about maximum). It seems to download the .hex correctly. But nothing happens. ie the EEPROM embedded code does not to do anything visible. If there were a LED blinking example I could try debugging. The HELLO WORLD would not embed.

Kenjones1935

- 16th October 2010, 01:51

Note, below. I get what I type. I think 'echo' is turned off. I think I am connected. Still no StickOS, however.

4845

Ken

Kenjones1935

- 16th October 2010, 01:57

Take a look at this mikroBasic PRO for PIC (http://www.mikroe.com/eng/products/view/9/mikrobasic-pro-for-pic/)
You can download a fully functional FREE demo version (and all relevant documentation) of the software. The only limitation is that the compiler output is limited to 2,000 words of generated PIC code - you code will probably fit within this limitation so any number of students can use the compiler legally for free. Over 415 PIC microcontrollers are supported (PIC12, PIC16 and PIC18). There is a also a C compiler available which I highly recommend over BASIC to get your students started on the right track from the get go.

http://www.mikroe.com/img/compilers/mikrobasic/pro/pic/gallery/compiler_ide_01.png

rmteo, you have a good point. I have not yet used 2000 words in my PBP programs with the wall racing robocars. My guess is that using photo cells will be no more expensive code-wise.

Thank you for the link.

Ken

Kenjones1935

- 16th October 2010, 02:01

UART's echo was ON.

Ken

rmteo

- 16th October 2010, 04:01

You may be interested in this.

http://www.youtube.com/watch?v=M-7C7TIYJ8I

ScaleRobotics

- 16th October 2010, 04:47

Ken, I am sorry. I gave you the wrong firmware file. That one was meant for a UBW32 with HID Bootloader which apparently came with the UBw32 before we wrote over it.

Soooooooooo

Here is what I can only believe to be the right file. If this does not work, we will have to ask for higher help.

I wish I had the same hardware here, and would not have led you astray.

Here is the file:

Kenjones1935

- 16th October 2010, 15:15

In the world of Hi-Tech I always purchase a second one - just in case.

If I were to switch, what do you suggest be my actions?

Ken

ScaleRobotics

- 16th October 2010, 15:52

In the world of Hi-Tech I always purchase a second one - just in case.

If I were to switch, what do you suggest be my actions?

Ken
That's right, I sort of forgot about the second one...
But it does not sound like you tried the firmware I just sent you. As one last try, I would have you stick with the one were working on, and try the firmware I just sent in the previous reply.

But your right, if that does not work:
Switch to the untouched one. Download the microchip driver here: http://www.sparkfun.com/datasheets/DevTools/PIC/UBW32inf.zip and install it into your PC. And only plug the usb cable into it. See if you get a "new hardware detected" message.

Run the HID Bootloader executable from microchip http://www.cpustick.com/downloads/HIDBootLoader.exe , and see if it can find your UBW32. Then select the first firmware I sent you. This one: StickOS for Microchip PIC32MX4-F512L UBW32 Board Bootloader (http://www.cpustick.com/downloads/StickOS.UBW32.F512L.v1.80c.elf.hex) (v1.80) (.HEX, UBW32 HID bootloader image) with the long name. Let the microchip bootloader try to load the firmware into the untouched one (not even using your PicKit2).

Let me know how it goes.

Kenjones1935

- 16th October 2010, 19:07

I have four USB ports on the back and two on the front of my PC. How do I know into which physical port to plug the cable?

How does HyperTerminal know?

Ken

ScaleRobotics

- 16th October 2010, 19:18

I have four USB ports on the back and two on the front of my PC. How do I know into which physical port to plug the cable?

How does HyperTerminal know?

Ken
I have had equipment not get recognized when it was plugged into the front, so I would try the back.

Then, is any new hardware getting recognized when you plug it in? This is kind of a must have.

What step are we on. New device, or old device?

The only way that hyperterminal will know is if you tell it what com port it is. And the only way You will know, is if you look in Device Manager, and see a new serial port pop up when you plug the UBW32 in. And, the only way this will happen, is if the UBW32 gets recognized as new hardware. Which will only happen if we have the right firmware loaded .... etc... etc...

But I think we are getting closer.

Kenjones1935

- 16th October 2010, 19:20

You may be interested in this.

http://www.youtube.com/watch?v=M-7C7TIYJ8I

This vehicle reminds me of the original 'turtle' for which LOGO, the language, was developed.

I am on a slightly different tact. I am trying for a robocar that looks like and is driven like a modern automobile. The model level 1/10 sized radio control vehicles fit that description. They have accurate miniaturization and good speed (up to 30 actural mph). This may connect with middle school students.

Ken

Kenjones1935

- 16th October 2010, 19:47

Once, as I said in my post, Hyperterminal worked. Only once!
I wrote:

If I eliminate ASCII echo and I type 'hello' I do get 'hello' on my Hyperterminal GUI. That is GOOD. Trouble is I disconnected the PICkit2 and reconnected and HELLO no longer appears.

???????Ken

ScaleRobotics

- 16th October 2010, 19:54

Ok, but after you said that, you said:

Nutts. Wrong again!

UART's echo was ON.

And, you should get a "??HELLO?? command not recognized" or something to that effect back. So I would say nutts, it was the echo.

But I still don't have enough information to advise you any further. I don't know what step you are on.

Yes, the new .inf is different. It is for using with the firmware originally in your UBW32. (Which I believe is only in your untouched device). It is for step 2, if you are on step 2.

Walter

Kenjones1935

- 16th October 2010, 20:19

Here's what Device Manager says:

4851

ScaleRobotics

- 16th October 2010, 20:46

Thanks Ken,

That's a start! The more information you give me, the easier this will be to trouble shoot. If I have to guess what you are doing, this is going to be pretty slow and painfull. But, here it goes... (I suppose, in a way I deserve it for leading you astray for a day or two).

There are two possibilities of where you are at, if I were to guess.

1. You have loaded the firmware from post# 486 into the used UBW32 using your Pickit2, and have now plugged it in with the usb cord to the back of your computer. And now you are looking in the device manager. I am wondering what, if anything occured in the lower right hand part of your computer screen. Did it say new hardware found? Did it try to find a driver, or did it do nothing?

2. You already tried #1 and have gone to step 2: You switched to the untouched UBW32. You downloaded the microchip driver here and have installed it (like you have mentioned) http://www.sparkfun.com/datasheets/D...C/UBW32inf.zip (http://www.sparkfun.com/datasheets/DevTools/PIC/UBW32inf.zip) ,and have plugged the usb cable into it. You have checked to see if you get a "new hardware detected" message.

You have run the HID Bootloader executable from microchip http://www.cpustick.com/downloads/HIDBootLoader.exe (http://www.cpustick.com/downloads/HIDBootLoader.exe) , and you have seen if it can find your UBW32. Then you selected the first firmware I sent you in post#463. This one: StickOS for Microchip PIC32MX4-F512L UBW32 Board Bootloader (http://www.cpustick.com/downloads/StickOS.UBW32.F512L.v1.80c.elf.hex) (v1.80) (.HEX, UBW32 HID bootloader image) with the long name. Let the microchip bootloader try to load the firmware into the untouched one (not even using your PicKit2).

And now you are looking into your Device Manager, but see no new serial port.

Kenjones1935

- 16th October 2010, 20:51

Once, two evenings ago I sat down, turned on Hyperterminal and got 'hheelllloo' when I typed 'hello'. I said to myself that's a good connection. It has echo.

I then went to the UART TOOL in PICkit2. It did 'hello' when I typed 'hello'. I thought that was good so I took a snapshot and sent it to the forum. Then I realized that UART has the same 'echo' or 'no echo' config as Hyperterminal. It was set to 'echo'. Therefore it was not connected at all.

Having done that I went back to Hyperterminal and got nothing again and again and even today. Hmmmm But it did work once.

In no case did I get a response from the code in the chip.
Which leads me to another question.

When PICKIT2 is told to READ it displays what is labeled "Program Memory" into which I thought the original StickOS had been loaded. Am I wrong? When I first hooked up my new PICWhacker to the PICkit2 I did a READ. All it showed was FF's throughout. I just read the spec. pages on memory organization. Page 93 mentions "Separate Boot Flash memory for protected code." Is that visible from a READ? I do not understand the virtual and physical memory charts on Page 94. Things have changed since the Digital Equipment Corp made the PDP-11.

Ken