if you are running your program on a host in the ground network, then the easiest is to publish that message on the Ivy bus: https://wiki.paparazziuav.org/wiki/Ivy
you can e.g. do that easily from a python script using https://github.com/paparazzi/pprzlink/blob/master/lib/v1.0/python/ivy_msg_interface.py
you can e.g. do that easily from a python script using https://github.com/paparazzi/pprzlink/blob/master/lib/v1.0/python/ivy_msg_interface.py
ah, so we are talking about a Parrot drone?
video you can receive via RTP, the command you send up would be via the normal PPRZ protocol
depending on what exactly you want to send you either have to create your own message or use one of the existing ones
see http://docs.paparazziuav.org/latest/paparazzi_messages.html#DATALINK_CLASS
video you can receive via RTP, the command you send up would be via the normal PPRZ protocol
depending on what exactly you want to send you either have to create your own message or use one of the existing ones
see http://docs.paparazziuav.org/latest/paparazzi_messages.html#DATALINK_CLASS
there is e.g. the possibility to issue high level commands like goto position, move at velocity, etc...
or more low level attitude commands
you could put the quadrotor in guided mode and send
https://github.com/paparazzi/paparazzi/blob/master/sw/ground_segment/python/guided_mode_example.py
GUIDED_SETPOINT_NED messages, seehttps://github.com/paparazzi/paparazzi/blob/master/sw/ground_segment/python/guided_mode_example.py
Hello all, I am currently trying to compile the paparazzi source code into a shared library, but am having difficulty in making this work. Does anyone here have experience in doing this or could provide guidance on where the appropriate arguments could be added to the build? I tried multiple places as early in the build however could not get it to create the shared library.
@flixr, I am trying to make the airborne and simulation a shared library. The reason for this is to eventually port the paparazzi functionality to java. My desire is to call things over jni and eventually move the airborne modules over to java, and continue to use JSBsim through jni for simulation purposes.
you could try to add it to https://github.com/paparazzi/paparazzi/blob/master/conf/Makefile.nps
maybe something like
$(OBJDIR)/simsitl.so : $($(TARGET).objs)
$(Q)$(CXX) $(CXXFLAGS) -shared -o $@ $($(TARGET).objs) $(LDFLAGS)
not sure though if it really makes sense to compile all that into one lib
@adamczer you would probably need to #ifdef out the main in https://github.com/paparazzi/paparazzi/blob/master/sw/simulator/nps/nps_main.c#L92 and set the options yourself and then periodically call
nps_main_periodic
I have to admit that I don't quite understand the reason for calling this from java though...
but then I'm not familiar with Java/C integration at all...
The nps main init/ execution cycle would be replaced by a Java execution. All the calls that exist from this point of entry could then be called directly allowing for testing of framework prior to completing a full Java implementation. Its basically so I can swap out one component at a time and make sure I did not mess up something while porting. Does that make more sense?
all things is ok but in last step when i want to creat shortcut
after double clicking it say unable to execute
whats the prop?
@tokiyoki it should be possible although it is not really documented.
relevant configuration files are: https://github.com/paparazzi/paparazzi/blob/master/conf/boards/stm32f4_discovery.makefile and https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/boards/stm32f4_discovery.h
you just need to change the board type for
relevant configuration files are: https://github.com/paparazzi/paparazzi/blob/master/conf/boards/stm32f4_discovery.makefile and https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/boards/stm32f4_discovery.h
you just need to change the board type for
stm32f4_discovery in the ap target of you airframe file.
There was some effort to port paparazzi to that a long time ago but it was not finalized
As libopencm3 has support for the f3 by now the port should be quite streight forward if you know how to do embedded programming :)
Autocorrect hits once again:)
Hello,
I am using the Optitrack system at TU Delft and have some problems with flying at higher altitudes. To be more precise, when I'm flying the Bebop between 2.5-3 meters fix alt. the altitude can vary ALOT when going from one waypoint to another and the drone can also completely deviate from the flight plan and start accelerating into the net (both on the sides and in the roof). At lower altitudes 1-2 m everything is working fine. Does anyone have any idea what can cause this?
I am using the Optitrack system at TU Delft and have some problems with flying at higher altitudes. To be more precise, when I'm flying the Bebop between 2.5-3 meters fix alt. the altitude can vary ALOT when going from one waypoint to another and the drone can also completely deviate from the flight plan and start accelerating into the net (both on the sides and in the roof). At lower altitudes 1-2 m everything is working fine. Does anyone have any idea what can cause this?
@dgberry1 message definitions are in the pprzlink repo: https://github.com/paparazzi/pprzlink/blob/master/message_definitions/v1.0/messages.xml
in paparazzi this is added in sw/ext/pprzlink/message_definitions/v1.0/messages.xml and copied to var/messages.xml on make
in paparazzi this is added in sw/ext/pprzlink/message_definitions/v1.0/messages.xml and copied to var/messages.xml on make
and yes, you need to call the toplevel make after changing messages
if you put a messages.xml file in conf/, that will be used instead...