Under Water Vehicle Project - Advice Needed

Hello folks,

Sorry about the long post!

I have a bit of a project on the go which has to be finished by April. We've set our sights quite high considering the lack of experience we have, but there are 5 of us working on it so hopefully we'll get there.

Quick overview of the project:
I'm sure most of you know what an ROV is. Our project is a model AUV - Automated Underwater Vehicle, for which the ultimate goal (in industry) is a vehicle capable of navigating to a predesignated area and performing some task (i.e. actuate a valve on a christmas tree). The image recognition capabilities on the more advanced models using cutting edge software, and given we have a budget of £500, we're going to be downsizing quite a bit.

The emphasis of our project is stability, which we are investigating on two fronts. The first is an efficient hull design, to minimize drag force due to underwater currents. The second is by way of a stability system - which I am working on.

I've had a look online to see how feasible a system we can develop, done a bit of thinking and would be delighted if you chaps could help steer me in the right direction. I've looked into AUVs and 'drones' for the stability - essentially a similar idea but in water not air.

Ideally the AUV would navigate a predetermined path and then when it reached it's 'destination' it would try it's best to stay in that position.

Ultimately, I'd like to incorporate the following for navigation.
-Ultrasound transceiver on the front face of the AUV, to gauge distance from 'target'.
-Pressure Sensor / Barometer - to gauge depth.
I realise this would only give position in 2 directions, but sticking to the idea that this is on the sea bed, that's a realistic assumption.

For stability, I'd like to use a 6 Axis Accelerometer. I had a look online, and I was wondering if something like this would be suitable for use with the PICAXE:
http://www.robotshop.com/sfe-6dof-razor-ultra-thin-imu-triple-axis-3g-accelerometer.html

Having had a quick read on a few threads on the forum, am I right that the correct way to actuate a response from an accelerometer is in integrating the acceleration twice to get the displacement, and actuating an appropriate response to counter this?

For actuation, I was thinking these bilge pumps would be ideal:
http://www.force4.co.uk/842/Rule--1100-Submersible-Bilge-Pump.html
Given they are waterproof already, can be manipulated fairely easily, and are fully reversible.

To sum up, I suppose I'm hoping for some general advice. Does this seem feasible using a Picaxe microcontroller?

I've bought myself a 18M2 started kit (not for this project - for myself) and a bunch of LEDs / Resistors to have a play around with so hopefully in a week or two I'll be up and running and will be asking some more technical questions!

Cheers,

Brian.

BrIDo said:

Hello folks,

Sorry about the long post!

For stability, I'd like to use a 6 Axis Accelerometer. I had a look online, and I was wondering if something like this would be suitable for use with the PICAXE:
http://www.robotshop.com/sfe-6dof-razor-ultra-thin-imu-triple-axis-3g-accelerometer.html

Brian.

Click to expand...

I think a picAxe might not have the computer horsepower you will need. You will probably need floating point which is not the picAxe strong suit. Check out SparkFun, they have a lot of stuff on accelerometers and magnetometers.

Actually there is a really good book that might help you.

http://www.alwayshobbies.com/Boats/Books/Model-Submarine-Technology$3.ice

I have a copy and it covers a lot of electronic systems to regulate depth and to set a magnetic bearing it could give you a lot of the answers you are looking for.

BrIDo said:

Having had a quick read on a few threads on the forum, am I right that the correct way to actuate a response from an accelerometer is in integrating the acceleration twice to get the displacement, and actuating an appropriate response to counter this?

Click to expand...

Newton has the answer to that:-
S=Ut + 1/2 at^2 (distance = initial velocity times time plus half the acelleration times the square of time)

first differential gives
V=U + at (velocity = initial velocity plus accelleration times time)

second differential gives
accelleration

So, yes, but only in theory.
The problems you encounter in real life are the constant offsets that get lost with integration and also the accumulated error. These can get quite large when working with digital integration due to quantising.
Not impossible, but many 'gotchas' waiting to bite.

Absolutely, but what does an accelerometer give you at a steady velocity?

Exactly.
If we reverse the differential process I describe in post 4 we get:-
Integral of accellaration = Velocity + at (but 'U' has vanished)

