PBP projects for R/C models

[rmteo]

While any C compiler does certainly support functions, there are at least 3 dialects of BASIC for PICs that not only support functions but features such parameter passing, global/local variables, etc. that allow structured programming.

[Kenjones1935]

The code in my little cars is, in fact, very little. It only deals with distance. It does not calculate rates of speed, of approach, of turn. It does not calculate angles. It does no mapping.

Maybe my 16F887 based kit is not up to that task. I am not sure and I do not know how to find out. Maybe I could architect better in C, but it has been literally twenty five years since..... and I used to have a very extensive (corporate supplied) library.

Suggestions?

Ken

[rmteo]

mbed is a tool for Rapid Prototyping with Microcontrollers mBed

Microcontrollers are getting cheaper, more powerful and more flexible, but there remains a barrier to a host of new applications; someone has to build the first prototype! With mbed, we've focused on getting you there as quickly as possible.

Huge library (check out the Handbook, Cookbook and Code pages), free IDE and C compiler. 100MHz 32-bit MCU, 512kB Flash, 64kB RAM.

[Kenjones1935]

mbed is ARM = RISC. I remember RISC from my days at DEC. For my robocars I chose the Microchip 16F887 because I stumbled upon and bought the PICkit 2 bread board system. Had the PICkit board come with 0.1" centers I would probably stayed with it. Now I use the PIC stand alone and solderless protoboard.

I am afraid to leave Microchip and associated vendors. I bought two UBW32 BITwackers then found that I could not program them with my version of PICKit 2. Also the UBW32 does not come in a 0.1" DIP package. I am also a bit confused where to go for help other than this forum.

Maybe I can stick with PICBASIC PRO if I can teach myself more about doing simple mathematics and array structures for data storage. I surely would like subroutine calls that accept parameters and return values.

Suggestions?

Ken

[mackrackit]

MicroChip also = RISC

I surely would like subroutine calls that accept parameters and return values.

Just write a sub routine that will do what you want and GOSUB. Pretty much the same thing. Yes, the "C" folks will flame this. But it is true.

[ScaleRobotics]

The code in my little cars is, in fact, very little. It only deals with distance. It does not calculate rates of speed, of approach, of turn. It does not calculate angles. It does no mapping.

Maybe my 16F887 based kit is not up to that task. I am not sure and I do not know how to find out. Maybe I could architect better in C, but it has been literally twenty five years since..... and I used to have a very extensive (corporate supplied) library.

Suggestions?

Ken

Hello Ken.

Sure, there are more powerful chips to use. There are also more powerful languages. But, the question is, what are you going to be doing, and do you really need to change chips, and or languages? So far, the use you have made the chip perform, is probably the equivalent of an old man walking with a walker. You have not taxed your current environment whatsoever! Sure, a lot more could be done, but I think, if it was done right, the most required might be an 18F device.

Currently, your PIC18F887 can handle 5 million assembly instructions per second. Your hardware (servo) can handle at maximum, 50 instructions per second (pulse width control at 50 hertz, or 20ms frames). So, with every chance to change your direction, your program can perform 100,000 assembly instructions. A lot of PBP code can fit into 100,000 instructions. That can basically go through every available code location (14k program space) on the chip seven times, during the 20ms it has to make a decision.

Seeing as you are hardly putting a dent in the 14k, shouldn't you at least try to do something more, before saying you don't think the chip can handle it?

Let's take a look at the items you mention:
Speed : This is relatively easy to do and will hardly take any code. Put a sensor on a wheel and away you go!

Approach of turn: You have all the distances measured, why not use them to in your control for turning. Calculate at what point in time will you be x length to the wall, and at this time turn, instead of saying "if my measurement is less than 4 feet, etc etc. Since you are only taking front measurements every 60ms?? or so, you might well be beyond the 4 feet by the time you measure.

Calculate angles: Cool idea. But with what sensors are you going to determine that? And how? PBP has SIN, COS, Hypotenuse and ATAN built in. Sure these are rough calculations, but I don't know that with your current sensors you will need (or be able to use) anything more advanced. Add a magnetometer http://www.sparkfun.com/products/9371 , and perhaps this could get more complex. If it does need to be more precise, there is a PBP compatible CORDIC include file to calculate SIN, COS, ATAN, Hypotenuse. See http://www.picbasic.co.uk/forum/showthread.php?t=10528 . On an 18F, you can do this 9,000 times per second while still using PBP in our program.

As for mapping, with your current set up, I would go out on a limb, and say that is impossible with any language. To map, you need to know where you are. You will need more sensors! A GPS (and a large outdoor "track"), or magnetometer, or light sensors that find at least a reference beacon, or barcode like strips on the floor, just to figure out where it is. Lots of ways to do it, some better than others.

So, from what you have vaguely mentioned, I see no barrier using your current chip, or using PBP. Can you be more specific about what function libraries you are talking about? What ever language you choose, you are going to have to decide how you are going to perform these functions, and what sensors you are going to use to do them.

