[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Paparazzi-devel] Joystick question
From: |
Martin Mueller |
Subject: |
Re: [Paparazzi-devel] Joystick question |
Date: |
Thu, 12 May 2011 12:42:12 +0200 (MEST) |
Hi Gautier,
> I thought you were using the point-to-point mode.
that's what I do, <type="xbee_api">. The <link="broadcasted"> tag in the
messages.xml makes XBee API mode use the broadcast just for the so-marked
messages.
> So you're right, api broadcast and transparent should be alike, but
> with this, you can only fly one aircraft at a time trough datalink,
> right ?
Not really. The idea behind API mode and RC_3CH was not only joystick but to
have a separate RC transmitter with TWOG, XBee modem and an alphanumeric LCD
inside to control the plane in manual/auto1 and have some essential information
(e.g. voltage, altitude) directly from the plane on the transmitter. A (maybe
optional) gcs/laptop would have the "normal" point-to-point API connection.
The RC_3CH message does not contain a target but a source address as all
messages. RC transmitters do not have a programmable/powerful HMI (at least
they did not have 2 years ago) to choose a target aircraft ID nor do you want
to re-program it all the time. They would simply send a well defined number as
source address and the aircraft would lock on that (like RC "binding"),
configured through conf.xml and/or the gcs. If you want to fly multiple
aircrafts at the same time you could choose between a couple of source
addresses with buttons on the transmitter.
Did a transmitter prototype but in the end it was a time consuming, expensive
device with a lot of mechanical work to do. Find some (outdated) code in
sw\in_progress\rctx\main_rctx.c New transmitter designs have a lot of user
programmable possibilites, maybe it is worth to reconsider
(http://code.google.com/p/th9x/).
The link.ml needs an update to be able to send XBee API (broadcast) messages
with other values than "my_addr = ref 0x100" for controlling multiple aircrafts
concurrently with multiple joysticks.
Martin
> ac_id field, so it should work with multiple aircraft, except that the
> bandwidth is maybe too small to do that safely...
>
> Gautier
>
> On 11/05/2011 22:33, Martin Mueller wrote:
> > Hi Gautier,
> >
> >> I think that sending the RC_3CH with the XBee api mode takes probably
> >> more bandwidth than sending the RC_4CH with transparent mode.
> >
> > why do you think so? XBee API broadcast does not need a target address
> > nor an acknowledge.
> >
> > That's what I get for XBee API broadcast of a RC_3CH (sent by
> > ctrlstick.c):
> > http://paparazzi.enac.fr/wiki_images/Xbee_api_broadcast.jpg
> >
> > Same for XBee transparent (more than 100us longer):
> > http://paparazzi.enac.fr/wiki_images/Xbee_transparent.jpg
> >
> > The acknowledge of the transparent mode message takes 200us gap +
> > 400us message:
> > http://paparazzi.enac.fr/wiki_images/Xbee_transparent_w_ack.jpg
> >
> > With a bad link you get 3x low level repeat:
> > http://paparazzi.enac.fr/wiki_images/Xbee_transparent_no_ack.jpg
> >
> > Which takes up to 8.2ms + 0.6ms = 8.8ms in total. With a 20ms repeat
> > rate you should be safe as you need max 45% bandwidth for the uplink.
> > You have to be careful with the downlink rate not to fill up the link,
> > though.
> >
> > Sorry for the crappy pictures, have no Windows box to read out the
> > oscilloscope.
> >
> > Martin
> >
> >> For now,
> >> it is not possible to use the RC_3CH with input2ivy as it doesn't have
> >> an ac_id field that is mandatory with it.
> >> As Martin said, it is much better to send the mode each time. When you
> >> have a joystick and that you want to use buttons to set the mode, it is
> >> possible by declaring a "variable". Look in the file
> >> attack3_booz_nav.xml for an example.
> >> I will probably make a proper DTD file and a wiki page some day to
> >> explain how it works...
> >>
> >> Gautier
> >>
> >> On 08/05/2011 08:25, Martin Mueller wrote:
> >>> Hi Chris,
> >>>
> >>> the original idea for joystick was to have a very short transmission
> >>> time. It turned out that the first implemented RC_3CH message takes
> >>> 1ms to transmit as XBee broadcast message (measured with a HF meter).
> >>> Most of that time is guard time, addressing and checksums. An
> >>> additional byte only takes some tens of microseconds to transmit.
> >>>
> >>> The mode information is vital to the message. If mode change
> >>> information is lost and the aircraft interprets auto1 controls as
> >>> manual controls you could have an issue.
> >>>
> >>> For RC_3CH the mode was encoded into the throttle byte. As long as you
> >>> do not want to do 3D hovering UAVs should be fine with a 6-bit only
> >>> throttle resolution.
> >>>
> >>> Martin
> >>>
> >>> On 08.05.2011 07:44, Chris wrote:
> >>>> Hi.
> >>>> I finally made everything work well with my Saitek Aviator and i also
> >>>> made some changes
> >>>> that aim in reducing modem bandwidth so i need to ask for your opinion
> >>>> on those.
> >>>>
> >>>> 1) added a variable to the rc_datalink.h and .c files
> >>>> ("datalink_pprz_mode") that controls the autopilot's mode:
> >>>>
> >>>> extern volatile int8_t datalink_pprz_mode;
> >>>>
> >>>> #define NormalizeRcDl(_in, _out) { \
> >>>> _out[RADIO_ROLL] = (MAX_PPRZ/128) * _in[RADIO_ROLL]; \
> >>>> Bound(_out[RADIO_ROLL], MIN_PPRZ, MAX_PPRZ); \
> >>>> _out[RADIO_PITCH] = (MAX_PPRZ/128) * _in[RADIO_PITCH]; \
> >>>> Bound(_out[RADIO_PITCH], MIN_PPRZ, MAX_PPRZ); \
> >>>> _out[RADIO_YAW] = (MAX_PPRZ/128) * _in[RADIO_YAW]; \
> >>>> Bound(_out[RADIO_YAW], MIN_PPRZ, MAX_PPRZ); \
> >>>> _out[RADIO_THROTTLE] = ((MAX_PPRZ/255)*(127+ _in[RADIO_THROTTLE])); \
> >>>> Bound(_out[RADIO_THROTTLE], 0, MAX_PPRZ); \
> >>>> _out[RADIO_MODE] = MAX_PPRZ * (datalink_pprz_mode - 1); \
> >>>> Bound(_out[RADIO_MODE], MIN_PPRZ, MAX_PPRZ); \
> >>>> }
> >>>>
> >>>> 2) The variable was added to the settings.xml file and the joystick
> >>>> .xml
> >>>> file was configured to change the variable like this:
> >>>>
> >>>> <message class="ground" name="DL_SETTING"
> >>>> on_event="stick_right_button">
> >>>> <field name="index" value="IndexOfSetting(datalink_pprz_mode)"/>
> >>>> <field name="value" value="2"/>
> >>>> </message>
> >>>>
> >>>> <message class="ground" name="DL_SETTING"
> >>>> on_event="stick_center_button">
> >>>> <field name="index" value="IndexOfSetting(datalink_pprz_mode)"/>
> >>>> <field name="value" value="1"/>
> >>>> </message>
> >>>>
> >>>> <message class="ground" name="DL_SETTING"
> >>>> on_event="stick_left_button">
> >>>> <field name="index" value="IndexOfSetting(datalink_pprz_mode)"/>
> >>>> <field name="value" value="0"/>
> >>>> </message>
> >>>>
> >>>> That way i don't need the "MODE" portion of the RC_4CH message so the
> >>>> message length is now reduced by one byte and since that particular
> >>>> message is repeated at a high rate this should reduce bandwidth usage,
> >>>> am i correct or i dont gain anything by doing that?
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >
> >
> > _______________________________________________
> > 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
>
--- original Nachricht Ende ----