Hence, any initial velocity at startup is lost, and such errors can accumulate VERY quickly, especially as a second integral is required which introduces a second level of 'unknown' AND integrates the initial error. Thus, any initial error (and or inaccuracy) simply gets larger with time even if all else is absolutley perfect.

Spent a bit of time playing with my 18M2 project board tonight, working through the PicAxe tuts in the manual. Got my LED's blinking and sirens going. What can I say, Rome wasn't built in a day!!

So the PicAxe can't handle floating point operations?

Thanks for the book recommendation, I'll check if the library has a copy.

Regarding the accelerometer chip I posted, it doesn't have to be that one, it can be 6 standalone accelerometers if need be. The main reason I want to go with picAxe and not arduino is because I think starting at the beginning and building from nothing with a picaxe will teach me more, but i'll also understand exactly what's going on with what I build. If I buy an 'off the shelf' arduino kit and something goes wrong I want know where to start figuring it out.

Beanie, I'm understanding what you're saying. But, when you integrate you also add in a constant. It's then possible to solve for those constants using linear equations? Is this maths possible in the basic language and on the picaxe controller?

Dippy, aye, I thought about the fact that if after the initial change in speed occurs, the accelerometer won't give any measurable value. Essentially what i'll be trying to do is have the actuators cancel out the resulting motion from the initial force. This might result in an 'overbalance' but with a bit of calibrating a fiddling about i'm hoping it'll eventually try to settle itself to zero. Does that sound like a feasible idea or am I talking shit? What would you recommend as a better way of doing it? I suppose a big part depends on the responsiveness of the bilge pumps and how quickly they're able to enact a response...

