Ardupilot goes into the water Part 13

Long time - no sea.

If anybody will tell me about global warming - i will kill him!
We had the coldest (and rainiest) may and june ever.

And August was - the rainiest ever.


Globalization only seems to work in the financial domain, but not for the weather. What about a "weather-transfer" of bad weather to the sahara? They will appreciate the rain there. Despite this fact and the passing away of a close relative, i wished, these months had never happened.

In mid-july, we have seen that this spherical fusion-reactor some eight light-minutes away is still running. I am personally not a fan of nuclear energy, but in this case...

What happened since my last entry?
Not really much.

The new cat has now the same color on both hulls.
The board, that holds the hulls together is now coated with fiber and epoxy to make it more rigid.
The extra battery for the sonar was dropped. The power comes now from the main battery. (-300g of weight)
The cable from the sonar to the transducer was shortened (-100g)

This was really not much, but there are still some challenges out there...

Swimming is not one of my favourite disciplines.
Swimming in bad weather conditions does not even make it better.
Swimming is OK, considering the following conditions:

1. It is summer (I mean that season, when it should be really warm)
2. You have enough time to put on your swimming suit, when the boat starts to react weird.
3. You love swimming
4. No rain

if any of the above is not applicable, staying on the shoreline is the better option.

Swimming is usually caused by:

1. Software
2. Mechanics and Hardware
3. Personal idiocy
4. A combination of the above


To prepare the this year "PID optimization campaign" i decided, to reduce my recovery-swimming exercises to a minimum and thought about Radio Control.

First, i fiddled with my 27MHz RC control from the Jetski model, but found out that this thing is abolutely crappy. Bad range performance, noisy and most of all: no failsafe behaviour. I wanted the software on the ardupilot to decide, whether there is a transmitter controlling the ship or not. And therefore i have to measure the pulses comming out of the Receiver. So far so good, but the 27MHz Rx outputs always some pulses, regardless, if the Tx is on or off (the good old analog era...).

I remembered, that the Ardupilot was originally conceived as a fail-safe
system with an RC option as a fallback for the safe launching and landing
of an airframe.
Why not using this feature for the boat?
Reading the docs and the software showed, that the implementation, which is
in the original version of the Ardupilot was not exactly what i needed.

My requirements were:

1. If the transmitter is OFF or the Receiver is out of reach, the boat shall
be fully controlled by the Ardupilot.

2. If the Transmitter is ON, control shall be passed to the Radio control.

Implementation on the original version was a little bit different,
so i decided to do it my own way.

How to detect if the RF is good or bad?
The only way is to look at the servo pulses, that come out of the Receiver.
Analog RC Systems output always something on the servo channels, even when the Tx is OFF. (see above)
Discrimination between noise and a good signal would be possible by some weird SW algorithms, but i wanted to keep it simple.

A very old friend of mine, who is an RC Dinosaur told me to buy a 2.4GHz RC control.
So i ordered a SPEKTRUM DX5e, which is a fairly priced entry level model.
Reading the manual showed, that the failsafe functionality of the receiver was exactly that what
i needed. Manuals sometimes do not tell the truth, so i oscillographed the servo outputs and found, that
they really told the truth:

1. When the receiver is turned ON without a Transmitter beeing in the air, there is silence on all servo outputs - good.
2. When the Tx is turned ON and the Rx is correctly bound to the Tx, pulses on all channels - good.
3. When the Tx is switched OFF, silence on all channels, but not on the throttle. The throttle channel outputs a pre-programmed default pulse-width. - still good.

From the software point of view, it is very easy to distinguish between silence and "something". So i took the rudder channel to sense the RF.
(Tx ON --> pulses, Tx OFF --> silence)

Technically, all worked fine.

right in the middle: the Receiver.

I have put the code here:


Please note, that the Hardware of the Ardupilot board has to be
modified!
Read the comments in the RC_Control tab.
I have refactured some of the code and added some comments.
WITHOUT testing it. Take the code as a starting point for your own
experiments.


