Topic: ARDUINO any one? (Read 67092 times)

Brian60 · « **Reply #125 on:** April 06, 2016, 12:24:14 pm »

Andy have you some links to read up on the gyro stabilisation? I'll be beginning the build that all of this is supposed to go in next month. So I would like to find out if its going to be feasible to do.

This is what I am hoping for.... Anchor handler etc can be moved out on to lake via normal radio, then trigger whatever system will hold the ship in one spot. This would allow over the side/stern activity like lowering rov, crane derrick etc to be done while the ship is held by 'the system' switching on/off azimuthing pods bow and stern.

dreadnought72 · « **Reply #126 on:** April 06, 2016, 12:32:19 pm »

In the second part of your example the motion of the IMU is cancelled out for the camera by the movement of the servos.

You'd be using azipod thrusters (?) to rotate & translate the hull (with the IMU mounted in it) in order to return to the angle and location that the device was set to.I can't, following a quick look, find a figure for the minimum sensitivity of that accelerometer - but my experiments with the compass side of things on a near-identical chip demonstrates a (very) little drift: about a quarter of a degree per minute: pretty much unnoticeable.

Of course, a hardish part would be in determining the control signals required by the azipods to perform the correct manoeuvre. Lots of testing and programming required.

(And the really hard bit would be to program the device to work it out for itself: just let the program play with the azipods until it learns what works. That's the AI, fuzzy logic, here-comes-Skynet approach for advanced tinkerers.)

Andy

dreadnought72 · « **Reply #127 on:** April 06, 2016, 12:43:45 pm »

I see that there are some good guides on the Adafruit site for using their accelerometers. The Arduino forums are a good place to look, too.

And it might be worth taking a peek into what the drone-people are using for three-axis stability: though, being boats, we'll only need two.

Andy

tsenecal · « **Reply #128 on:** April 06, 2016, 04:18:00 pm »

Guys, another place i have found that has some nifty "IMU" gadgets is

http://pololu.com

specifically:

https://www.pololu.com/category/80/accelerometers-gyros-compasses

i currently am using their product #2127 for some onboard telemetry (magnetic heading, roll, pitch) for my model submarines.

i have a #2468 on order, it adds a gyro to the mix to give better readings, "synergy" is the phrase everyone uses... but with all that, i should be able to make an onboard pitch and roll stabilizer, which also sends the data back to the transmitter...

I have looked at both adafruit and sparkfun ( http://sparkfun.com ) and pololu seems to beat them on price.

tsenecal · « **Reply #129 on:** April 06, 2016, 04:28:39 pm »

another item that almost escaped me about using GPS.

1) most of the cheap GPS devices have about a 30 foot resolution.

2) I can't remember where i read this, but doubling up on some of the cheaper GPS devices was the idea, the basic design is to have two different GPS devices, and average the LAT and LONG readings from the two different devices, getting a more accurate set of values. the more devices, the better the result.

g6swj · « **Reply #130 on:** April 06, 2016, 09:55:45 pm »

Hi Tim
Interesting info. I think I end my day more confused than I started it! Oh well listening to music drinking fine whisky so can all be bad!
The spec of the GPS I am using says accuracy 3 meters or better

I am waiting for some LCD backpack i2c boards to arrive so I can easily hook up a display to see what's going on rather than using a PC. Going to put the kit in a floating tray in the bath an observe the raw data maybe then the mist will dispell

Jonathan

g6swj · « **Reply #131 on:** April 07, 2016, 09:26:38 am »

Brian,

This is an interesting article https://en.wikipedia.org/wiki/Inertial_measurement_unit

So I think you need a TIMU not an IMU to hold position.

And I think you would need Azipod/Schottel type drives rather than bow/stern thruster would be needed.

I think I'll back track and keep things simple for now as IMU / TIMU is above my pay grade!

Jonathan

Brian60 · « **Reply #132 on:** April 07, 2016, 01:25:52 pm »

Thanks Jonathan I'll take a look. The build I have in mind has two azipods at the stern for manouvering and main drive and one at the bow along with two tunnel thrusters for manouvering only. The bow azipod drops out of the hull when needed, the full size ship has three tunnel thrusters and two azipods up front. But in a model there is just not the room to fit it all in.

tsenecal · « **Reply #133 on:** April 07, 2016, 02:45:11 pm »

the Time portion of a TIMU could be picked up from the clock data in the GPS stream... its supposed to be accurate to within 1ms of my nearest atomic clock, but the real "time" value returned is complicated...

from the web:

Quote

