Re: [Paparazzi-devel] 4.9 rotorcraft_cam.xml

[Andrius Batalauskas]

Oups, sorry. Should have mentioned the version. We are experimenting with 4.9 and 4.2. But I mean this one:
https://github.com/paparazzi/paparazzi/blob/v4.2/sw/airborne/firmwares/rotorcraft/commands.h

With an additional "_in_flight" check (see last attachment) pitch and roll are shut off at ground level. Just like yaw is.

Now we got another issue: Yaw takes quite some time to react. No idea why. I will look into that tmw.

Cheers!
Andrius

Am 30.01.2013 22:45, schrieb Felix Ruess:

Hi Andrius, 

could you please make a pull request on github, or send a patch if you prefer that?

It is also quite unclear on which version you based this... seems like an old one.

Cheers, Felix

On Wed, Jan 30, 2013 at 10:40 PM, Andrius Batalauskas <address@hidden> wrote:

Ok, found the reason.

For people facing the same problem:

-Check the PPM. The signals were fluctuating way too much in our case.
-Also adjust command.h (see attached). The default behaviour should be changed imho.

Greetings!
Andrius

Am 29.01.2013 18:48, schrieb Andrius Batalauskas:

Hi Gautier,

ok, so this would be far more work than I hoped for. *Sigh*
Since we hand in our project by the end of next week this will be hard to do until than. Anyway, thanks for your patience.

Still we got another issue with our arming sequence (don´t wanna set a new topic here):
When we disarm the motors (by pushing the left stick to the left) we need to take care not to move the stick up or down.
The default behaviour should be: "don´t accept any movement commands while running at minimum speed". Otherwise the copter may hit the next wall when we shut it off.

Is there a treshhold for this? If so: where?

Greetings,
Andrius

Am 28.01.2013 15:00, schrieb Gautier Hattenberger:

Hi Andrius,

About the rotorcraft_cam module: it as been made to control a camera mounted on a rotorcraft frame using the the heading of the vehicle to control the pan, and optionally a servo to control the tilt motion.
The tilt motion is not compensating for the tilt and roll motion for two "official" reasons :
- having the camera always moving because of a bad combination of servo/stabilization_control usually produces more blurry images than doing nothing,
- it was a light version of the cam module that can do more things including absolute angle stabilization.

We can also consider a more realistic point of view:
- this module is a quick and dirty hack I wrote in 2009 when having a stable flight was already a challenge.
- the generic cam control module is a even older piece of code that is only working for fixed-wing aricraft.

As a conclusion, I would say, that if someone wants to work on the camera control, the best is to make the cam module working properly on all firmwares, and if possible make the rotorcraft_cam a special case of the generic module so it can be removed.

Gautier

Le 25/01/2013 18:10, Andrius Batalauskas a écrit :

Hi folks,

we got odd behaviour using our Lisa/M1 rotorcraft and a cam. When we plug in the system the servo rotates from 0° to 90°, -so that one seems to work. But though we defined our cam as "HEADING" it´s not moving when we pitch our rotorcraft. However the message output does change but for yaw values only (see pic).
The yaw value should stay zero and the tilt value should vary from 0° to 90° at least, right? Out servo should even allow 0° to 180° ranges but haven´t tried it yet.

Greetings,
Andrius

Am 16.01.2013 21:24, schrieb Andrius Batalauskas:

Cool, thanks. I´ll try that out!

Am 16.01.2013 17:24, schrieb Felix Ruess:

Basically, yes...
You should remove the [STOP|MIN|MAX]_MOTOR the MOTOR_MIXING section and use the min/neutral/max of each servo for that.

So the servo min value is sent for a stopped motor, neutral is what is sent to motor in idle, max is max...

E.g. in your case: <servo name="SE" no="0" min="1000" neutral="1200" max="2100"/>

See also http://lists.gnu.org/archive/html/paparazzi-devel/2012-10/msg00181.html

Cheers, Felix

On Wed, Jan 16, 2013 at 5:14 PM, Andrius Batalauskas <address@hidden> wrote:

Thx, the beeping sound is gone
BUT
only one of the motors is working when armed. Another one moves a little, the other two are doing nothing at all. I need to pitch in ordner to make all of them rotate. It´s working fine with 4.2.
Do I have to increase the min/neut/max values in <servos driver="Pwm"> for making it work? Those values are taken from our own configuration not from the example file.

Am 16.01.2013 13:47, schrieb Felix Ruess:

Hi Andrius,

it seems you commented out the call fun="motor_mixing_run(autopilot_motors_on,FALSE,values)" in the command laws and the motor mixing section. So the output is never updated and probably zero sent.

Depending on what motor controllers you use, they might beep because the don't get a valid signal...

See https://github.com/paparazzi/paparazzi/blob/master/conf/airframes/examples/quadrotor_lisa_m_2_pwm_spektrum.xml as an example.

Cheers, Felix

On Wed, Jan 16, 2013 at 12:31 PM, Andrius Batalauskas <address@hidden> wrote:

Hi and thx for the feedback guys!

Motor delay and (un-)arming in different corners is working fine now with 4.2 (for those who have the same problem: see the two "autopilot..." files attached).

