This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Pypilot heading display
#11
I have managed to use to use an esp32 to read  HDM from 192.168.14.1 port 20220 but cant create a loop that will give me a continuously updated stream. The string looks like 192.123, the numbers after the decimal point continuously change but the 192 is only correct when I first connect.  Is it necessary for me to send a request to update the reading?
Thanks for your help  John
Reply
#12
So if you reconnect the socket you get a new number? Did the compass move? Is it calibrated? Does pitch and roll give the same?

I will play with this more.
Reply
#13
If I turn the pypilot it immediately shows the new compass reading. My esp32 continues to show the old reading for 30secs or more. Checking port 20220  with opencpn debug shows the correct readings, so the problem is with the esp, maybe my code?

void loop() {
 WiFiClient client;

 if (!client.connect(host, port)) {
  Serial.println("Connection to host failed");
  delay(4000);
  return;
 } // end if

 Serial.println("Connected to server successful!");

   
  while (client.connected()){
    if (client.available()) {
           
     String NMEAline = client.readStringUntil('\n'); //Read one line of the NMEA output 
    if(NMEAline.startsWith("$APHDM")){ //Check if it is the APHDM one which contains the info I want
     Serial.println(NMEAline); //Print it out over serial
     delay(500);    
    } // end if
  } // end while
  } // end line if
} // end loop
Reply
#14
I would check netcat and then just dump the raw data over serial to see if you are getting the data.

You had me worried it was my bug Smile
Reply
#15
I think my problem is caused by the buffer filling up with data, it is then read and displayed, so I always see data that is 20sec to 2min old. The usual Arduino TCP functions dont seem to be able to handle that. Any suggestions? 
John
Reply
#16
Ive given up on TCP, I have converted the TCP data to UDP in opencpn. It now works ok with about 4sec delay.  
Thanks for your help -  John
Reply
#17
(2020-10-11, 11:44 PM)seandepagnier Wrote: If you want to get the maximum rate of 20hz, you have to connect direct to pypilot and to get the lowest latency possible I use udp sockets

Is this UDP interface documented somewhere?

In theory, I could use this heading output as a backup for my existing NMEA 2000 compass? 

My other AP requires 10Hz heading input to be happy.
Reply
#18
It is documented in the source code... sorry. The udp interface is mostly used for manual control where low lag is more important, so UDP is not output from pypilot but can be used as an input if that makes sense.

As for fast heading output, it would be possible to implement. As for tcp buffering, maybe just calling a flush routine would help?
Reply
#19
(2024-02-20, 11:58 PM)seandepagnier Wrote: It is documented in the source code...  sorry.    The udp interface is mostly used for manual control where low lag is more important,  so UDP is not output from pypilot but can be used as an input if that makes sense.

As for fast heading output, it would be possible to implement.  As for tcp buffering, maybe just calling a flush routine would help?


Ok, so I skimmed through the source a bit, I guess it is the "server" that is listening these watch -requests.

a) is it enough that I send UDP packet to port 23322 containing the watch request like:  watch={"imu.heading_lowpass":10.0}\n  - and then the reply packets should arrive to same socket I sent the request from?

b) what is the unit of watch request frequency/update period? I presume updates per second possibly, ie. Hz?

c) what is the maximum rate I can request the updates? 10Hz is what is required, but is there a higher limit - if so, could request higher rate and do some external filtering possibly?

d) is there a list somewhere of the available key values? If not, skimming the source is ok Smile

e) I would need imu.heading or possibly imu.heading_lowpass and maybe imu.headingrate, and convert those into nmea 2000 and call it a day? Should be pretty straight forward. I already have an esp32 injecting other stuff into nmea 2000 bus using the ttlappalainen library.

f) If I also request imu.pitch and imu.roll, I could use maybe this as a say camera stabilizer input source as well? What is the difference between imu.roll and imu.heel?
Reply
#20
Sorry to be confusing... but there are 2 separate uses of udp sockets. One is for commanding the servo in manual control mode (slightly less latency) and may not be worthwhile.

The other use is used by upy_client, and a udp_port is sent to the server as a setting, eg: udp_port=23423

a) The server will then reply to watched values via udp on this port rather than tcp. All watch requests as well as setting other values are still sent via tcp, and the tcp connection should still be monitored. udp is connectionless and therefore not 2 way communication

b) units are in period.
c) If you send a period of 0, you would get the fastest rate.
d) you could run pypilot_client or watch "values" to get the keys
e) ok. I would try getting it working with tcp first, and try udp if you really need it. 30 second delay makes no sense, 4 second delay also makes no sense. The udp vs tcp is a split second difference or generally you cannot tell. Play with other platforms and see... Find a way to flush the buffer. I did put the udp support in for a slightly more responsive esp32 control.
f) imu.heel is a lowpass version of imu.roll
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)