I have a computer with a GPS connected to a serial port that is running gpsd with a pretty basic configuration. Here is the contents of /etc/default/gpsd:
START_DAEMON="true"
USBAUTO="false"
DEVICES="/dev/ttyS0"
GPSD_OPTIONS="-n -G"
GPSD_SOCKET="/var/run/gpsd.sock"
With this config, gpsd runs fine and all gpsd client utilities, e.g. cgps, gpspipe, gpsmon, can get data from the GPS.
I am trying to access GPS data from a Qt QML program using the PositionSource element with the following syntax but lat and long show as NaN so it doesn't work:
PositionSource {
id: gpsPos
updateInterval: 500
active: true
nmeaSource: "socket://localhost:2947"
onPositionChanged: {
myMap.update( gpsPos.position )
}
}
I tried piping the NMEA data from the GPS to another port using gpspipe -r | nc -l 6000 and specifying nmeaSource: "socket://localhost:6000 and everything works fine!
How do I make Qt talk to gpsd directly?
After tinkering (i.e. compiling from source, installing, configuring, testing, etc.) with gps-share, Gypsy, geoclue2, serialnmea and other ways to access data from a GPS connected to a serial port (thanks to Pa_ for all the suggestions), but all with no results while gpsd was working perfectly for other apps, I decided to make Qt support gpsd by making a very crude change to the QDeclarativePositionSource class to implement support for a gpsd scheme in the URL for the nmeaSource property. With this change, a gpsd source can now be defined as nmeaSource: "gpsd://hostname:2947" (2947 is the standard gpsd port).
The changed code is shown below. I would suggest this should be added to Qt at some point but in the meantime, I guess I need to derive this class to implement my change in a new QML component but, being new to QML, I have no idea how that is done. I suppose it would also probably be a good idea to stop and start the NMEA stream from gpsd based on the active property of the PositionSource item... I will get to it at some point but would appreciate pointers on how to do this in a more elegant way.
void QDeclarativePositionSource::setNmeaSource(const QUrl &nmeaSource)
{
if ((nmeaSource.scheme() == QLatin1String("socket") )
|| (nmeaSource.scheme() == QLatin1String("gpsd"))) {
if (m_nmeaSocket
&& nmeaSource.host() == m_nmeaSocket->peerName()
&& nmeaSource.port() == m_nmeaSocket->peerPort()) {
return;
}
delete m_nmeaSocket;
m_nmeaSocket = new QTcpSocket();
connect(m_nmeaSocket, static_cast<void (QTcpSocket::*)(QAbstractSocket::SocketError)> (&QAbstractSocket::error),
this, &QDeclarativePositionSource::socketError);
connect(m_nmeaSocket, &QTcpSocket::connected,
this, &QDeclarativePositionSource::socketConnected);
// If scheme is gpsd, NMEA stream must be initiated by writing a command
// on the socket (gpsd WATCH_ENABLE | WATCH_NMEA flags)
// (ref.: gps_sock_stream function in gpsd source file libgps_sock.c)
if( nmeaSource.scheme() == QLatin1String("gpsd")) {
m_nmeaSocket->connectToHost(nmeaSource.host(),
nmeaSource.port(),
QTcpSocket::ReadWrite);
char const *gpsdInit = "?WATCH={\"enable\":true,\"nmea\":true}";
m_nmeaSocket->write( gpsdInit, strlen(gpsdInit);
} else {
m_nmeaSocket->connectToHost(nmeaSource.host(), nmeaSource.port(), QTcpSocket::ReadOnly);
}
} else {
...
Related
So this might be a bit basic of a question, but I don't have much experience on the hardware side of things. I am using DJI Android Mobile SDK to communicate with a M600 flight controller and have a FTDI CU/TTY device I am trying to send info back and forth.
This successfully works to send "Hello World" to my USB device:
//sends data to onboard sdk device
final byte[] helloWorld = "HelloWorld".getBytes();
mFlightController.sendDataToOnboardSDKDevice(helloWorld, new CommonCallbacks.CompletionCallback() {
#Override
public void onResult(DJIError djiError) {
if (djiError != null) {
showToast(djiError.getDescription());
WriteFileAppendAsync writeAppend = new WriteFileAppendAsync();
writeAppend.execute(djiError.getDescription(), "sendOnboardErrorFile.txt");
} else {
showToast("Hopefully Hello World");
WriteFileAppendAsync writeAppend = new WriteFileAppendAsync();
writeAppend.execute(helloWorld.toString(), "sendOnboardSuccessFile.txt");
}
}
});
I can see this when I run either of the following in terminal:
screen /dev/cu.usbserial-BLAHBLAH 38400
screen /dev/tty.usbserial-BLAHBLAH 38400
A bunch of gibberish/ hieroglyphics show up and then the text "Hello World" pops up every time I click a button that triggers the above DJI code.
Now, I want to get the flips side of this working i.e. send something back from the USB to the DJI sdk using the following:
if (mFlightController.isOnboardSDKDeviceAvailable()) {
showToast("Set Onboard SDk Callback");
mFlightController.setOnboardSDKDeviceDataCallback(new FlightController.OnboardSDKDeviceDataCallback() {
#Override
public void onReceive(byte[] bytes) {
WriteFileAppendAsync writeAppend = new WriteFileAppendAsync();
writeAppend.execute(bytes.toString(), "onboardCallbackFile.txt");
}
});
}
The trouble is I never seem to get anything in response.
As per this question, I made sure I have read write permission on the USB device:
chmod o+rw /dev/ttyS1
And I have tried all sorts of echo and cat commands (I don't know which one is read and write). They either say device is busy, or if not, they seem to open a port of communication (the terminal blinks indefinitely), but nothing sends to my device.
Commands I've tried:
echo 'HelloTest' > /dev/cu.usbserial-BLAHBLAH
Nothing special happens, goes to next terminal line
echo 'HelloTest' > /dev/tty.usbserial-BLAHBLAH
Terminal returns HelloTest
echo 'HelloTest' < /dev/tty.usbserial-BLAHBLAH
cursor blinks indefinitely
echo 'HelloTest' < /dev/cu.usbserial-BLAHBLAH
Terminal returns HelloTest
cat < /dev/cu.usbserial-BLAHBLAH
cat -v < /dev/tty.usbserial-BLAHBLAH
cat -v > /dev/tty.usbserial-BLAHBLAH
cat -v > /dev/cu.usbserial-BLAHBLAH
No such file or directory (I guess I need 2 terminals running for this?)
Questions
Does this have to do with Baud rate? I have set that up in DJI Assistant. What is the difference between TTY and CU and Echo and Cat? I have tried all sorts of combinations. I am able to use the screen command with both cu and tty. Finally, what is a simple hello world I can send back to the sdk to see that I am actually receiving data from my usb device? I would think echo would success, but I'm not receiving anything.
Edit
I almost feel like I need to use something like usb-serial-for-android; however, I'm not actually connecting the usb device to my android device. Instead, I am connecting to the DJI RC Controller, which connects to Lightbridge/ M600, which connects through the API port with my usb device.
I came across this issue a while back as well using the Matrice M100 with the ROS onboardSDK.
if (mFlightController.isOnboardSDKDeviceAvailable()) {
showToast("Set Onboard SDk Callback");
mFlightController.setOnboardSDKDeviceDataCallback(new FlightController.OnboardSDKDeviceDataCallback() {
#Override
public void onReceive(byte[] bytes) {
WriteFileAppendAsync writeAppend = new WriteFileAppendAsync();
writeAppend.execute(bytes.toString(), "onboardCallbackFile.txt");
}
});
}
Where are you calling this?. Here's how I solved my issue: I wrote a function:
private void addCallback()
{
mFlightController.setOnboardSDKDeviceDataCallback(new
FlightController.OnboardSDKDeviceDataCallback() {
#Override
public void onReceive(byte[] bytes) {
// Do stuff with the data here..
}
});
}
Then in my onResume method I did something like:
#Override
public void onResume() {
Log.e(TAG, "onResume");
super.onResume();
if (mFlightController != null) {
addCallback();
}
}
It's not the most elegant way but it seemed to do the trick for me. You can find my solution here. It's been a while since I worked on it though!
If you have an FTDI device then you need an FTDI driver. :)
Did you install something like this by chance? https://www.ftdichip.com/FTDrivers.htm
Serial port emulation through USB requires virtual serial port software to function.
I believe you need to understand the DJI OpenProtocol to make this work. The "bunch of gibberish" is in fact the problem here. That gibberish is the protocol that DJI drones use to properly relay communications.
In order to send from "Onboard" to "Mobile" with the latest code you need the 0xFE CMD_Set Id as a header to your data:
https://developer.dji.com/onboard-sdk/documentation/protocol-doc/open-protocol.html
So, either, figure out the proper format to your data or buy a cheap PC and install the OSDK.
I'm trying to connect to a D-Bus signal this way:
bool result = QDBusConnection::systemBus().connect(
"foo.bar", // service
"/foo/bar", // path
"foo.bar", // interface
"SignalSomething",
this,
SLOT(SignalSomethingSlot()));
if( !result )
{
// Why!?
}
QDBusConnection::connect() returns a boolean, how do I get extended error information? If a check QDBusConnection::lastError() it returns no useful information (as QDBusError::isValid() is false).
I had the same issue and it turned out that the slot I connected to had the wrong parameter types. They must match according to Qt's documentation and it looks like connect() verifies that, despite not explicitly mentioned.
Warning: The signal will only be delivered to the slot if the parameters match.
I suggest d-feet to list signals and check their parameter types. dbus-monitor does list signals, paths and such too, but not always the exact type of parameters.
One important observation though: I fixed the issue in my particular case by using different slot parameters than the actual signal has!
I wanted to connect to a com.ubuntu.Upstart0_6 signal mentioned here to detect when the screen in Ubuntu is locked/unlocked. dbusmonitor prints the following and d-feet shows parameters (String, Array of [String])
// dbusmonitor output
signal time=1529077633.579984 sender=:1.0 -> destination=(null destination) serial=809 path=/com/ubuntu/Upstart; interface=com.ubuntu.Upstart0_6; member=EventEmitted
string "desktop-unlock"
array [
]
Hence the signal should be of type
void screenLockChangedUbuntu(QString event, QVector<QString> args) // connect() -> false
This however made connect() return false. The solution was to remove the array parameter from the slot:
void screenLockChangedUbuntu(QString event) // works
I am aware that the array parameter was always empty, but I cannot explain why it only worked when removing it.
You could try these tricks:
1) Set QDBUS_DEBUG environment variable before running your application.
export QDBUS_DEBUG=1
2) Start dbus-monitor to see what's happening on the bus. You may need to set a global policy to be able to eavesdrop system bus depending on your distro.
Update:
Are you sure connecting to the system bus succeeded? If it fails you should probably check system.conf policy and possibly create own conf in system.d. This post might be helpful.
You could first connect to the system bus with QDBusConnection::connectToBus and check if it succeeded with QDBusConnection::isConnected. Only after that you try to connect to the signal and check if that succeeded.
QDBusConnection bus = QDBusConnection::connectToBus(QDBusConnection::systemBus, myConnectionName);
if (bus.isConnected())
{
if(!bus.connect( ... ))
{
// Connecting to signal failed
}
}
else
{
// Connecting to system bus failed
}
I'm having a little difficulty with johnny-five (Multiple Boards) ; can anyone shed some light on this for me?
I have 2 Arduinos connected and I can access them individually perfectly fine with the "var board = new five.Board()".
I can successfully connect and use them both with Cylon.js.
However, when I attempt to utilize the "new five.Boards()" it never seems emit a "ready" event so I can start coding my logic.
Using (slightly modified) johnny-five/eg/boards-multi.js
var five = require("../lib/johnny-five.js");
var boards = new five.Boards(["A", "B"]);
// Create 2 board instances with IDs "A" & "B"
boards.on("ready", function() {
// Both "A" and "B" are initialized
// (connected and available for communication)
// |this| is an array-like object containing references
// to each initialized board.
this.each(function(board) {
console.log("READY"); // NOTE: this never executes
// Initialize an Led instance on pin 13 of
// each initialized board and strobe it.
var led = new five.Led({
pin: 13,
board: board
});
led.blink();
});
});
My console shows:
1437253899028 Device(s) /dev/ttyACM1,/dev/ttyACM0
1437253899104 Connected /dev/ttyACM1
1437253899121 Device(s) /dev/ttyACM0
1437253899126 Connected /dev/ttyACM0
1437253901860 Board ID: A
1437253901862 Board ID: B
...and I wait forever and it never emits "ready"...
Note 1: I have re-uploaded the latest "StandardFirmata" on both of them several times; and they work just fine on their own.
Note 2: I have tried the exact same setup on 3 different systems (one ubuntu linux, one on Windows, and one of Raspberry PI 2B) same problem on all...
I'm not sure if I am missing something boneheaded here; however no matter what I try johnny-five just wont allow me to proceed. As I mentioned above, it seems to work perfectly with Cylon-- however, I'd rather use j5 as I've got quite a bit of code already in place I'd rather not port over to Cylon just to connect more than one Arduino to my system.
Any help would be greatly appreciated!
Update #1:
I am getting a little closer, I can address each Arduino board now. However; I am still stumped on how to properly catch the "ready" event.
var five = require('johnny-five');
var ports = [
{ id: "A", port: "/dev/ttyACM0" },
{ id: "B", port: "/dev/ttyACM1" }
];
var boards = new five.Boards(ports).on('ready', function() {
// does nothing?
console.log("THIS SHOULD TRIGGER");
});
// Waiting 5 seconds for the boards to init, instead of "ready" event.
setTimeout( function() {
console.log(boards[0].isReady);
console.log(boards[1].isReady);
}, 5000);
This ends up with the console output of:
1437268012413 Connected /dev/ttyACM0
1437268012427 Connected /dev/ttyACM1
1437268015161 Board ID: A
1437268015163 Board ID: B
true
true
....at this point, I can do the following to address the boards (within the setTimeout() of course):
var led1 = new five.Led( {
pin: 6,
board: boards[0]
});
led1.on();
var led2 = new five.Led( {
pin: 4,
board: boards[1]
});
led2.on();
Still attempting to determine why I cannot catch the elusive "ready".
Update #2:
Looks like I figured it out. It was in fact emitting ready, however I wasn't utilizing the API correctly.
Working Code:
new five.Boards(ports).on('ready', function( boards ) {
console.log( boards ); // ready emits
});
Update #3:
I think I found a bug in the library.
It seems that the following file:
node_modules/johnny-five/lib/board.js
line: 1109
If you change:
if (this.repl)
to
if (false && this.repl)
It seems to emit the "ready" event.
I've found a bug in the repl initialization, this will be fixed in the next release. The issue was a call to state.board.info(...) in Repl.prototype.initialize, where the info method was undefined as a result of an oversight during recent refactoring of the board logging and logging function definitions. This bug appeared in v0.8.85, so try npm install johnny-five#0.8.84 to resolve the issue until the next release.
I'm currently working with an Arduino trying to build an ad hoc network to which a device can connect to and send web requests to. The problem I am currently having is that I can only set up one connection and then when that connection is terminated (with client.stop()), all subsequent connections are not picked up by the server, even a cURL command just sits there spinning. The first connection I start when I reset the server works fine, and I am able to talk to the server; but after that, the Arduino can no longer find new clients (even though it's trying with the library given).
I`m using the SparkFun library for the WiFly shield cloned from GitHub, along with an Arduino Uno.
My current code is based off their default example 'WiFly_AdHoc_Example', but I had to remove a few things to get the network to start up which might be the cause of this problem.
Here is the .ino file that I am running.
#include <SPI.h>
#include <WiFly.h>
//#include <SoftwareSerial.h>
//SoftwareSerial mySerial( 5, 4); //Part from example not used (see below)
WiFlyServer server(80); //Use telnet port instead, if debugging with telnet
void setup()
{
Serial.begin(9600);
//The code below is from the example, but when I run it the WiFly will hang
// on Wifly.begin(). Without it, the WiFly starts up fine.
//mySerial.begin(9600);
//WiFly.setUart(&mySerial); // Tell the WiFly library that we are not
// using the SPIUart
Serial.println("**************Starting WiFly**************");
// Enable Adhoc mod
WiFly.begin(true);
Serial.println("WiFly started, creating network.");
if (!WiFly.createAdHocNetwork("wifly"))
{
Serial.print("Failed to create ad hoc network.");
while (1)
{
// Hang on failure.
}
}
Serial.println("Network created");
Serial.print("IP: ");
Serial.println(WiFly.ip());
Serial.println("Starting Server...");
server.begin();
Serial.print("Server started, waiting for client.");
}
void loop()
{
delay(200);
WiFlyClient client = server.available();
if (client)
{
Serial.println("Client Found.");
// A string to store received commands
String current_command = "";
while (client.connected())
{
if (client.available())
{
//Gets a character from the sent request.
char c = client.read();
if (c=='#' || c=='\n') //End of extraneous output
{
current_command = "";
}
else if(c!= '\n')
{
current_command+=c;
}
if (current_command== "get")
{
// output the value of each analog input pin
for (int i = 0; i < 6; i++)
{
client.print("analog input ");
client.print(i);
client.print(" is ");
client.print(analogRead(i));
client.println("<br />");
}
}
else if(current_command== "hello")
{
client.println("Hello there, I'm still here.");
}
else if (current_command== "quit")
{
client.println("Goodbye...");
client.stop();
current_command == "";
break;
}
else if (current_command == "*OPEN*")
{
current_command == "";
}
}
}
// Give the web browser time to receive the data
delay(200);
// close the connection
client.stop();
}
}
This script is just a mini protocol I set up to test. Once connected with the wifly module you can send text such as "get" "hello" or "quit" and the wifly module should respond back.
Using Telnet I can successfully connect (the first time) and send commands to the Arduino including "quit" to terminate the connection (calls the client.stop() method). But when I try to reconnect though Telnet, it says the connection was successful, but on the Arduino it's still looping thinking the client is still false. What??
I know right, I'm getting mixed messages from Telnet vs Arduino. None of the commands work obviously since the Ardunio is still looping waiting for a client that evaluates to true. I'm going to take a look at WiFlyServer from the library I imported and see if I can dig up the problem, because somehow that server.available() method isn't finding new clients.
I am noticing a lot of TODO's in the library code....
So I found the reason for the problem. It was in the WiFlyServer.cpp file from the SparkFun library. The code that was causing the reconnect issue was in fact the server.availible() method. Right at the top of the method, there is a check:
// TODO: Ensure no active non-server client connection.
if (!WiFly.serverConnectionActive) {
activeClient._port = 0;
}
For some reason when I comment this out, I can connect and reconnect perfectly fine and everything works as it should. I will now dive into the library and see if I can fix this, I'm not exactly sure what this is doing, but it gets called when the server connection is not active and is somehow blocking subsequent connections. The problem with this solution is that the Arduino always thinks it has found a client since client and client.connected() evaluate to true even if one doesn't exist. Even client.available() evaluates to true right when the connection is terminated and the ghost "client" is found, but after that first run through the if-statement the ghost "client" is no longer available(). Even with this flaw it still picks up a new client when it comes along which is why it works.
How might I get to the root of this problem without using this commenting hack?
Are their any risks or future problems I might run into doing it this way?
What is the purpose of the block that I commented out in the first place?
Well, when you're calling client.stop(); how does the Arduino know whether the client has to start again?
Remember setup() executes only once.
Have you tried to include the following code in your loop to tell the Arduino to create the WiFly AdHoc network again? This may or may not work. I don't have one myself and haven't played with the Wifly shield but it's worth a try.
Remember to only ever execute the code once every time you need to connect again since it's sitting inside a loop that's always going to be running.
WiFly.begin(true);
Serial.println("WiFly started, creating network.");
if (!WiFly.createAdHocNetwork("wifly"))
{
Serial.print("Failed to create ad hoc network.");
while (1)
{
// Hang on failure.
}
}
I have a simple sketch on my Seeeduino Mega 1.22 which just displays the serial input on a LCD Display. Using lynx term and the arduino serial monitor works fine: sent input is being displayed. The trouble starts when I want to start serial communication between my Java programm, running in Eclipse on a Win7 x64 machine, and the Seeeduino. I'm using the RXTX x64 build. The programm is intended to send and receive some string.getBytes() via the open port. Receiving on the Java side works, but receiving on the Arduino side fails.
It seems that the problem is the proper Flow Control setting. I saw that some people had the same issue like here Issues receving in RXTX
But this solution does not work for me. If I set the FlowControl to None, than I get only a block icon on the display, indicating, that the serial connection has been established, but nothing else. If I set the FlowControl to RCTS_IN | RCTS_OUT, then I get the string bytes only on the display when I close the established connection.
Why is the data only send when I close the connection (Flushing the out stream did not help as well) ? What am I doing wrong with the Flow Controll settings?
This is the modified connect() method I'm using.
void connect(String portName) throws Exception {
CommPortIdentifier portIdentifier = CommPortIdentifier
.getPortIdentifier(portName);
if (portIdentifier.isCurrentlyOwned()) {
System.out.println("Error: Port is currently in use");
} else {
CommPort commPort = portIdentifier.open(this.getClass().getName(),
2000);
if (commPort instanceof SerialPort) {
SerialPort serialPort = (SerialPort) commPort;
serialPort.setSerialPortParams(115200, SerialPort.DATABITS_8,
SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);
try {
serialPort.setFlowControlMode(
// SerialPort.FLOWCONTROL_NONE);
// OR
// If CTS/RTS is needed
//serialPort.setFlowControlMode(
SerialPort.FLOWCONTROL_RTSCTS_IN |
SerialPort.FLOWCONTROL_RTSCTS_OUT);
} catch (UnsupportedCommOperationException ex) {
System.err.println(ex.getMessage());
}
serialPort.setRTS(true);
in = serialPort.getInputStream();
out = serialPort.getOutputStream();
(new Thread(new SerialWriter(out))).start();
serialPort.addEventListener(new SerialReader(in, this));
serialPort.notifyOnDataAvailable(true);
} else {
System.out.println("Error: Only serial ports are to use!");
}
}
}
Thanks in advance for your time
Solved it. It was not the buffer, as many suggested it. The problem was, that the Seeeduinos RST Switch on the board was set to automatic. Setting it to manual, solved the problem.
No Flow-Controll needed.