Would a magnetometer work for you? (Don't know how well they would work in the environment you are planning to work in)
This way you have a direction reference that you can start of with.
The accelerometers would then give instantaneous readings of external influences (such as drift) which you would then take into account.

BrIDo, you are absolutely correct about having to add in a constant when integrating. The problem is that you don't know what that constant needs to be. More to the point, you have no way of knowing because of the sensor you are opting to use. For example, you don't know the initial velocity which is one of the constants you need to know. Get that slightly wrong and every itteration of your integration will add a little more error to your final result.

The PICAXE is more than capable of doing all the sums. Digital integration is nothing more than addition. The real question is can it do it fast enough and to enough precision?

Model helicopter pilots know about the initial velocity problem only too well. Any rotational movement when initialising the gyro will result in an offset on the tail rotor compensation for the duration of the flight.

Simple tilt-switches might be useful. In fact you might be able to guage acceleration from them too. I think you've got to weigh up the complexity of the solution against the practical value.

BrIDo said:

So the PicAxe can't handle floating point operations?

Click to expand...

Natively the PICAXE only handles 16-bit positive only integers, with an extra operator to determine the upper 16-bits of a 16-bit x 16-bit multiplication.

This isn't necessarily such a problem as it may first seem but may dictate choosing algorithms which suit its capabilities. The umFPU maths co-processor can be used to extend the PICAXE mathematical capabilities.

Beanie, had a think, and I see what you mean. Starting with:

y''= a
y'=at+c
y=1/2at^2 + ct + b

Ultimately, I'm after y, I end up with 3 unknowns and two equations. Normally, in a theoretical solution, I'd integrate between t,initial (which would be zero) and t,final (some arbitrary value) and solve my constants, put them back into the original and out comes y. However, I don't know how long any given acceleration will be acting on the AUV - I can't solve for the equations.

Having read through the picaxe documentation (albeit quickly at times), am I right in saying that all variable inputs into the picaxe produce an integer value of between 0 and 255? I'm probably simplifying far too much, but with some calibration, a conversion factor, and a bit of trial an error, can't I just 'recycle' that value and use it to determine how aggressive the actuators have to respond?

I had a look at tilt switches Jeremy. Am I right in saying that they're either on or off? If that was the case I'd have no way to gauge a variable output from the actuators and I've got a feeling the AUV would end up oscilliating violently..?

Would a magnetometer work for you? (Don't know how well they would work in the environment you are planning to work in)
This way you have a direction reference that you can start of with.
The accelerometers would then give instantaneous readings of external influences (such as drift) which you would then take into account.

Click to expand...

Hmm, I've had a browse and various robotic sites and these always seem to be mentioned along with accelerometers. Someone in another thread on here, i'm sure, was using it to 'recalibrate' it's accelerometer after so many turns?

Looking at vector magnetometers, would it be possible to have the AUV calibrate itself when it gets into position, and then with movements which result in a change in readings from the magnetometer (i'm assuming in X,Y,Z) begin actuating a response? Would movements of a few centimetres be registered by the magnetometer?

Really appreciating the advice here folks, it's definitely helping to shape our design and thought process!

BrIDo said:

Having read through the picaxe documentation (albeit quickly at times), am I right in saying that all variable inputs into the picaxe produce an integer value of between 0 and 255?

Click to expand...

Inputs can be single bit ( 0 or 1 ), byte ( 0 to 255 ) or word ( 0 to 65535 ) depending on what you are reading and how you are reading it. Some things come in half-way; READTEMP12 reads 12-bits of temperature, READADC10 reads 10-bits of analogue.

BrIDo said:

I had a look at tilt switches Jeremy. Am I right in saying that they're either on or off? If that was the case I'd have no way to gauge a variable output from the actuators and I've got a feeling the AUV would end up oscilliating violently..?

Click to expand...

Tilt switches are usually on or off. You could consider a potentiometer with a stick from its shaft and a weight at the end. If low friction you can create a variable 'tilt sensor'. You could also create a 'quadrature rotary switch' and do it digitally ( like mouse motion sensing using opto sensors ).

Even if these aren't ideal - nowhere near as high-tech as accelerometers - they may have usefulness in calibration, error compensation or sanity checking. Likewise, if a PICAXE isn't the core controller you finally choose they could still serve as 'smart peripherals', off-loading hardware interfacing and so on from the core.

Spot on BrIDo, that's what I was trying to explain in post #4.
With real-time digital integration you don't actually solve any equations, you integrate as you go along with iterations as fast as you can.

So, sticking with:-
y''= a
y'=at+c
y=1/2at^2 + ct + b

All you KNOW is "a". From that, at any point in time you can determine y' (velocity) if you also know "t" (and c). As per 'normal' integration, you would take "t" as infinitely small and sum. However, you need to reading in "a" and assume it to be constant for the duration of however long it takes between each reading. This is your value "a" and for the period it takes between readings. Sum all these up continuously and you have real-time velocity.

Very crudley, it would like this.
Do
ReadADC A 'Read in the acceleration
dV = A*t 'Change in velocity = acceleration * itteration period
V=V+dV 'add the change in velocity to the current velocity
Loop 'keep doing it as fast as you can.

You can see that in theory it is quite simple.
However, you need to take into account the fact that "a" is a vector, and "t" is very small (and needs to be worked out from how fast your code is). In addition to that, you need to take your calculated velocity and apply the same principal to derive distance.

One minor hiccup that this method poses is what happens if somebody should kick your vehical into touch? A very rapid "a" (the kick) could be missed altogether while you were busy calculating. Now you have an increase in velocity that you totally missed. You can get around that by doing part of the integration in analogue. That is nothing more than a cap on the ADC input to "smooth out" any rapid changes in "a" but it does slow down overall response which can lead to other issues.
Now we need to consider quantising issues.
Even if you use ReadADC10, at best, you will only get a value between 0 and 1023 for the full range of your sensor. What if "a" is greater than 99 but only just under 100. You will be very rapidy summing up lots of 99s when you should be summing up lots of 99.999999s. This will quickly lead to an error in the calculation.

So, theory simple. Practice, not so simple (to get accurate results)
You need "a" to be a large number so that you have resolution.
You need "t" to be as small as possible.
But then you need to be able to store all those accumlated t*a's which means storing very big numbers.
And then you need to do it all again to that result.
It's a messy ballancing act when doing it digitally

It CAN be done though

Thanks for the help folks.

I've decided to stick with the picaxe, and after having a chat with the project supervisor, we've decided to simplify our design somewhat.

I attached the basic idea for the motor circuit below. My general thinking was to have an accelerometer - much more basic than the one in the original post - to detect changes in tilt (i.e. when the accelerometer is non zero) and have the motors going full throttle, forward or reverse to actuate (working together on opposite directions maybe). I've since found the circuit in the back of the picaxe manual 3 which features a reversible circuit using relays.

I thought about having variable speed control for the motors - can anyone suggest a way to go about this? I've used speed controllers for an RC model plane before, but I'm not sure if they could be utilized here (they're also bloody expensive!). Am i right in thinking a variable resistor, where the resistance can be automated via the picaxe would do this? Does such a component exist, or is this essentially what an ESC is?

I also looked at the L293D motor controller chip. I think this would be easier than the relay method, and pending the our motor size I think we'll go for a few of these instead.

Lastly, I've uploaded some of our concepts for you to have a look at. The funky colours are from CFD analysis. We're optimizing the chisel-ish design, given it's easier to make, actuate, and has the second lowest drag coefficient.

Hi

the Circut looks like it will work but i have a couple of sugestions:
1)have you thought about a half h driver, that way you can eaisily go forwards and backwards.

2) to hold it in position cant you use a motor to drive an auger in to the ground so it will stay where it is (dont dig too deep thogh, we dont want another BP oil disaster!! )

3) once you become familiar with i2c and serial you could use more than one picaxe to do the work (ie one for drive, one for tools, one for navigating etc)

jamster

Hmm, the half h driver you suggested, something like this:

http://focus.ti.com/lit/ds/slrs007b/slrs007b.pdf

It looks pretty similar in function to the L293D motor driver chip shown here:

http://www.solarbotics.com/products/l293d/

The problem with the L293D is the current. I think 600mA might be too small for the motors we are thinking about going ahead with.

Unfortunately, we're not allowed to make any modifications to the equipment being 'worked on,' and there's no guarantee that the AUV would be close enough to the sea bed to go with an auger type arrangement.

I found this website here, which has been absolute excellent on IMU's:

http://www.starlino.com/imu_guide.html

If you are worried about current/power then make a butch driver using MOSFETs. While you're at it make it an H if you want.
A convenient one may be the TC4469 or similar.
MOSFET drivers (and advice) abounds.


If your chip is getting busy then use a secondary micro and write some serial firmware.

RC speed controllers are indeed expensive but they work very well, they protect both the motor and the battery from excessive current and discharge and they are very simple to use. So, spend the money and put your time and effort into solving problems that don't have an off-the-shelf solution.

Another advantage that you will have by using an RC speed controller is that it will work from 'standard' servo signals. You could use these throughout your your project for control. This would also work nicely for your stability problem because it would allow you to fit a "heading hold" gyro between your control signal and elevation control servo. Another off-the-shelf solution

These devices produce rock-solid stability for aircraft so I don't see why they shouldn't work for your application. Spend the extra few pence and get the type that use a seperate channel for gain control, then you can tweek the value to work with the more sluggish respsonse that you would expect to see under water.

This project is a tall order to get working by April and IMHO not feesible on a budget of just £500 unless you have some 'good' contacts. If you stick with ready made servos for your control surfaces and motion, at least it will give time to work on the trickier parts rather than having to worry about things that have already had many thousands of man hours of design work already. I wish you all the best of luck. Keep us posted on progess.

EDIT:
What ever happened to DPG's trans-atlantic attempt?

It was probably as effective as the shift key on his keyboard

Maybe he sold it to some Columbian drug baron to get stuff to an American beach and it ended up somewhere else.
Haven't heard from him for ages.

Tilt (in two dimensions) in degrees with an accuracy of about one degree is easy to calculate using an ADXL203 with a Picaxe, you just need two readadc10 inputs, several word variables and a chip that has the ATAN function. You are welcome to my code if it is helpful. But the calculation takes a little time and more if you add a digital filter to remove vibration, so a lot depends on what speed of response you need. You also need to calibrate the adxl203 as its analogue output range 0-1023 spans -1.7g to +1.7g in a non-linear fashion and the channels are close but not exactly the same.

As well as tilt you can check for impacts, for example. I'm not sure how accurate it would be for dead-reckoning however even if you had the power to do the calculation.

Similar considerations apply for 3 dimensions of course.

Beanie, I'd like to go with the speed controllers but for the time being I'm going to avoid them due to costs and have on/off/reverse thrusters. Atleast until we've sourced the price of all the entire craft, including the hull shape - then we might look at adding them in at a slightly later date. I realise this might give some interesting, maybe violent oscillations as the craft tries to level itself (maybe a reason to request more funding after an initial test to buy the speed controllers). We did some buoyancy calculations and had a bit of a laugh when we realised we'd need 150kg to make the thing neutrally buoyant!

I had a go at drawing up a circuit (attached below) using some of the suggested components (to make sure I'm taking some of this in). Do you think it would run in it's present configuration?

I chose the 20X2 because of it was the fastest chip available, and because it was capable to trigonometry commands. I've got the serial tied up using a 22k and a 10k resistor. I've used 330 ohm resistors for the outputs to the motor controller, and I've got the data from the accelerometer going to ADC (analogue) capable pins which I'd configure as inputs. Under instructions from the accelerometer data sheet, I included two capacitors in it's power supply line (power decoupling?). I also included a 1846 ohm resistor, to drop the voltage from 4.5v to the 3.3v the device runs on.

I've tried to follow the information I've picked up thus far, but I'm not sure about the following:
1) The accelerometer - the Self Test (ST) and Power Down (PD) pins operate digitally - are all picaxe pins capable of digital input / output?

2) My take on the motor controller is that the enable voltage is used as a threshold for the input pin, i.e.e input voltage=enable voltage = 1, input voltage < enable voltage = 0. Is this correct?

