Hello,

Cool idea. Although it might not live up to GT Academy standards... (nice fire suit!) 

My guess: the GPS shield with the patch antenna has a limited spatial resolution which will affect the precision of your measurement (depends on conditions but it's safe to assume +/- 10m error). In addition you are limited to maximum of 10 samples / second refresh rate. Add those two together and you are probably looking at half second resolution or worse.

Still an interesting project though. You can throw in some interpolation and compare with a beacon-based lap timer to see how close you can get the results... Or maybe add a 9-axis gyro/accelerometer/magnetometer to capture kart dynamics around the track?

Good luck! 

Chris

www.projectpilotfish.com

Thanks Chris. So does it mean we should be able to read/write SDHC (32GB/FAT32) with 4.2.2.2? I did read through the release notes on CodePlex but didn't find a definitive answer.

Chris

www.projectpilotfish.com

Hello Chris,

Hardware-wise, yes. KodeDaemon sent over a code update last week that we couldn't get into the 4.2.1 firmware in time...but we'll be adding support for larger cards very soon. Netduino Plus 1 will also be getting the software update. Chris

Did this make it into 4.2.2? I am contemplating using the SD card for low-res image storage and would like to use larger media. I read through the forums and can't find a definitive answer. A little hesitant to upgrade any of our two boards at this stage of the project but will do if I can get 16GB+ SD card support.

Chris

www.projectpilotfish.com

Thanks for the nice words on Pilot Fish. BTW, even though it's not a submerged vehicle (other than parts of the motor pods), keeping ocean water out of the navionics, batteries and propulsion over the course of the trip has been a significant challenge... Just saying

Good luck with the project! Would be interesting to follow the build. I might also revisit the tether-less design later this Summer - will post back if it ever gets any traction. Oh, and it will most probably be Netduino-driven

Chris

www.projectpilotfish.com

Hello Jamie,

Your original readings look right. The standard analog servo expects a pulse every 20ms. It is the duration of the pulse that matters (<1.5ms vs. > 1.5ms - see the signal graph in the link above). Accounting for the analog input noise, you can consider your <10 values as low level and your >900 values as high level. Since you are reading the input once every (roughly) 500ms, you are probably randomly (at resonance frequency?) hitting the pulse.

This thread has more details on the challenges/limitations.

Sorry - I know I am not much of a help... I haven't seen a reliable and purely software solution for Netduino - if anyone has one, I'd be curious to read about it too...

Chris

www.projectpilotfish.com

Hello Ruben,

Cool idea! Every time I come back from vacation I start designing one of these. I am yet to get beyond the back-of-a-napkin-sketch phase... 

To start, have a look at this ROV (no affiliation with them and haven't used the product myself). 

I believe your main challenges are outside of the control schematics / software:

  - Creating a sufficiently water-tight setup that you can drop down to 60-80 feet. At depth (pressure) you can't get away with splash-rated electricals. Things get large/heavy/expensive very quickly;

  - Finding a way to get rid of the tether (this has been paramount for me but might not be an issue for you). Wireless is a good idea under (salt) water, as long as it is not radio-wave based ;

 

 

If you are not afraid to tackle all of the above... I've always looked at this as an "underwater hovercraft" project: create (and maintain) neutral buoyancy and use trust-vectoring (angle/velocity) to move around. Won't win any high-speed chases but will probably get the longest dive times with the least amount of energy and disturbance. Plus it will provide the most stable camera platform - it's like getting a gyro-stabilized camera pod.

 

I wonder if any of the quad-copter projects out there cannot be used a a starting point when it comes to schematics / software:

- Use a 3-axis accelerometer to determine orientation (mainly for horizontal plane reference);

- Use a 3-axis gyro to determine rate of rotation (propulsion control keep those to a minimum when there is no operator input for camera PoV stabilization);

- Use pressure sensor for current depth detection. Delta registration is probably more important than absolute value;

- Use a pressure cylinder with a step motor for buoyancy control (several other ways to achieve this);

- Hook-up each of your motor pods through a decent bi-directional speed controller;

- Your "hover" algorithm will depend heavily on your thruster layout, but the basic idea should be to work towards zero-readings on the gyro and zero-deltas on the accelerometer. Once you get that, it should be relatively easy to "temporarily break" your hover algorithm to move in the right direction.

Just my 2 cents.

Keep us posted on the progress - really looking forward to seeing some underwater footage

Chris

www.projectpilotfish.com