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

[camerart]

Hi,
Here is CODE for 18F4431 8xCH SERVO-MOTOR CODE using a shift register: https://www.electro-tech-online.com/threads/oshonsoft-interrupt-parse.159316/

Add GPS and PARSE CODE to the above CODE, in the same way.

Camerart

 

[camerart]

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.

 

[Pommie]

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.

 

[Pommie]

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.

 

[camerart]

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.

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

 

[camerart]

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.

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

 

[Pommie]

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

How it arrives, not what arrives. Is it in the form of servo pulses? RS232?

Mike.

 

[camerart]

How it arrives, not what arrives. Is it in the form of servo pulses? RS232?

Mike.

Hi M,
Can you clarify what you're asking please?
C

 

[Pommie]

How does the data arrive from the transmitter? Is it like normal servo pulses, some kind of RS232?

Mike.

 

[camerart]

How does the data arrive from the transmitter? Is it like normal servo pulses, some kind of RS232?

Mike.

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

 

[Pommie]

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.

 

[Pommie]

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.

 

[camerart]

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.

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

 

[camerart]

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.

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.

 

[camerart]

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.

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

 

[Pommie]

What accuracy are they?

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.

 

[camerart]

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 8 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.

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

 

[Pommie]

Can Oshonsoft do 64 bit integers?

Mike.

 

[Pommie]

Hi M,
That doesn't seem accurate enough for use, really.

See my edit. Pre coffee maths.

Mike.

 

[camerart]

Can Oshonsoft do 64 bit integers?

Mike.

Hi M,
I'll find out.
C