Add GPS/PARSE to 8xSERVO-MOTOR CODE in Oshonsoft

Sort by date Sort by votes
Hi,
Here's is CODE including GPS and PARSE from a different PIC. It has QEI, which is not used here.

The CODE checks for a sentence beteen $ and W, which only works in the N and W of the globe. so is limited the 1/4 where I live, and can be expanded for all, but as it's working, leave for now. There are suggestions for this e,g, CSV and * CRLF. The reason W, was chosen is to keep the STRING length down,which could be critical, so [IF W or IF E] is a suggestion.
 

Attachments

  • 18F4431 32MHz XTL REMOTE_SLAVE RX_QEI 021222 1030.bas
    20 KB · Views: 340
Upvote 0 Downvote
That thread is saying that three different things can send a message over RS232 and they can switch at random times so it's possible you'll never receive some packages, Is that correct? Note, it's possible a switch could happen mid sentance and you get the first half of one (starting with $) and the second half of another (ending with W).

From what I can gather, the chip has to do a number of thing,
control servos,
read USART,
Input from an R/C receiver,
Calculate various other things.
What are the other two things (beside GPS) that can send data?

I suggest adding a read receiver data to the code we have working.
Do you have an example of what comes from the R/C receiver?

Mike.
 
Upvote 0 Downvote
I was going to suggest converting any coordinate to a 32 bit value that represents how far around the world it is. So 0 will be 0° and 1 would be 360° but as 0 and 360 are the same point 1 is never needed. The 32 bit value would represent a value between 0 and 0.999999999999999999 - so the fractional part of the value.

Mike.
 
Upvote 0 Downvote
Hi M,
The NMEA sentences arrive precisely on the second and in 250ms spaces until the next second= 5/sec, but I imagined that to the CODE it would seem random.
It can be accurately timed, easily, or [wait till $]?
The whole sentence must be received consecutively, to make sence.

4431 jobs (This may change depending?)
READ:
SPI control DATA.
GPS-PARSE via UART
READ A/D information

Calculate 'what to do'

CONTROL;
MOTRS-SERVOS

I suggest adding a read receiver data to the code we have working.

The RC UART receive is on the other PIC, and arrives into this PIC via SPI

Do you have an example of what comes from the R/C receiver?

Not yet, but it is likely to be something like LAT, LON, aim degrees.

The SERVO CODE is the last of the peripherals, so after tidying up 4 CODEs on 4 PICs. We can start playing with what it all does, but first get it all co-ordinated, in the MAIN thread.
C
 
Upvote 0 Downvote
Hi M,
This sounds mighty interesting, but regarding the GPS, there are other things for me to do, not mentioned here, and so I don't overload, leave it for now, and stick to $-W.

From memory, I think the LAT LON coordinates e,g N=+ S=- E=+ W=- for 0-0, worked in my head.
C
 
Upvote 0 Downvote
Pommie said:
How does the data arrive from the transmitter? Is it like normal servo pulses, some kind of RS232?

Mike.
Click to expand...
Hi M,
PIC1 has the control 'buttons' joystick etc PIC2 READs the other GPS, then radio to PIC 3.
PIC3 READs other peripherals, and processes all DATA, then sends it to PIC4 4431 via SPI to control the MOTORS/SERVOS.
There are 4x PICs each with long CODE, some of which I have to refresh myself to remember, and would take a lots of explaining, it's all in the LINKs I posted.
EDIT: PIC numbers corrected
C
 
Last edited:
Upvote 0 Downvote
I'm curious how you use the GPS coordinates. The coordinates are in degrees, seconds and fractions of seconds. I assume Oshonsoft has float but not double. Float is normally 32 bit (or I expect it to be in Oshonsoft) Which doesn't really have the resolution for what you're doing. Using a 32 bit integer means that each bit is approximately 9mm at the Equator.

As you're controlling this (I assume) by R/C then any time less than 0.2S (200mS) is faster than human reaction time so should be perfectly fast enough.

What peripherals need reading?

Adding SPI code to the ISR should be trivial and the main code can interpret it.

However, I can't help but think this would be a lot simpler if only one pic was involved.

Mike.
 
Upvote 0 Downvote
If you're wondering where I get 9mm from, Earth is approx 4 million meters circumference, 4 million divided by 2^32 is 0.009313 meters, or 9.3mm.

Maths could get tricky though as I'm fairly sure Osh doesn't have 64 bit variables (or Doubles), so integer maths might be a good way to go.

Mike.
 
Upvote 0 Downvote
Hi M,
This project has taken 5years to get to this point, and we haven't started on the RC stuff yet. I have to know every part of it, and as some was years ago, I can't immediately recall all of the reasons for choices, but I know not to make changes without checking the rest of the system.
Cost and size of SMD components and peripherals, PCB design, different members CODE, are some reasons for choices.
Anyway, I have to work in compartments, so many of your questions are for the main thread, I posted the link.
If we can get the GPS into the SERVO CODE first, while I redesign the PCB to include the shift register, I can cope with that.

Are you happy with that?
C
 
Upvote 0 Downvote
Hi M,
I only gave it a little thought, as I have to stay on track, and I have little maths skills, I count on my fingers. (I do have a maths qualification though, long forgotten)
Best left till later, when I can think about it. (on the main thread)
C.
 
Upvote 0 Downvote
Hi M,
Using: $GNRMC,162254.00,A,3723.02837,N,12159.39853,W,0.820,188.36,110706,,,A*74
as an example, the 2x measurements shown in red are the accuracy from the GPS, and these are compared for movement. What accuracy are they?

The distance at 30MPH for 200ms is my first though regarding, 'is it fast enough'

What perihpherals see #5.

C
 
Upvote 0 Downvote
camerart said:
What accuracy are they?
Click to expand...
12159.39853 is 121 degrees, 59.39853 minutes is to 5 decimal places. Accurate to approximately 200m (at the equator). I've seen sentences with 7 decimal places which is accurate to ~2m. However, you have North and South to add to that. I'm not sure how you would do calculations with that figure.

Mike.
Edit, out by a factor of 100 - should be Accurate to approximately 200cm or with 7 decimal places ~2cm.
 
Last edited:
Upvote 0 Downvote
Hi M,
That doesn't seem accurate enough for use, really.
I'm sure the ones I have should be more accurate than that, even at my latitude.

At the moment better GPS modules, are £250, which is a bit much, as I need 4x of them.

I'm working on the 'new' PCB with shift register. The empty PCB's are made in China, then I have to stick the components on,before we can test anything.

If we leave accuracy for now, and if you're happy to carry on adding the GPS into the 'shift register' CODE, while I finish the PCBs and my mate finishes tidying up the SPI's, this will mean we can carry out some sort of test flight.

Is that ok?
C
 
Upvote 0 Downvote
You must log in or register to reply here.

Similar threads

  • Question
Library to work with displays based on TM1638 (Oshonsoft Pic Basic Compiler).
Replies
0
Views
1K
DogFlu66
  • Question
Can Oshonsoft use 'byref' in a FUNCTION? (Plus examples of CHAR MATCHING CODE)
3 4 5
Replies
92
Views
20K
camerart
  • Question
UART/CODE problem Oshonsoft
3 4 5
Replies
83
Views
16K
camerart
  • Question
Library for DS1302 clock (Oshonsoft Pic Basic Compiler).
Replies
0
Views
682
DogFlu66
  • Question
Using RD16 16BIT PIC register write in Oshonsoft
Replies
15
Views
4K
camerart
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…