GPS has become the world's principal supplier of accurate time. It is used extensively both as a source of time and as a means of transferring time from one location to another. There are three kinds of time available from GPS: GPS time, UTC as estimated and produced by the United States Naval Observatory, and the times from each free-running GPS satellite's atomic clock. The Master Control Station (MCS) at Falcon Air Force Base near Colorado Springs, Colorado gathers the GPS satellites' data from five monitor stations around the globe. A Kalman filter software program estimates the time error, frequency error, frequency drift and Keplerian orbit parameters for each of the satellites and its operating clock. This information is uploaded to each satellite so that it can be broadcasted in real time. This process provides GPS time consistency across the constellation to within a small number of nanoseconds and accurate position determination of the satellites to within a few meters.

with a good GPS for arduino being $50, and the IMU from pololu being $12, i think that could be considered affordable by some.

g6swj · « **Reply #134 on:** April 08, 2016, 07:47:04 am »

Hi Tim,

To obvious for me to get time from GPS :) However if difficult I guess another way would be to use one of the many RTC boards to get the time simply. Adafruit's Chrono Dot claims 1 sec per year accuracy so may be good for the boating lake on a Sunday morning :)

Not sure if I confused things a little - my reference top "above my pay grade" was a reference to my ability (or lack of it)! - That said "I can't get you (concept) out of my mind" - I saw JL's ELO in concert last night and it hit me when this track played that I don't like walking away from things like this as my mind strays back to the challenge frequently - I would be happy to come to a point where I think I know how to do it rather than a collection of possibly related concepts.

I still do not grasp the concept completely - although the discovery that time is a required ingredient helped clear some of the fog of "how does this work" from the initial suggestion of just the raw triple sensors data fusion.

I am attempting to get it straight in my head how this could work - I presume the easiest way is to position the boat into the wind/tide and firstly maintain heading with thrust/azipod devices. Secondly you would then monitor the TIMU bit and correct the forward/backward & port& starboard movement.

Any thoughts?

Jonathan

dreadnought72 · « **Reply #135 on:** April 08, 2016, 10:53:46 am »

The thing about the time element is - your looping programming is counting time already. No need for a specific TIMU.