[Kenjones1935]

I have not been planning on adding sensors. I might change the SONAR for IR. I know nothing about the details.

For speed I was planning on dividing distance traveled by time between measurements. For angles, I agree, the SONAR's have a vague and varying pattern. Hence the 'speed' calculations may be inconsistent.

With the hobby level car I have complete proportional control of both steering and wheel power. If I could get a PWM system that is truly 50htz (my present system is not. It was calibrated by trial and error) then I would have a great deal of flexibility - the better to speed up the car. Then a parameter passing GOSUB would be very convenient.

Ken

[ScaleRobotics]

I have not been planning on adding sensors.

Then it sounds like PBP should be plenty powerful for your application. Only, I don't think you will be able to get into mapping, as there is no reference to where the car currently is. You could count turns, but once you miss or rather add a turn, then you are off. The only angle you could calculate, is the angle between the front location sensed, and the side position sensed in reference to being parallel with the car. You would not know whether this angle is being measured on a corner, or a straight away.

If you want to use accurate servo, you could use some of the code already pointed out to you.

(Ok, this one is kind of new, so no one suggested it yet)
http://www.picbasic.co.uk/forum/cont...th-2-I-O-lines

Back on post #336 of this thread:
http://www.picbasic.co.uk/forum/show...1961#post91961

Somewhere way back on this thread:
http://www.picbasic.co.uk/forum/cont...e-Servo-Driver

And suggested back on post #80 of this thread (though these later examples a lot better)
http://www.picbasic.co.uk/forum/cont...-encode-decode

[ScaleRobotics]

Hi Ken,

HPWM is hardware based, so it keeps going while other things happen.

Check out the manual:

It can run continuously in the background

while the program is executing other instructions.

You might try trouble shooting your output signal, to see what is happening.

[Kenjones1935]

HPWM is a hardware command. It runs while PAUSE is pausing except (it appears) when it is the first "active" command in the code. Really. Truly. The only difference between those two snippets of code is the WHILE statement at the beginning of the one that works.

Note: These few lines of code precede the 'main:' label. All I am trying to do is to demonstrate that the wheel controls are working before experimenting with racing. Once the program counter gets past 'main:' both versions run identically.

Ken

[Kenjones1935]

I would like to read a TIMER immediately after sending a trigger pulse to my SONARS. Then immediately reset it for the next cycle. (Which TIMER am I not using with PAUSE or HPWM.) Anybody?

I want to calculate velocity. I plan to subtract two SONAR distance readings and divide by the time elapse between triggers. Units of distance sound travels in a millisecond (13.2 inches) divided by the number of milliseconds. (Could do no translation: Use the distance sound travels in a 4Mhz tick divided by the number of those ticks between SONAR triggers.) Could I explain that to middle school students?

I have not been translating SONAR echo pulses to inches. Instead I learned how to translate inches into SONAR echo times. That is how I set up my distance parameters. At 1100 feet per second that is 13.2 inches per millisecond. (When measuring distance the PIC must divide by two. It is measuring time for an echo response.)

Any simple code snippets you know of?

Ken

[Kenjones1935]

I would like to use the 4 Meg counter to measure time in seconds and the SONAR responses to measure distance in inches.

I could then set up CONstants that would be recognizable
and measurable by middle school students with a yardstick and a watch with a second hand.

How?

Ken

[mackrackit]

This displays the sonar distance in inches. Using the "ping" module from Parallex.

'  18F6680
    DEFINE OSC 20
    @ __CONFIG    _CONFIG1H, _OSC_HS_1H
    @ __CONFIG    _CONFIG2H, _WDT_OFF_2H & _WDTPS_128_2H
    @ __CONFIG    _CONFIG4L, _LVP_OFF_4L
    INCLUDE "modedefs.bas"
    DEFINE LCD_DREG     PORTG
    define LCD_DBIT     0
    DEFINE LCD_RSREG    PORTE
    DEFINE LCD_RSBIT    0
    DEFINE LCD_EREG     PORTE
    DEFINE LCD_EBIT     1
    DEFINE LCD_BITS     4
    DEFINE LCD_LINES    4
    DEFINE LCD_COMMANDUS    3000
    DEFINE LCD_DATAUS   150
    PAUSE 500
    PAUSE 1000
    
    INCONSTANT  CON 890
    INDISTANCE  VAR WORD
    TIME        VAR WORD
    
    START:
    HIGH PORTB.3
    PULSOUT PORTB.3,2
    PULSIN  PORTB.3,1,TIME
    INDISTANCE = INCONSTANT ** TIME
    LCDOUT $FE,1,DEC3 INDISTANCE," INCHES" 
    PAUSE 100
    GOTO START

[ScaleRobotics]

Yes, but how are you checking to see that hpwm is not working, sometimes. Are you really observing the signal itself, or just the reaction it is "supposed" to cause? You have the tools to look at the source .... why not use them?