3) And, would I need to include a 330 ohm resistor in the supply line to the enable voltage to the L293D to account for the voltage lost in the PICAXE output lines?

4) Is it acceptable to use a separate power supply to drive the motors, as is the configured circuit?

Geoff, thanks for the offer. I'd like to have a go at the coding it myself and then I'll post it on here and see how far off I am!

Dippy, I don't think that particular one would be suitable, but I did find one which I think might handle the high current drawn by the motors we're using. I've used the L239D and ADXL203 in a circuit to get to grips with connecting the components but i'll move into the 'heavier' half h bridge later.

No time right now to go into details but DO NOT POWER UP that circuit.
It WILL KILL your 3v accellerometer chip?
How on earth did you arrive that resistor value for dropping the voltage?
You a need a proper regulator.

Don't worry, I don't actually have any of those components, I was just doing it theoretically.

I looked up regulators and I'm guessing I'd need something like this:

http://www.sparkfun.com/datasheets/Components/LD1117V33.pdf

Two thoughts....

Not a great choice of regulator - read the datasheet and see the drop out voltage. HINT: what will happen to the output voltage if your battery voltage drops to 4.2v?

A better choice would be http://www.rapidonline.com/netalogue/specs/82-3008e.pdf

Your 22k/10k resistors are incorrect - put the standard download circuit in place with a 3.5mm jack socket so that you can re-program the PICAXE in-situ - see Manual 1