Still we would like to use 4.9 if we can. Simply because it´s newer, shinier and has better support for cams. ;-)
However when uploading our xml configuration (see the one attached) the motors keep beeping and twitching every two seconds.  I don´t speak Paparazzi fluently yet, so what does it say?
GCS can still be started though (see pic).

Greets!
Andrius

Am 09.01.2013 19:30, schrieb Felix Ruess:

Hi,

Regarding the arming sequence:

1) There is currently no support to arm/unarm in different corners.

You could easily write a new arming sequence by copying/renaming https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/firmwares/rotorcraft/autopilot_arming_yaw.h and replacing YAW_STICK_PUSHED() as appropriate and then including this file in autopilot.c instead.

2) The delay to arm/disarm is currently still fixed to AUTOPILOT_MOTOR_ON_TIME (40).

This value represents the number of received rc frames during which the arming condition must be true. So with a usual rc receiver freq of ~40Hz you get ~1s.

In master I changed this define to MOTOR_ARMING_DELAY and made it configurable. To change it to 0.5s add to your airframe file (to any section without a prefix, e.g. misc or autopilot or to the firmware section):

<define name="MOTOR_ARMING_DELAY" value="20"/>

(As Eduardo already pointed out the ACTUATORS_START_DELAY is used to have delay until the first commands are sent to the motor controllers (mkk, skiron or asctec).)

Regarding booz_cam:

3) In master the rotorcraft_cam.xml module should work with both LPC21xx and STM32.

Eduardo, if i see that correctly your changes are basically a hack and also will only work if you use PWM motor controllers and not with MKK or asctec controllers.

It also would make much more sense to implement the cam stablization mode in master using the state interface.

Or even better refactor this and create generic stabilization functions (that also take the camera mounting orientation into account) which can then be used by the fixedwing and rotorcraft code.

Cheers, Felix

On Wed, Jan 9, 2013 at 4:48 PM, Eduardo Lavratti <address@hidden> wrote:

BTW, i created STABILIZE MODE that use PITCH and ROLL angles to stabilize the cam.
you can adjust the tilt  angle offset using settings/CAM menu;

ACTUATOR_DELAY is only a delay to initialize the motor module not the start motor procedure.
If i remember, the actuator delay only work with MKK, asctec module (i2c modules), so the pwm supervision not use this delay.

On Wed, Jan 9, 2013 at 12:43 PM, Andrius Batalauskas <address@hidden> wrote:

Happy New Year folks!

(Liza/M 1.0/Quadcopter/v4.2.0_stable-2-gd155873)

1) A question concerning the standard arming procedure for the motors (throttle min and full yaw). The motors start and shut down after pushing the yaw both to the left or the right with a time lag of 1 sec.
Is it possible to alter the sequence to start the motors only by pushing yaw to the left and shut them down only by pushing the yaw to the right?

2) Additionally, I want to reduce the time lag. Is the 1 sec standard or just a result of my configuration? Can I use the parameter ACCTUATOR_DELAY_TIME within the airframe to reduce the time lag during arming sequence? Which values are appropriate? Any suggestion is appreciated!

3) We are still trying to implement an automatic heading cam even if it takes some C-Code modifications in the end.
The idea is to "tilt" the cam manually (let´s say with up/down buttons from GCS) and later automatically by reading the pitch value from our Quad. So no panning whatsoever.
With the configuration files attached I get the following error while compiling:

firmwares/rotorcraft/main.c: In function 'telemetry_periodic':
firmwares/rotorcraft/main.c:176:1: error: 'booz_cam_pan' undeclared (first use in this function)
firmwares/rotorcraft/main.c:176:1: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [/home/and/papa_42/var/Quad_LisaM_HSB/ap/firmwares/rotorcraft/main.o] Error 1
make[1]: Leaving directory `/home/and/papa_42/sw/airborne'
make: *** [ap.compile] Error 2
make: Leaving directory `/home/and/papa_42'


Any ideas?

Cheers!
Andrius

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

E-Mail ist virenfrei.
Von AVG überprüft - www.avg.de
Version: 2013.0.2805 / Virendatenbank: 2637/5999 - Ausgabedatum: 31.12.2012
Die Virendatenbank sind veraltet.

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

E-Mail ist virenfrei.
Von AVG überprüft - www.avg.de

Version: 2013.0.2890 / Virendatenbank: 2638/6034 - Ausgabedatum: 15.01.2013

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

E-Mail ist virenfrei.
Von AVG überprüft - www.avg.de
Version: 2013.0.2890 / Virendatenbank: 2638/6037 - Ausgabedatum: 16.01.2013

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

E-Mail ist virenfrei.
Von AVG überprüft - www.avg.de
Version: 2013.0.2890 / Virendatenbank: 2638/6037 - Ausgabedatum: 16.01.2013

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

E-Mail ist virenfrei.
Von AVG überprüft - www.avg.de
Version: 2013.0.2890 / Virendatenbank: 2639/6053 - Ausgabedatum: 23.01.2013

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

E-Mail ist virenfrei.
Von AVG überprüft - www.avg.de
Version: 2013.0.2890 / Virendatenbank: 2639/6053 - Ausgabedatum: 23.01.2013

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

E-Mail ist virenfrei.
Von AVG überprüft - www.avg.de
Version: 2013.0.2890 / Virendatenbank: 2639/6068 - Ausgabedatum: 30.01.2013