Just query/compare the state every hundredth/tenth of a second or so (you'd need a 'delay' in the loop), work out drift and yaw from the equations of motion, rotate the azipods to suit and fire 'em up. Sure, your mechanical azipods will be constantly changing/thrusting and playing 'catch up' with the electronic side of things, but who cares? You might need some maths to filter and smooth the data and output, but it really boils down to a negative feedback system.

Andy

g6swj · « **Reply #136 on:** April 08, 2016, 11:11:20 am »

Andy,

Yup obvious (now) and overlooked - thank you for words of wisdom - it does make me smile how it's possible to miss the really obvious

I would advise against delay() as such and use example below but I think that's what you meant - I just had it drummed into me "DON'T USE DELAY!"

compare current millis() with a prev_time snapshot + our delay value

In setup declare a variable for storing the last time we ran a section of code e.g. unsigned long prev_time=0;
In the main loop

if (millis() >= prev_time +100) { // the 100 in this example is our delay in ms
// Set our variable "prev-time" to the current time in elapsed ms so we can compare it the next trip through the loop

prev_time = millis();
}

Regards
Jonathan

dreadnought72 · « **Reply #137 on:** April 09, 2016, 02:20:44 pm »

Hi Brian!

A few thoughts.

The IMU measures acceleration and rotation. Assume the IMU is centrally placed, with its Y-axis along the hull (bow is positive) and X-axis is across the hull (starboard positive). Z-axis rotations are the hull yawing. To keep it simple, we're only interested in these three things - disregard Z-axis motion and other axes' rotation (due to wave action, pitching and rolling in a sea).

If your loop queries the IMU at, say, a hundred checks per second, you'll get two lots of quite accurate acceleration information, and one of rotation.

How to use this data?

The area under a graph of acceleration/time is the velocity. This is not particularly interesting. However, the area under a graph of velocity/time is a displacement, a distance, and this is very interesting. We want to work the anchor handler to minimise/cancel out any displacements from our zero position.

So here's some pseudo code - you'd need to do this for both the x and y axes:

time = time since last checked
x_acn1 = IMU's current x-axis acceleration
x_vel1 = time * (x_acn1 - x_acn0)/2
x_displacement = time * (x_vel1 - x_vel0)/2
stuff here
x-acn0 = x_acn1
x_vel0 = x_vel1

...and repeat.

'Stuff here'?

The image shows our original position, that is, the point at which the system was switched on P₀, and our current position at any point in time P₁.

Since we can calculate the x and y displacements, and the current z-axis rotation, we can drive the boat back to P₀.

All angles are measured clockwise from the positive y-axis and best worked in radians.

alpha is the angle of our displacement. It's given by pi/2-ATAN2(dx,dy).
beta is the hull rotation (heading).
So the angle we need to drive the boat (from the boat's point of view) is pi+alpha-beta. Let's call it gamma.

Given the layout of the proposed model, I suspect you'd rig the bow thrusters to correct for beta, and the three azipods to drive the hull along gamma.

As the heading changes over time, back to zero, gamma will change.

Now, the beauty of this is that, at high sample rates (fast loop times) the displacements will be far smaller than that shown in the diagram. I suspect your azipods' props will be barely turning (the bulk of their work will be in changing the angle of thrust).

And - perhaps - there lies the real problem. It would take some experimentation to determine the best angles for the azipods to move the vessel in the desired gamma, but a close guess around the compass might be enough, because the system will constantly be monitoring and measuring its current P₁.

Andy

Brian60 · « **Reply #138 on:** April 09, 2016, 08:52:58 pm »

I'll need to go through that tomorrow Andy. A little too much to take in this late on a saturday night!

g6swj · « **Reply #139 on:** April 11, 2016, 06:21:53 pm »

GPS Autonomous Boat - stage 1 basic GPS functionality seems to be working ok

Need to get my head around decimalisation of lat/long!

barriew · « **Reply #140 on:** April 12, 2016, 02:55:32 pm »

My Ramp Mover Project
I have finally completed my project to automate the ramp on my car ferry. I had the basic operation completed some time ago, but had a problem with the ramp dropping suddenly when the system was switched on. A comment on the forum lead me to realise that I should be able to use the Arduino to stop this. This involved routeing the servo power via the Arduino and inserting a delay to allow the receiver to initialise properly.
I modified my veroboard layout to include a 5 volt relay for this purpose, but unfortunately the relay was a dud. I next ordered a relay module designed for Arduino . When it came it was quite bulky and would have been messy to incorporate and so I was going abandon the idea. Then I realised that I should be able to utilise a MOSFET to switch the power, so another re-design of the veroboard.
After various errors caused by lack of knowledge, I finally completed the board only to find the ramp still dropped when servo power was connected after the delay. I have finally solved this by inserting a 'go to home' statement in the Sketch immediately after the delay - it may have been better before I suppose. The ramp now just does a quick 'jerk' once power is applied.
Having finally got this working I have also worked out the cause of the problem - Digital Servos

I have only just realised that the ramp servo is digital. It wasn't ordered specifically, it just happened to have the right power for the job. So that being the case, I can now remove the delay.
The photo is of the finished product - not the neatest board, but it has gone through lots of changes. The underside is even worse

.
Thanks to all who offered help and advice.
Barrie

C-3PO · « **Reply #141 on:** April 14, 2016, 11:28:14 am »

Hi Barrie,

Dead impressed - even a bare bones, own build, cut down Arduino. Looks pretty neat to me. I have never done a "bare bones" Arduino build - you have inspired me to give it a go.

Looks like this really worked out well. Brick walls and stumbling blocks along the way (learning moments!) which in truth and with hindsight is a part of the challenge/fun and makes the grey matter work for it's money. Much more fun and rewarding this experiential stuff, having to work it out yourself rather than just making something from an existing design.

Good on you!

Regards
C-3PO

barriew · « **Reply #142 on:** April 14, 2016, 05:28:52 pm »

C-3PO

All is not as it seems

I tried removing the delay, and it was back to square one

So, the delay will stay - shortened, but it will stay.

Barrie

g6swj · « **Reply #143 on:** April 21, 2016, 07:07:59 pm »

Autonomous boat project progressing well (I think)

Now working on telemetry link using 2 x RFM69CW 433mhz transceivers about £8 each - manufacturer quotes line of sight range >1km - we will see!

Jonathan

g6swj · « **Reply #144 on:** May 10, 2016, 08:45:05 pm »

Telemetry - one step closer to autonomous navigation
At last some success. If you have ever played around with technology/programming you will completely understand the experience of hitting a brick wall that just doesn't want to budge and your project grinds to a halt. Well after several precious hours of nothing I have at last got telemetry data flowing over the airwaves (433mhz) and now appearing on a remote shore based PC screen. It's rough (very) and needs thought but the basic concept is shown below - lucky it was only days before it hit the scrap heap...

tsenecal · « **Reply #145 on:** May 10, 2016, 09:40:14 pm »

Quote from: g6swj on May 10, 2016, 08:45:05 pm

Telemetry - one step closer to autonomous navigation
At last some success. If you have ever played around with technology/programming you will completely understand the experience of hitting a brick wall that just doesn't want to budge and your project grinds to a halt. Well after several precious hours of nothing I have at last got telemetry data flowing over the airwaves (433mhz) and now appearing on a remote shore based PC screen. It's rough (very) and needs thought but the basic concept is shown below - lucky it was only days before it hit the scrap heap...

i know exactly how you feel: https://www.youtube.com/watch?v=fuX2pPjoMCY

g6swj · « **Reply #146 on:** May 11, 2016, 06:55:30 am »

Quote

i know exactly how you feel: https://www.youtube.com/watch?v=fuX2pPjoMCY

Hi Tim,
Looks like you got your solution working - what was the display screen you where using?
Jonathan

Brian60 · « **Reply #147 on:** May 11, 2016, 10:03:11 am »

You guys are making massive advances that us lesser mortals can only stare and wonder at.

g6swj · « **Reply #148 on:** May 11, 2016, 10:18:29 am »

Hello Brian,

The funny thing about this is that most of the code I am using is not mine and is copied/patched together from the internet as most things with Arduino you copy and amend rather than start from scratch.

I am watching your progress with your dynamic positioning project - if you think the telemetry would be of use as you get further into your project ( so you can see on shore what is happening with sensor/gps data) then very happy to share code. (this doesn't sound quite right as it's not really my code in the first place!) - cost for the Telemetry transceivers (2x£8)

Like most things if you get a glance under the bonnet you will see that it's actually very simple and logical - easy for me to say now having wasted about 10 hours watching a blank telemetry less screen as I plugged away trying to get if to fire...

The application running on the shore based PC is written in VB.net using a free version of Microsoft Visual Studio. Whilst I can program in this with some effort 95% of the code was pasted from the internet. This could equally be an LCD screen attached directly to an Arduino. The reason I have gone for a pc based app is I want to do live Google mapping and like the idea of an animated compass and may even add a Radar section as well.

Regards
Jonathan

tsenecal · « **Reply #149 on:** May 11, 2016, 02:43:46 pm »

Quote from: g6swj on May 11, 2016, 06:55:30 am

Hi Tim,
Looks like you got your solution working - what was the display screen you where using?
Jonathan

Jonathan,

i am living within the constraints of the radio equipment i standardized on, i am using the OpenLRSng Transmitter module and Receiver with (in that video) a futaba 9cap radio. in addition to that, the OpenLRSng protocol has "adopted" the FrSky telemetry protocol, so i am using the FrSky FLD-02 Telemetry Display Screen:

http://www.hobbyking.com/hobbyking/store/__40032__OrangeRX_Open_LRS_433MHz_Transmitter_100mW_compatible_with_Futaba_radio_.html
http://www.hobbyking.com/hobbyking/store/__27096__OrangeRx_Open_LRS_433MHz_9Ch_Receiver.html
http://www.hobbyking.com/hobbyking/store/__19969__FrSky_FLD_02_Telemetry_Display_Screen.html

on top of all that, i have built my own "hub" using an arduino that connects directly to the receiver and allows me to use some of the telemetry fields for my own purposes. since that video was made, i have upgraded to the FrSky Taranis transmitter, still using the OpenLRSng TX module, allowing me to display a more comprehensive amount of telemetry data on that transmitter's built in display. i use the OpenLRSng modules and receivers because i am using them to control submarines, which do not work with the new 2.4ghz radios. like you, the core of the arduino code is a FrSky telemetry library i found online, that basically allows me to send data from an arduino to the receiver via serial comms, allowing me to take anything an arduino can collect and send it back to the transmitter for display. Just took a look at my latest rev of the arduino code, and due to the use of that library, the total linecount on the arduino sketch i wrote is only 278 lines, including some comments. it gives me 3 different battery voltages, amperage usage for my main battery, depth, main motor rpm, 2 temperatures, compass heading, a calculated speed, roll, pitch, and latitude and longitude.

an on-going thread on my construction of a second hub was finished recently on a website called "subpirates". http://www.subpirates.com/showthread.php?5271-Custom-Frsky-Telemetry-Hub

what i have basically discovered is that for me, visual displays of data are often not useful, it takes your eyes away from the object you are controlling. which is bad for model submarines. the new transmitter allows me to take most of the telemetry data and use it to trigger audio warnings if values get below or above thresholds i decide upon.

News:

Author Topic: ARDUINO any one? (Read 67092 times)