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.
Comments
Dylan,
yes i can :-)
I just got a boat driven by two motors- there is no rudder. I was looking at the sketch for this one and it would be fantastic for my project, but I only have basic programming skills and don't really know how to go about modifying it to steer by adjusting each motor's power without messing things up. If you could help me out, that would be so great!
i had a closer look to your waypoints. They are very close together (some 20m away) this is very close to the threshold for the waypoint-hit. And, this may cause big differences between the setpoint and the actual bearing, which in turn causes large rudde movements. I did my tests with waypoints that were at least 50m away from each other.
This may cause some addtional meters of swimming :-)
Buy a body-board and fins.
By the way: lovely cats on your homepage.
This one was one of mine:
regards
Harald
hm...
If the hull is stable, you can concentrate on the ArduPilot.
First, you may have a look at the center Position of the rudder servo, when driven by the AP. Maybe this differs from the RC one. you can adjust that by the #define MIDDLE_YAW directive.
Maybe the "excellent turning capability" of you boat is the problem, if it reacts very sensitive to the joystick movements.
reducing the KP_HEADING will help.
I know, adjusting all this parameters can be very frustrating, but it gives a lot of know-how and if you finally have success, you will know, that is was worth doing it. Keep on...
Regards
Harald
nice to hear, that the GPS is working again.
I have had a look to your code and found nothing pathological.
The behaviour, that you are describing (the circling) sounds very familiar to me :-)
It seems, that your hull is not stable enough to hold a straight line. I already had the same problems with my firebrigade ship.
You can try this:
First, look, where the keel weight is located (if you have any). If the weight is in the vicinity of the ship´s center of gravity, this may cause instable behaviour. Moving it more to the aft may make it better.
What you can also try, is to add some kind of fins to the aft of your keel.
(try some plastic or Balsawood, that you can fix with hot-glue or the like)
Second, try fiddling with the KP_HEADING parameter, because the one i used is optimized for my monokeel assembly. If you have oscillations, try to reduce at least by a factor of two and make the the integrator and derivator part close to zero. Try the following parameter set as a starting point:
#define KP_HEADING 0.3
#define KI_HEADING 0.0005
#define KD_HEADING 0.0001
#define MOTOR_SPEED 80
This is a mere P-controller, which makes optimization more easy.
But keep in mind, that the geometry of the ship plays the key-role for good stability. This is why i left the mono-hull approach and moved to a catamarane design. The monohull (firebrigade ship) i have used, worked quite well after lots of optimizations, but there were still oscillations.
Can you provide some photos of your boat?
Regards
Harald
// command sequence to switch back from SIRF to NMEA
unsigned char gpsbuf[] =
{ 0xA0, 0xA2, 0x00, 0x18,
0x81, 0x02, 0x01, 0x01, 0x00, 0x01, 0x01, 0x01, 0x05, 0x01, 0x01, 0x01,
0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x25, 0x80,
0x01, 0x3A, 0xB0, 0xB3};
int i;
void setup()
{
Serial.begin (9600); // or whatever baudrate has been seet previously
for (i=0; i<= 31; i++)
Serial.print(gpsbuf[i], BYTE);
...
regards
Harald
what GPS are you using ?
The code is written for the EM406.
The only thing i do is to switch the baudrate from default 4800 to 9600 in the startup code. If you try the original code, this feature is not implemented. The EM406 stores this settings for about one week if powered off. If yo are using a different module, this may be a reason for the failure. But, if the blue led is ON, the GPS is OK.
I still think there is some problem with the throttle output. Try a servo on the throttle output, to see if there is something living. If you have an oscillscope, you can directly look at the pwm pin if there are pulses coming out.
seems that there is a problem with the Throttle channel. The random movement of the rudder is OK, when the boat is at rest, because the GPS outputs random heading information, when the GPS is not moving.
You can first try is to move the boat around (on land), when in AP mode. The random movements should stop and the rudder should "force" the boat towards the first waypoint.
This may look funny if somebody is carrying a boat under his arms and moving around on land, but it helps ;-)
Second, you have to find out, why the motor stops. There can be several reasons:
Maybe the PWM Channel of the AP is dead or the ESC did not start up.
I also had trouble with some ESCs. Mostly, they are in failsafe mode, when powered up. To get them armed, they need a startup procedure. Please look at the manual of your ESC.
You can write some code to only control the throttle channel and put it in the
What you can also try is to control the throttle only with the RC (as you already wanted to do). This will show, if the AP is working correct e.g. the boat should find its way to the waypoints. But if you try this, be aware of swimming!
You also can try to test it by writing some code in the setup() function and fiddling with the pulse_servo_throttle function as in the example below:
void setup()
{
init_ardupilot();
waypoints = sizeof(wps) / sizeof(LONLAT);
//ram_info();
Init_servo();//Initalizing servo, see "Servo_Control" tab.
test_yaw(); // Just move the servo to see, that there is something living
// insert your test code from here
pulse_servo_throttle(xx);
delay(xx);
regards
Harald
have you tried all of the measures from my trouble shooting guide?
Pleas note, that the code only works with a valid GPS fix.
I have tested the code on the last weekend with a flying platform and it worked well. (the code worked well, but the platform crashed :)
The failsafe function of the ATiny shall work without modification. If i have got it right, the Multiplexer is switched by the ATiny if the control input is connected to the switching channel of your RC (Channel 5 on the DX5e)
You can check out the Version 1.0 of the original ArduPilot code and have a look, how Jordi has implemented the failsafe..
Anyway, it makes me wonder, what exactly happens on your system. can you describe how the system behaves ?
regards
Harald
Lately I have been doing some tests with the FEZ Domino for another project and have come to the conclusion that I’m replacing my two Arduinos with one FEZ Domino.
My reasons for doing this is;
• It’s built on .NET micro framework and is programmed in Visual Studio C#. This IDE is far superior to the Arduino IDE.
• You can debug directly on the chip and set breakpoints in your code while the program is running (on the chip) and examine variables
• C# has real string handling functions like .IndexOf .Substring .ToUpper etc.
• The FEZ has a built in SD with a real file handling system.
• It has 3 hardware UART so no more software serial. I need one for the GPS, one for the transducer and one for an XBee.
• It has load of more RAM (62Kb) and flash (148Kb)
• A built in real time clock
• It has full threading capabilities and event handled UART’s
OK, so it’s not real time like the Arduino (how could it with threading?) But it’s lightning fast for my use anyway.
I’m currently working on this project with the FEZ Domino http://letsmakerobots.com/node/22108
I’m not saying your should do the same, but if you haven’t heard of the FEZ, take a look here: http://www.tinyclr.com/ They also have the FEZ Panda for an introduction price of $19.95 It’s like the Domino without the SD card and USB host, but with 60 IO-pins and 4 UART.
Kind regards
Geir
-
1
-
2
of 2 Next