Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 18 12:02
    Fabien-B commented #2740
  • Jun 18 12:01
    Fabien-B synchronize #2740
  • Jun 16 16:53

    gautierhattenberger on fix-gdb_check

    (compare)

  • Jun 16 14:04
    gautierhattenberger commented #2740
  • Jun 16 14:03
    gautierhattenberger commented #2740
  • Jun 16 13:24

    Fabien-B on master

    [fix] add which command to test… (compare)

  • Jun 16 13:24
    Fabien-B closed #2741
  • Jun 16 12:13
    gautierhattenberger opened #2741
  • Jun 16 12:13
    gautierhattenberger review_requested #2741
  • Jun 16 12:13
    gautierhattenberger labeled #2741
  • Jun 16 12:12

    gautierhattenberger on fix-gdb_check

    [fix] add which command to test… (compare)

  • Jun 16 12:10

    gautierhattenberger on fix-gdb_check

    (compare)

  • Jun 16 07:06
    Fabien-B commented #2740
  • Jun 16 06:52
    Fabien-B synchronize #2740
  • Jun 15 15:16

    gautierhattenberger on master

    [rtos_mon] fix computation of C… (compare)

  • Jun 15 15:16
    gautierhattenberger closed #2739
  • Jun 15 13:52
    Fabien-B opened #2740
  • Jun 14 10:42

    gautierhattenberger on master

    Added new flight plan to safely… (compare)

  • Jun 14 10:42
    gautierhattenberger closed #2738
  • Jun 14 10:20
    EwoudSmeur commented #2738
Hector Garcia de Marina
@noether
it should be okei I guess? Or shall I wait or do something differently
Gautier Hattenberger
@gautierhattenberger
@noether there is only a single thread like for rotorcraft, so no real FBW part. The assembly of the AP modes, including sub-modes for NAV are done in the autopilot XML file. I think that direct control can be achieve with just the command mixing in airframe file and mode definition.
For the navigation interface, I tried something new, with "register" functions to tell which function should be used for goto, circle, etc. I not sure this is so nice after all, but it is still more flexible than other firmwares at the moment.
Hector Garcia de Marina
@noether
" I think that direct control can be achieve with just the command mixing in airframe file and mode definition" Yes, I agree with it
"I tried something new, with "register" functions to tell which function should be used for goto, circle, etc. I not sure this is so nice after all, but it is still more flexible than other firmwares at the moment." Yes! I think that after all the vehicles that we are supporting, and different algorithms, I really think it is a good idea (hopefully let see whether we can execute it well xD)
by the way, what is the status of the new GCS ? Can I give it a go or contribute to it? I wanted to add the trajectories (drawn on the map, instead of using the python app) if smb uses the GVF (I did not know how to do that in ocaml xD)
Fabien-B
@Fabien-B
@noether The new GCS is not quite ready yet, but it start to be usable !
https://github.com/Fabien-B/PprzGCS
You can install it easily on Ubuntu 20.04 with deb releases, and it should be "not so painful" to build it on 18.04.
The code is not very stable yet, I sometimes do huge refactorings, but its getting better.
I wanted to add the possibility to add python plugins. I know its possible but I haven't succeed yet. It would be a great (and easy) way to add "specific" widgets, ...
Hector Garcia de Marina
@noether
@Fabien-B yeah, I cloned it already!
I think I will start use it with the rovers since it is less sensitive than the planes
for me what is exciting is that I can program in C++, so I can add functionalities that I wanted time ago (especially about swarms). Python apps are okei, but it is not the same to have them integrated into the GCS.
I did not know that you have made this huge progress with the GCS
Fabien-B
@Fabien-B
I absolutely didn't think about rovers, so it may be painful :smile:
If you want, there is a "silent" mode, that prevent the GCS to send any messages (just for visualization purpose).
What I mean about python is that, providing a good C++ interface (yet to be made...), python bindings can be generated, so you would really call C++ functions from your python code.
ou can then interact with widgets the same way you would do in C++, so it would be really integrated in the GCS.
Then Qt can "execute"this python code.
Look at what is done in QGIS for example. You cannot tell the difference between python stuff and "original" stuff!
Hector Garcia de Marina
@noether
ohhh I see what you mean about python
thanks for the advice about the silent mode
well, the rover right now will need the same as the aircraft
and display the same information
just the messages will be different (but the same info to be displayed)
as it happens now, the idea is to integrate the rovers with the rest of the vehicles, at least in the GCS
OpenUAS
@OpenUAS
@noether you wrote" the idea is to integrate the rovers with the rest of the vehicles". Just out of curiosity, what is different with a Rover and an aircraft?, IMHO a rover is nothing else than a taxing airframe without wings right? Steering with rudder, this mixing in you airframe. I'm no RC car guy, (had a few racing buggies in my youth). I can offer to let some airframes with tricycle landing gear taxi around a huge parking lot if it help you.(I just limit the throttle and remove wings) if you want.
BTW I have quite some Digimesh XBee's unused geathering dust, you can have m for free if you need.
Hector Garcia de Marina
@noether
@OpenUAS sure, the rover can have an arbitrary velocity (zero and even backward), and it is purely a 2D vehicle. Sure, the rover can work as a fixed-wing by fixing the velocity for example. However, I will treat them as rovers (now as a "hobby project"), so they can have their own guidance, react to the terrain, other applications on the ground (collaborative transportation or sensing), and eventually to have ground and air vehicles collaborating
thanks for the offer about the XBees! Are they the old good one S1 ? xD
right now I have plenty of radios, anyway, thanks a lot for the offer
hiro1117
@hiro1117
image.png
Hi everyone. I'm new to paparazzi and trying to use paparazzi v5.14.0 stable. but when I executed $make, I got this error. I tried on macOS and ubuntu18.04 and got the same error. It may be basic... but please can anyone tell me what is wrong ..?? Thank you
Gautier Hattenberger
@gautierhattenberger
@hiro1117 I'm not sure about the Mac, but which procedure have you used to install on Ubuntu ?
You can try this one: https://paparazzi-uav.readthedocs.io/en/latest/quickstart/install.html#
Fabien-B
@Fabien-B
@hiro1117 Also, use make -j1, as there was some errors in dependencies, and it might fail sometimes building in parallel.
Also, latest stable is v5.18. Unless you have a specific reason to use an older version, you might consider using this one, some bugs has been fixed since.
hiro1117
@hiro1117