(nice style schematic though )

I agree with Martin about the regulator and download circuit.

Not sure the 20X2 would be the best choice. Is speed that important to you?
I'd consider the 28X2 which would offer more I/O which you may well need when you start adding in the bits you'll need for the control surfaces. It will also offer more program space should you need lookup tables and similar.

I have to agree on a chip with more pins. I'm working on the prototype for a self navigating device (not a UAV, but no other details because of NDA) and the 40X2 that was originally "enough" now has a 28X2 to handle RF serial I/O and some other things that relate more to communications than to the primary purpose of the device, along with a uMFPU for some floating point needs. At the moment, there are 3 or 4 unused pins on the 40X2, but we may need an I2C I/O expander for the as-yet-uninstalled pieces.

On the bright side, the double-sided board is currently about 4.5 inches by 5 inches, which is close enough to the planned real estate size. There are also some nicer "toys" - like FRAM instead of EEPROM.

John

Personally, I am fond of the MTroniks line of ESCs (unlike the aircraft ones you are familiar with, they have fwds/rev models that are already waterproof. We use them a lot in R/C Model Warship Combat (where we end up at the bottom of the pond a lot). Some are not teribly dear - kind of depends on the size of motor you are driving = make sure to size the ESC to the stall draw of the motor being controlled. You can find the full range here: http://www.mtroniks.net/details1.asp/ProductID/178/Genesis-Sport-Plus.htm

Since you would be using more than one, be sure and disconnect the red wire from all but one (if you are using it for a BEC) or from all, if you are not using any of them as a BEC.

Just had a brainstorm. you might not need to disconne\ct the red wire if you put a diode in place on each to prevent current flow backwards through the ESC.....

Cheers,

Wrenno