Thats all for today, on the next episode i will tell the experience with the RC control on the lake and why i decided not to use the RC any more.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Fiddling with twitter for two days now.

    http://twitter.com/HM_42

    feel free to follow.
  • @JD,

    Here is the APWTSG (ArduPilot Water trouble shooting guide)

    1. Check if you have enabled the code (uncomment the" #define RADIO_CONTROL " directive )

    2. The AP has a red LED, that indicates the state of the multiplexer control Pin. LED ON --> Control by AP, LED OFF --> control by RC

    3. The Switch mechanism only works, when there is a valid GPS fix. If you try it indoors, it may not work.

    4. check, if you are on the right channel with the rudder. It is Channel 2 (Connector IN2 on the AP (Pin D3 of the Arduino) )

    5. Check, if the MUX switching works.

    embed this code the at the starting of the main loop.

    ...
    void loop()
    {

    // embed from here
    while (1)
    {
    switch_to_ardupilot();
    delay (1000);
    switch_to_radio();
    delay(1000);
    }

    // to here
    ...

    The RED LED shall toggle now with a frequency of about 1Hz.


    6. If this also does not work, check, if the sensing of the Rudder Channel works correct.

    call the check_radio() function in an endless loop and output it to the console and control the values while switching
    the Transmitter ON and OFF.
    OR move the rudder joystick.
    The value should be zero, when the Tx is OFF. It should be in the range of 1000 to 2000, when the Tx is ON.

    ...
    void loop()
    {

    // embed from here
    while (1)
    {

    Serial.println (check_radio() );

    }

    // to here

    7. If all of the above fails:

    DON´T PANIC!

    first count to ten...

    then PANIC.

    (and comment this blog).

    Regards
    Harald
  • Hi Warren,
    i am a little bit in a hurry today. so my response will be short.
    I Think, tgat the control via the ATiny is OK! The throttle control can be done directly from your RC, because in my code i only switch on the Motor on start an i switch it off, when reaching the last WP. The rudder is the only servo thar is controlled by the AP, so there should?3 non implications to other parts of the SW.

    I will have a closer look to the code this evening.
  • actually, I decided to keep the Attiny controlling the Mux, and control the throttle directly from the R/C Rx... will this affect your other code that is controlling the Rudder?

    Basically, I would like the Ardupilot to only control the Rudder to get it to its waypoints, would this be more complicated or less?
  • Harald,
    I tried the modification as suggested, by heating pin 6 of the Attiny with my soldering iron, and lifting it up so that it is no longer soldered to the pad - it can still be re-soldered if needed again.

    The problem is that after loading your code, the R/C system does not ever have control over the servos, whether it is ON or OFF. My R/C receiver completely stops sending signals to the servos if the radio is turned OFF or signal lost, so I thought it would work.... any suggestions? Did you do any other modifications to your Ardupilot, any other jumper wires?

    Also, you might look into the Spektrum BR6000 bot receiver with programmable Failsafe position, I use it with a DX5e and it actually utilizes both the toggle-switch and buddy trainer-switch as channels 5 and 6. By setting the failsafe on the toggle-switch channel to default to Off, you can leave the Ardupilot failsafe in tact and use it to switch between R/C and GPS control, without adding any extra code onto the Ardupilot.

    I have my own waypoints loaded, but havent tested the GPS guidance yet.
  • Hehe, the color reminds me of the boats I use at work.

    gbridge_behindTN.jpg


    Nice job Harald!
  • Hi Ron,

    i already had another cat, which was heavier than the actual one (about 6 kg). It worked well with the same motor, but at a lower speed level. The actual one has a total weight of about 3.5 kg, which comes mostly from the payload. The Batteries alone are over 1.5 kg. I think there would be no problem adding more payload to the actual one, there is still headroom for another 2kg. At the moment i am happy with that configuration, because it will run for about 2 hours at a speed of 8 km/h with one charge. This is absolutely sufficient for surveying a lake with about 1000x1000m in size.
    But who knows, maybe one day, i will increase the size, My dream is still a totally solar powered ship that has virtually unlimited power.
  • Harald,

    Have you considered increasing the "pontoon" volume to allow for additional payload capability? Does that introduce other complications?
  • @ Serge,

    nice piece of code!
    I wonder if the measurement of the pulse in APM_RC.InputCh() is so exact, that it works.

    @Niklas,

    there will be at least one new map (produced in this five miliseconds time frame without rain in August)
  • Once again good post Harald.

    I would like to see more depth maps, if possible.

    Best regards
    Niklas
This reply was deleted.