@gautierhattenberger @Fabien-B Thank you for reply!
I got the paparazzi from github: https://github.com/SUNY-BU-Software-Systems-Research-Group/paparazzi
I'm trying to run a clang plugin created for v5.14: https://github.com/SUNY-BU-Software-Systems-Research-Group/PaparazziBF/tree/main/PBF-Detector
Before get this clang plugin, I need paparazzi v5.14.0 running, but I can't...

@Fabien-B I tried $make -j1, but it returned the same error.
I have no idea why "No rule to make target 'libpprzlink-install' occurred..

Fabien-B
@Fabien-B
@hiro1117 The official paparazzi repository is here: https://github.com/paparazzi/paparazzi/
Do a make clean before retrying, to be sure there is nothing left from the previous failed build.
And follow the link Gautier gave you, to be sure. I don't know for Mac, but it should work on Ubuntu (be careful, some instructions are specific for Ubuntu 18.04/20.04)
Gautier Hattenberger
@gautierhattenberger
@hiro1117 You can also check the folder sw/ext/pprzlink, if it is empty the submodule update failed
If it is the case, you can try to initiate and update it by hand with git submodule --init --recursive sw/ext/pprzlink from the root folder of paparazzi
hiro1117
@hiro1117
@gautierhattenberger @Fabien-B Thank you so much for your help!!
After checking sw/ext/pprzlink, I found a lack of folders in the directory and other directory, so I installed whole paparazzi v5.14.0 again
I also realized I couldn't properly installed "ocamlbuild" and installed it.
Then I got this.. so I will try uninstall the ocaml and install required-version ocaml
image.png
RobertG333
@RobertG333
Hello everyone, I did a couple of (successful) test flights these days, using a FunJet airframe equipped with the Eagletree airspeed sensor. Now, when testing in rough gusty wind conditions the airframe wouldnt follow its navigation path too good but instead performed wide circles on the downwind legs and couldnt keep circles round. I suspected and moderately changed h_ctl_course_pgain but without effect. Further I often noticed more or less heavy wing fluttering (around the longitudinal axis). What would be the right tuning strategy? my airframe file for the Funjet is based on the one from /examples, without any changes when it comes to gains
Gautier Hattenberger
@gautierhattenberger
@RobertG333 Do you have an idea of the wind speed and the aircraft airspeed ? If the wind is really strong and the max bank angle saturated, there is not much you can do. So maybe you can first look at the logs to check if the roll angle is correctly tracking the setpoint and if it is saturated.
Which airframe file are you using exactly (and which version of paparazzi) ? I can't find a funjet in the examples folder.
RobertG333
@RobertG333
did use 5.16 on my notebook that day. There is a funjet_lisa_m airframe file in \examples., btw how can I update a pprz installation and be sure every single file is updated to the latest release (5.18) ?
RobertG333
@RobertG333
oh sorry, I just recalled "git describe" : 5.15 devel 230
RobertG333
@RobertG333
wind speed must have been around 10m/s while airspeed was ~ 15m/s
Gautier Hattenberger
@gautierhattenberger
I can see a microjet_lisa_m instead of funjet. It is the same type of vehicle, but funjet is flying faster. Maybe the gains are not optimal. Also, I can see that the ROLL_MAX_SETPOINT is only 35, which may not be enough with such strong wind. You can probably go up to 45 deg.
RobertG333
@RobertG333
@gautierhattenberger correct, the microjet file is exactly the same like mine when it comes to gains and setpoints. One difference: Funjet got an airspeed sensor, AUTO_AIRSPEED_SETPOINT is 13m/s, NOMINAL_AIRSPEED is 13m/s, too. Guess increased airspeed setpoint plus a higher roll setpoint could make a difference in stormy downwind legs. Did you ever go for a higher bank angle than 45 deg ?
RobertG333
@RobertG333
@gautierhattenberger leaves the fluttering of the roll axis... it became more apparent in gusty weather conditions. Can you recommend to change gains like roll_attitude_gain or roll_rate_gain for a smoother slower reaction ?
Gautier Hattenberger
@gautierhattenberger
If the airspeed is high enough, you can bank a bit more I guess, the funjet should be strong enough for 50 or 60 deg. But with a faster flight speed, not sure it will help a lot. For the roll damping, you can try to increase a bit the derivative gain (roll_rate_gain) and lower the proportional (roll_attitude_gain). Check that you don't loose to much precision in the setpoint tracking. If the noise on gyro is strong, you might have have some troubles as well.
RobertG333
@RobertG333
@gautierhattenberger Thx a lot, Gautier ! this sounds like a tuning procedure, cant wait to test it and will let you know about results. Good penetration in strong wind conditions is mandatory for my purpose.
RobertG333
@RobertG333
will also test a Microjet soon, which is about to be finished. I expect it to be even more agile and faster compared to the Funjet (which is a really good platform to start with)
OpenUAS
@OpenUAS
@noether No not the XBee Pro S1, that is the only one we settled on to still use of those series. But nice XTend for which I paid a fortune...but likely very obsolete with the chips available today. BTW thank for giving some insight in what you do with the rover, now I see what is needed.
OpenUAS
@OpenUAS
Anyone successfully used PPM RC input in a Chibios board?
Gautier Hattenberger
@gautierhattenberger
@OpenUAS not tested since a long time (if anyone used it at all...)
Islam SEDDIK
@Medislamseddik_twitter
Hi im about to buy the kroozSD card, I wanted to know if I can control it with any usb controller, if so (what configuration should I do?)
usb joystick *
OpenUAS
@OpenUAS
@Medislamseddik_twitter if you wan to control kroosSD flightcontroller with USBjoystick you do need a connection to your drone still(obviously) So e.g. a XBEE modem, a 3DR modem , whatever connection. You need the to connect your USB joystick in the GCS computer (where you uploaded paparazzi to your flight controller) then set in your airframe file this line <module name="radio_control" type="datalink"/>. For the rest browse the Wiki for more information e.g. https://wiki.paparazziuav.org/wiki/Joystick
@gautierhattenberger thanks for the info on PPM on Chibios, I'm prepared to expect some serious debugging then... :)