I am using python for capturing video for tello, I have tried the same code on Windows on my laptop and other ubuntu versions. But the video stream is not particularly working in ubuntu 22.04. While the drone is receiving stream on command from the system but the system is not able to receive any udp packets from the drone. (NOTE: THIS IS ONLY HAPPENING IN UBUNTU 22.04). I have tried ufw settings, allowing ports and all. But nothing seems to work. Please let me know you got any advice, thanks in advance.
Below is the code I am using
from djitellopy import tello
import cv2
me = tello.Tello()
me.connect()
print(me.get_battery())
me.streamoff()
me.streamon()
while True:
img = me.get_frame_read().frame
print(img)
img = cv2.resize(img, (360, 240))
cv2.imshow("live feed", img)
cv2.waitKey(1)
Related
I have an ATSAMD51 microcontroller integrated in a project-specific board which has also a xbee3 RF module. This xbee3 module is configured for Transparent Mode and the device type is 'router'. I can check this on the XCTU software.
Now, my goal is to install micropython on ATSAMD51 and then send commands to the xbee3 via UART since unfortunately I am not aware of any micropython library that can interact with the xbee. And just out of confusion, I don't want to use the xbee with micropython.
++++++++++++++ ++++++++++++++
++ ATSAMD51 ++ --UART--> ++ XBEE3 RF ++
++++++++++++++ ++++++++++++++
(running (transparent
micropython) mode)
I successfully installed the micropython on the ATSAMD51 and I managed to send commands to the xbee3 via UART. I know this works since when I do uart.write('1234') I can check on the XCTU console that the coordinator node receives this message.
However, If I try to send xbee3 AT commands, the uart.read() only gets 2 bytes at most.
Example:
screen /dev/tty.usbmodem0000000000001 115200 # enter the python REPL of the ATSAMD51
>>> from machine import UART, Pin
>>> uart = UART(5, rx=Pin('PB02'), tx=Pin('PB03'), baudrate=115200)
>>> uart
UART(5, baudrate=115200, bits=8, parity=None, stop=1, timeout=1, timeout_char=1, rxbuf=256, txbuf=256)
>>> uart.write('1234') # this actually transmits the message to the coordinator node
4
>>> uart.write('+++') # entering in command mode
3
>>> uart.read()
b'OK\r'
>>> uart.write('ATID\r')
5
>>> uart.read()
b'FO\r' # this should be FOO which is the device PAN ID
>>> uart.write('ATXX\r')
5
>>> uart.read()
b'ER\r' # this should be ERROR
Any command I send I always get only 2 characters + the \r (carriage return).
Thank you!
I've tried different baudrates and timeouts.
If I try to connect to the xbee directly from the computer via serial this works as expected. So I guess this is somehow related with the micropython UART configuration in the SAMD51?
The answer for the problem is here. A temporary fix is available here.
I am writing some programs using very simple/low-level ALSA audio output,
essentially doing something like:
snd_pcm_open(&handle, device, SND_PCM_STREAM_PLAYBACK, 0);
snd_pcm_set_params(handle, SND_PCM_FORMAT_S32, SND_PCM_ACCESS_RW_INTERLEAVED, width, sampleRate, 0, (width * NUM_PERIODS_PER_BUFFER * MICROSECONDS_IN_SECOND) / sampleRate);
and then, in a loop:
snd_pcm_writei(handle, buff, frames.frames_in_period);
This works as expected playing sound on local (Linux) loudspeakers.
Since this Linux machine is a headless server I need to move "somewhere else" (together with loudspeakers,of course) and access it through ssh (MobaXTerm on windows, actually) making it impossible to hear output.
Question is: is there a simple way to redirect audio over ssh tunneling?
I have seen trx, but it seems to be unavailable on windows.
It would be very important to avoid modifying playing program (changing output device is OK)
I setup a ScyllDB on my Debian 9.6 machine. When I run cqlsh I can connect to it and create tables, do queries etc..
Now I tried to write a simple program in C++ using the Datstax driver and it can't connect. It always blocks when it tries to connect.
The scylla package I installed is:
scylla | 3.0.11-0.20191126.3c91bad0d-1~stretch
cpp_driver is the current master from github: https://github.com/datastax/cpp-driver
Now I tried to run the examples/simple project which is included in the driver, so I assume that it should work, but it shows the same problem. I don't get any errors it just blocks
CassCluster* cluster = cass_cluster_new();
CassSession* session = cass_session_new();
char* hosts = "127.0.0.1";
cass_cluster_set_contact_points(cluster, hosts);
cass_cluster_set_protocol_version(cluster, CASS_PROTOCOL_VERSION_V4);
connect_future = cass_session_connect(session, cluster);
// here it blocks now forever...
er = cass_future_error_code(connect_future);
I also tried to run it on an Ubuntu 16.04 but it shows the same problem. Since the connect works, using the cqlsh I think it shouldn't be a configuration problem, but rather something with the cpp_driver.
I also traced the TCP connection, and I can see that the cpp_driver talks to the server, which looks similar to cqlsh conversation.
I finally found the solution for this issue. We were using cpp_driver 2.15.1 which apparently got some change in the even handling according to their release notes. When I downgraded to 2.15.0 the problem was gone and connection could be successfully established.
I'm new to mininet, I want to see the network topology using opendaylight(carbon) controller. I have tried command:
sudo mn --topo linear,3 --mac \
--controller=remote,ip=10.109.253.152,port=6633 \
--switch ovs,protocols=OpenFlow13,stp=1
And the opendaylight can successfully show the whole topology. And Then, I want to show the same result by using python code solely. However, it doesn't work.
#!/usr/bin/python
from mininet.net import Mininet
from mininet.node import RemoteController, OVSSwitch
from mininet.log import info, setLogLevel
from mininet.cli import CLI
def RemoteCon():
net = Mininet(controller=RemoteController, switch=OVSSwitch)
c1 = net.addController('c1', ip='10.109.253.152',port=6633)
h1 = net.addHost('h1')
h2 = net.addHost('h2')
s1 = net.addSwitch('s1')
net.addLink(s1, h1)
net.addLink(s1, h2)
net.build()
net.start()
CLI(net)
net.stop()
if __name__ == '__main__':
setLogLevel('info')
RemoteCon()
Oh, by the way, does the switches have default forwarding functionality? Sometimes, I have hosts and switch connected to each other and hosts can ping each other while running above code, h1 cannot ping h2 and vice versa.
Thanks in advance.
I'm assuming you are using the l2switch feature in OpenDaylight.
if you search this forum, you'll find others complaining of inconsistent
connectivity when using l2switch. You are probably hitting bugs, but
after a restart of OpenDaylight, it might be ok. By default, with l2switch
it should learn the links of the topology, and create the flows to allow
all hosts to ping every other host.
as for your python script to run mininet, I don't see anything obvious.
Can you look in the OpenDaylight karaf.log for any clues? Or check the
OVS logs for other clues? If you are just simply not seeing anything
in the topology viewer, then my guess is that the OVS is not connecting
to OpenDaylight at all.
One thing to double check. I don't know how the python script is deciding
which openflow version to use, but maybe it's using 1.0 and that's the
big difference from your command line, which sets it to 1.3?
I see that you missed starting your switch to communicate with the controller. Try
s1.start([c1])
This defines which controller the switch is connected to. Hope this helps.
You should give protocols parameter to addSwitch function as command line:
s1 = net.addSwitch('s1',switch=OVSSwitch,protocols='OpenFlow10')
I'm trying to program (upload new messages to) a scrolling LED badge via python on Linux instead of via the windows exe. I've got a capture of a successful upload via the windows app that I'll use as a template, but at the moment I'm having trouble writing anything at all to the device.
When I run my script, I get an assertion error, which I assume means that no OUT endpoints have been found. lsusb seems to corroborate this, but I could be mistaken. This is basically straight from the pyusb tutorial with alternate_setting removed from intf because it was causing a pipe error and is apparently not necessary.
intf = usb.util.find_descriptor(cfg, bInterfaceNumber = interface_number,)
ep = usb.util.find_descriptor(
intf,
# match the first OUT endpoint
custom_match = \
lambda e: \
usb.util.endpoint_direction(e.bEndpointAddress) == \
usb.util.ENDPOINT_OUT
)
assert ep is not None # < assertion error
In case it helps, lsusb -vv for the LED badge: http://bpaste.net/show/biixy6e38A71WlCw7euU/
Any guidance would be much appreciated - I'm entirely new to USB protocol, and not great at python either.