Final project journey (all weeks)

Note

Dear reader. This page can be seen as a journey that shows my progress related to my final project; more or less seperate from my weekly assignments. There might be some overlap of course. Related are a number of other pages regarding specific topics which are mentioned below.

Related pages

Scope

Decisions

System architecture

BOM - software - other

Scans

Tasks

RD3000 summary

Week 01

The last couple of months I collected a lot of ideas.

Based on video's / work we saw during bootcamp, the local session, I got inspired to try to make it big but not too big.

Swim monitor

Every Saturday morning I go to the indoor pool to improve my swimming technique / speed. I always swim in the 2nd lane (whereas 6 being the ones for the masters). To improve I need to focus on technique and then speed. But swmming around I've no idea of how my body is floating in the water. And speed drills? Actually I hate those.

Of course I followed a course and was once filmed in the water using a camera on a stick; whereby a coach walks along side to film, you. But that has been a long time ago. And it is both costly and time consuming to do that again.

Regarding the speed drills. Yes I have a watch but Ihave to manualle activate and deactivate it. So I'm always starting with one hand on the other, give myself some speed and the end I have to find the right button again. Depending on how good I do this, the speed measurement is kind of inaccurate.

What if there was a way to (more accurately) measure my speed and make get frequently inside into the way I swim?

Solution

The [swim monitor] is a system that enables swimmers to:

Track their speed, lap time, distance while swimming
Be challenged/paced by a pre-programmed exercise
Compete with another swimmer (gamefication)
Afterwards see how they moved through the water

Visuals/ mockups

The [swim monitor] is a system that consists of multiple parts:

Start/ stop (on both sides of the pool) that the swimmer can use to start/stop the monitor
Lap monitor that keeps track of time, speed
Pacer that shows how fast a swimmer should swim to meet his/her criteria
Camera that films a swimmer from the front, side and behind
Storage that combines timely data with visual data

Non-functionals

It has to be safe especially around/ in water
It is not allowed to pollute the water in any way (pool water is clean water)
It should be possible to install/ deinstall in 10 minutes time (as other people might need the pool)

Open water buddy

I personally like to swim in open water whether it is to improve my distance or just to cool down. Usually I do this in a rive ("de Vecht") which is very near by. This river is very popular and, especially in the summer, populated with boats.

So when I swim a longer distance I'm constantly looking around to navigate but also to look around whether boats actually see me. And as I swim alone there is nobody who can take a picture of me (just for fun later on).

And when I'm in the water to cool down I usually get out quit quickly as I have no fun just being in the water; I like to do something. Even if I'm with one of my kids throwing a ball, it gets boring after a while.

What if I could have buddy that guides me and plays with me in the water?

Solution

The [Open water buddy] is a device that:

Shows you the way (pre programmed route/ geo-fence)
Tries to catch you or any other person that is close by (like a shark)
Follows you around while you swim
Monitors you while you swim (distance, photo, video)
Randomly goes any direction so that you have to catch it
Can be set to stealth mode to film wildlife
Comes to you when needed
Can be controlled remotely

Visuals/ mockups

The [Open water buddy] is a device that consists of multiple parts:

Simple interface to activate a function / user feedback
Camera to film and take photo's
GPS tracker for loaction\
Light(s) for guidance / protection
Intelligence to recognize people/ objects / birds
Storage that combines location data with visual data

Non-functionals

It has to be safe especially around/ in water
It is not allowed to pollute the water in any way (although it is open water)
It should be small/ strong enough to be thrown away (like a ball)
It should be quiet
It should be possible to put a shark vin in top
It should be possible to put a yellow rubber duck on top of it

Week 2

I thought about creating a new page but just updated this one for now. Biggest decision is that my final project will be, what I now call, the Open Water Buddy. The main reason: I have no idea how to make it . Sounds silly but what the heck; I only live once. First change is the working title.

UWO

Udentified Water Object. Which in a sense does not do justice to what it will be able to do. To better help me design I will decribe it's functions from a users perspective. I will therefore call this person "User".

The object supports 2 main type of modes: normal and game mode.

NORMAL MODE

Scenario 01: GUIDE ME

User wants to go for a swim
User enters the water and turns on UWO
User selects "GUIDE ME"
User sets total distance in meters
User sets interval distance in meters
User selects "ACTIVATE"
UWO starts moving away from the user and keeps a safe distance
User start swimming
UWO signals when the total/ interval distance has been reached

Optional:

User selects photo on/off at interval
User selects video on/off
- User selects continuous or interval/duration in seconds

Scenario 02: FOLLOW ME

Basically the same as GUIDE ME only now the user is followed by UWO.

Optional: - User puts a shark vin on top of the object or a rubber duck

GAME MODE

Scenario 03: CATH ME IF YOU CAN

Looks similar to "GUIDE ME". Object moves away from the user. Difference is that the movements of the object are random but always meant to get away from the swimmer. Of course you can set the maximum radius in which the oject is allowed to move. Also the maximum speed while moving.

Scenario 04: JAWS

Looks similar to "FOLLOW ME". Object tracks the user but tries to catch it. There is a multi-player mode which means that it will try to catch any swimmer it can. Again here you can set a max radius and max speed while moving.

WILDLIFE MODE

User wants to film wildlife on the water from nearby
User turns on UWO
User selects "WILDLIFE"
User sets total radius in meters
User sets total time in minutes
User selects "ACTIVATE"
User puts UWO in the water
UWO starts moving away from the user away from the shore
UWO goes into stealth mode
UWO moves towards wildlife
UWO films wildlife
UWO returns to the starting point once time is up

Non-functionals

I adjusted my non-functionals accordingly

It has to be safe. This means
- no sharp edges that can cut you
- soft impact if you get hit or you hit the object yourself
- no change/ low risk of an electric shok when you touch the object (especially in water)
It is not allowed to pollute the water in any way (although it is open water)
It should be small/ strong enough to be thrown away (like a disc/ frisbee)
It should be quiet when in stealth mode
- so animals are not disturbed or spooked by it
It should be self-supporting regarding energy
- at least 30 minutes when in game mode
- at least 2 hours when in guidance mode
- at least 4 hous when in stealth mode
It should be difficult to detect it
- only external sensors are above water
- overal height above water should be kept to a minimum
It is able to put itself in an upright position
It should be possible to attach special accessoiries on it. For example
- a shark vin (game mode)
- a rubber duck (stealth mode)
It's direction should be clear for other vessels on the water when it is dark

System integration

UWO as a system will consist of several subsystems.

UX

Imagine being the water; maybe the user already has goggles on. This means that the interface should be easy to use and it's information clearly visible; even when it is dark(er). Rotating knobs? LED display in numbers. On the other hand may be the interface should be outside UWO. This would make it lighter? But what if you want to change some stuff while you are swimming. If the UX is outside how do you operate it then. Hmm..

Based on the directions from the user this subsystem is able to navigate in the right direction, the right speed. It's inputs are:

GPS location
Object detection (distance in meters, direction)
Swimmer detection (distance in meters, direction)
GeoFence
Mode/ scenario

It uses this information to pick a path at the right speed. For instance depending on the scenario it will I go toward or away from a swimmer.

While it is navigating it will output traveled distance in regular intervals.

Awareness

This subsystem is all about detecting objects; surroundings. It's input are:

GPS location
Map data (water side, buoys)
Camera/Image feed (maybe 360?)

Whether the camera feed is continous or just images I don't know yey

It uses the information to detect and output:

if UWO will hit something (if continuing in the direction)
what that something could actually be (could be wildlife, buoy, shore, swimmer)
at what distance

Imagery

This subsystem is responsible for detecting/ recording UWO's surrounding and storing it. It's input are:

GPS Location
Time/date
Continous camera feed (maybe 360?)

There is no output at this time but this could be cleaned images that are needed for the awareness subsystem

Navigational lights

This subsystem is responsible for all lights above (ships, vessels) and under water (to follow UWO). It's input are:

Navigation lights on/off
Guidance lights on/off
System warning lights on/off (this is to show what the status is of UWO)
- low battery
- stuck/ don't know what to do
- ...

Central unit

This part is responsible for the overall command structure; for receiving and providing information to the different subsystems.

Visuals/ mockups

Must stuff I can visualize myself but my biggest concern at the moment is the propulsion. I would like to use some type of jet engine (the ones that create forward motion based on pumping water; so no propellor). I think this would be fast and safe. So before I start creating a newer version of my 2D/ 3D sketch I asked for inspiration from GenAI. Short summary it also came up with a waterjet propulsion idea. For now I will assume I can create this.

GenAI also mentioned the term holonomic robot In short if I could accomplish this UWO would be able to "move in any direction from any orientation, creating an incredibly mobile robot. So, it's easy to move the robot in a congested area".

First 3D model in Solvespace

See week 2 for a description of the process. Just again the result for now.

Week 03

During our local session on Thursday, Henk suggested to discuss our final projects with Bas Pijls; just as an independent person. Regarding my idea he had some thoughts/ tips:

Student Mkhitar (2025) made a submarine; look into that
Water pressure from a "peralstaltic movement" is not fast enough
By the pump; it is very tricky to make yourself
Water tight is possible using epoxy.
Maybe I can create my model from "piepschuim" and cut out what I want (I will learn this during CNC week), then put epoxy in it and suc it vacuum (sounds nice )
Overall do-able but choose what you make yourself

Week 09

So it has been a while since I've updated this page but assignments took over . Anyway this week I again thought about my final project. I think that RoboQuack 3000 is a more suitable name for it.

RoboQuack 3000 is an autonomous swimming fetch companion cleverly disguised as a classic yellow rubber duck.

alt text — created with Grok Imagine using the prompt `a cute yellow rubber duck floating in open water, actively trying to catch swimming people, dynamic action scene, realistic water splashes, duck with determined expression pursuing swimmers`

At first glance it looks like an innocent bath toy, but inside it hides custom-designed electronics, AI vision, navigation, powerfull thrust engine and a couple distinct operating modes (also see week09):

Game mode — it actively chases and tags swimmers with a cheerful quack
Swim mode — it swims steadily in front, maintaining perfect distance to lead the road
Stealth mode — it goes quiet and observes wildlife/ takes photos without disturbing the scene

Week 10

I decided to use the current duck I have. It's no too big, it's nice looking, it's already there. So now I only have to attach a motor in it, give it eyes and some kind of GPS sensor to know where it is.

I therefore took time to 3D scan the duck for the single purpose of using it later on in 3D programs like Blender or FreeCad or whatever. Why? Because I can then take it's measurements and use it to attach a floating platform on the outside and a plaform inside the duck to hold electronics; etc. It's nice for me to do that with a real duck in front of me.

Anyway please see [Scanning RoboDuck]](../finalproject/scanning_roboquack3000.md). And yes I changed it's name again to RoboDuck 3000 (a name says it all).

Week 11

So at the end of global class yesterday (1st of April) Neil mentioned again that midterm review is coming up and I should have finalised my plan by then. Also make sure to explain choices; they should answer a question. Specifically important are:

system diagram
tasks to complete
schedule

I'll therefore use this page as a diary and keep track of questions/thoughts and decisions and use sub pages for more in depth detail (like system diagram, tasks, design, bill of material, etc). I already started with this last week but now I'm sure that's the way I want to go forward.

Thoughts/questions

Based on input devices week and this week were I could try the Grove Vision AI v2 module, I still think that detecting heads/faces is able using an AI sensor. What's going to be a challenge is that it's also able to detect upon a range of 10 meters and under shaking circumstances.
How to prevent the duck from flipping over in water with waves and wind? It is very light.
How to attach the water jet engine to the duck?
How to control the device in early stages; like having a remote kill switch? If it goes off into the distance then I should be able to stop it remotely. Maybe I should just make it completely remotely?
What about water inside the duck? Were do I put the electronics?

Answers?

Maybe I can train my own model on these objects? Using Sensecraft it's not that hard I think; doable. I can then train first with object A and extend that with more objects.
I could make some kind of platform under the duck. I can then also use this platform to attach/ store the batteries. Maybe a catmaran design were the batteries are on both sides? I could attach the water jet in between and just stick the duck on top of it.

image>?

From Irja I got a link to chemicals to make 3D prints water tight. But I'm thinking of making the underwater hull during the molding and casting week; epoxy is water proof. So then the electronics could go in the duck it self. Probably as high as possible; maybe in the head? Also nice place to receive GPS signals and near the camera that I want to use.

image

Regarding remote control ... maybe I should just make it completely remote control. That way I can keep the duck like it is as much as possible. But of course the remote control should then be water tight as well as it will be used near the water.
Maybe a general switch on the duck (on/off)?
Remote control means a way to communicate through air. So not only receiving but also sending (to let the remote controller know everything is ok). What kind of technique can I use for this? From the global class I learned that it depends on power, required functionality and distance.

Trying out

My idea was first to squeeze this pump into an already floating device ...

... but the ships plastic was very hard and I'm not sure how to attach it; maybe first watch a video or something.

Week 12/13

Still in middle of machine week but I also want to work on some ideas for my RoboDuck 3000.

During my midterm review with Henk and Take (global evalator) Henk mentioned that floating would actually be the first priority; and that is true. Once a base platform with my duck on top floats I can add other things. I did also mention that I bought the product Dichtol based on the YouTube video to make any 3D print water resistance (that was a tip from Irja (one of the interns)). But it was their shared opinion hat the coming molding & casting week would be the answer to creating my platform because the base needs to be water resistance; Take also did a lot of experimenting with 3D and water and found it to be very difficult.

Inspiration from others

I mentioned that I'm especially fearfull for my 3D skills with FreeCad/ Blender. So I like to see if/how others made objects that float using molding/casting/3D printing. What kind of shapes and how did thy make it water tight?

I found a couple of websites that I found to be interesting ...

Radio Controlled Duck

Kit-bashing a duck

How to Build an RC Duck - With Arduino and Wi-Fi

Rene the rubber duck boat with a nice video

How I built the fastest RC Duck boat

An extension by the same maker to his radio controlled duck. He does this by using a waterjet propulsion. Good tip is to use velcro (klittenband) inside to attach parts so it can easily be removed/ attached again later on.

Molding and casting

There's a lot of info to take from this. But first I notice that this is mainly 3D printed. So why would I need molding/ casting? What is this anyway? So I looked up a video using a search phrase like what is molding and casting.

I watched about half of it and my take on this:

molding is the process of creating a container or "negative" impression of an object
casting is the process of filling a mold cavity/ container with a liquid material (for instance silicone, plaster, epoxy, or steel). The end result is the "positive" object again.

And yes I understand that I could use it to make a more water resistance platform on which the duck sits. I mean using silicon would even make it a bit soft so that when somebody hits the platform of the duck they are not hurt that much.

From my 3rd week I wrote down that the advise then was to make a mold from foam, use epoxy and then vacuum it. I don't know yet how that works and why that would be usefull but it sounds fun

So for now I'll assume that the platform will be created using molding/casting.

alt text

To access all the inner parts it would be wise to create a hedge on top of it that can be closed with some screws. To make sure no water comes in I can use a sealing.

alt text

Other parts

The camera/ gps sensor will be mounted on the outside of the duck as high as possible. One way I can do that is by making it really look like a Robo duck; for instance by putting on a helmet like RoboCop.

As I have a scan of the duck I could 3D print the helmet and paint it later on with a silver metallic spray. Behind the visor I could make sure the camera can see outside. The GPS sensor could be just under the top of the helmet!?

Week 14

I used the Sunday to work mostly on my final project. As I promised myself I need to get something to float. As I bought a 3D printer I want to have an idea whether or not the duck will float when it's on top of a platform. So I decided to 3D print a first version of the platform.

Design process (again)

Here are pictures with explanation of the process.

Then I started playing around with different layout's of possible components. Largely influenced by the power bank I want to use and the water propulsion system.

Oh and I need to be able to use my hand from the top to change batteries later on. Let's test if there's space.

Ok enough for now. I will try to find other batteries that provide 12V (for the motor; could also be 2x6V of course). Time to take some first measurements to desing it/ something in SolveSpace.

alt text

SolveSpace

I'm getting more familiar with SolveSpace. But I still found it time consuming. Here are some in between mistakes.

I found out that for revolving I should only draw part of the drawing. So half a rectangle or half an object instead of it's symmetry alread. So when I started doing that I got better results.

alt text

Well it's not the result I really want but spiral desing and will it float so let's just print this one.

But will it float ...

Ok well yes I have somethig that floats but I found that:

needs to be deeper or needs side baland aotherwise duck wil flipover / wings
and place hodler for the duck/ so it stays in place

What about weight that might actually be used

Well it floats and water is NOT coming in

Design proces (again)

I ended up using duck tape to fixate the motor and to keep the water out. I used an older battery I had (7.4v 1300mAh) to power the motor for now and just turned it on and see what it would do.

it floats, it has some thrust despite the nossle not being attached

Learned/ decided/ questions:

the 3D printed platform does not let any water through despite being printed with DRAFT like settings.
the 3d printed platform is light; what if I change that for epoxy; won't it become to heavy?
I'm definitively NOT opening up the rubber duck. It would have to make some kind of mechanisme to close it of and attach it to the platform etc... This would only create more problems. So I'll stick to the helmet idea
to enable thrust the platform is to be below water. So it must be made heavier. A power bank will do that I think. BUT I should lower the point of gravity to make it more stable (like a sailing boat)
It also means that the service hole (the one I need to get into the hull) needs to really be water proof. This I could solve making some kind of hatch that has silicone/ flexible rubber as an inlay and use screws to close it
The bottom can be a bit thinner I think; now it's 5mm; my guess is that 3mm is enough

Week 14

At the start of the week Henk/ Remco gave me nice input.

Epoxy is indeed much heavier than printed plastic. So idea to continue with 3D printed hull is ok for now
Why not move the GPS sensor in the hull? Does not need to be on top; in a building you can receive the signal as well; so will do fine in the hull. This also means that the electronic parts for this can move into the hull
Helmet with electronics; why not use a longer cable and different camera? Then electronics for this can also move to the hull. Henk send me two links: https://nl.aliexpress.com/item/1005009339247009.html and https://nl.aliexpress.com/item/32820946214.html

Week 15

Ok 3 weeks to go; it's going to be fun.

During the week's assignment I tested the range of the connection between my laptop and the ESP32C6 via BLE. I ended up with a ESP32S3 that runs a Wifi access point that is connected to the Grove AI module. Wifi gives me a two way communication and enough range. I also built a small UI to talk to the the ESP32S3 using web sockets. The content for the UI is sent by the ESP32S3; it consists of Javascript with p5.js library and html.

Training AI model

I also found this article. It explains another way to create a model from scratch and convert it so it can be uploaded via SenseCraft.

It's good to know for now.

Working on the hull

to my surprise I got it working again with the receiver; even with the micro server I intend to use

Working on the hull prototype

My idea is to first complete the prototype of the hull and use this to try out everything. But for this I need to put it also into the water.

Navigation

Time to unbox the GPS module from SeeedStudio that's based on the GPS Air530Z. I bought it a while ago because of the benefits for my outside project.

It supports GPS / Beidou / Glonass / Galileo / QZSS / SBAS, which makes it suitable for GNSS positioning applications such as car navigation, smart wear, and drone. Meanwhile, this module is capable of receiving more than 6 satellites at the same time and is able to work excellently even if there's a very bad signal. Low power consumption at only 31uA

It has a nice manual which is in Chinese The wiki tells me more.

The basic code they provide

#include <SoftwareSerial.h>
SoftwareSerial SoftSerial(2, 3);
unsigned char buffer[64];                   // buffer array for data receive over serial port
int count=0;                                // counter for buffer array
void setup()
{
    SoftSerial.begin(9600);                 // the SoftSerial baud rate
    Serial.begin(9600);                     // the Serial port of Arduino baud rate.
}

void loop()
{
    if (SoftSerial.available())                     // if date is coming from software serial port ==> data is coming from SoftSerial shield
    {
        while(SoftSerial.available())               // reading data into char array
        {
            buffer[count++]=SoftSerial.read();      // writing data into array
            if(count == 64)break;
        }
        Serial.write(buffer,count);                 // if no data transmission ends, write buffer to hardware serial port
        clearBufferArray();                         // call clearBufferArray function to clear the stored data from the array
        count = 0;                                  // set counter of while loop to zero 
    }
    if (Serial.available())                 // if data is available on hardware serial port ==> data is coming from PC or notebook
    SoftSerial.write(Serial.read());        // write it to the SoftSerial shield
}


void clearBufferArray()                     // function to clear buffer array
{
    for (int i=0; i<count;i++)
    {
        buffer[i]=NULL;
    }                      // clear all index of array with command NULL
}

So I tried this out with a basic setup using an older PCB I made

alt text

After turning it on

Knows where it is

Ok then switching wire, uploading code I got a lot rubbish ... maybe to fast? I adjusted the speed to 9600 and then it worked fine.

I looked for info on the info coming out of this sensor. Via this article I was directed to an English translation of the Chinese manual. From this I get that I can send commands to it. But also that a lot of people are using this and that there are libraries.

Below is piece of the output that goes on and on

$GPTXT,01,01,01,ANTENNA OK*35
$GNGGA,164442.000,5218.96475,N,00503.42767,E,1,19,0.7,3.9,M,43.0,M,,*40
$GNGLL,5218.96475,N,00503.42767,E,164442.000,A,A*47
$GNGSA,A,3,01,03,04,06,09,17,19,28,31,,,,1.4,0.7,1.2,1*3F
$GNGSA,A,3,07,10,11,12,19,20,23,29,32,35,,,1.4,0.7,1.2,4*37
$GPGSV,3,1,12,01,31,139,36,02,,,15,03,62,075,41,04,66,174,29,0*52
$GPGSV,3,2,12,06,40,304,37,09,37,209,34,12,,,26,17,33,234,37,0*57
$GPGSV,3,3,12,19,39,271,37,25,,,25,28,18,040,30,31,28,068,33,0*56
$BDGSV,3,1,12,07,25,045,32,10,26,056,20,11,25,173,30,12,82,225,32,0*7D
$BDGSV,3,2,12,19,52,239,27,20,76,066,39,23,11,051,20,25,,,13,0*4F
$BDGSV,3,3,12,29,41,192,38,30,,,14,32,18,062,22,35,50,281,36,0*4F
$GNRMC,164442.000,A,5218.96475,N,00503.42767,E,0.00,102.38,040526,,

Appearantly the output is in the NMEA format.

NMEA is an acronym for the National Marine Electronics Association. NMEA existed well before GPS was invented. The purpose of NMEA is to give equipment users the ability to mix and match hardware and software. NMEA-formatted GPS data also makes life easier for software developers to write software for a wide variety of GPS receivers instead of having to write a custom interface for each GPS receiver. There are different NMEA sentence type, and the type is indicated by the first characters before the comma

Ok, this is rabit hole, so it would be helpful to use a libary. As Arduino itself does not provide one (I've looked but nothing with GPS Air etc..) I found an option. Looking at the header file and the example code the author provides a way to send commands to the sensor to only get what you want.

My plan is to keep it simple for now, just pick out the lines that are related to my regional area and later on send commands if needed. But what info is for my region?

Example: $GPRMC,092750.000,A,5321.6802,N,00630.3372,W,0.02,31.66,280511,,,A*43 Means: UTC Time 09:27:50, location 53°21.6802′N 6°30.3372′W. Speed over ground 0.02 knots, course over ground 31.66°. Date is 28 May 2011.

Without a big library I should be able to read lines from the output and then split that string into these parts.

Looking at the output I don't see GPSRMC but I do see GNRMC. This indicates appearantly that the data comes from a combination of multiple satellite navigation systems, not just one; GN = GNSS (Global Navigation Satellite System).

I then worked on a basic setup of the code which let me think about the PCB design.

PCB

So the Navigation module will take care of managing the motor, the micro server while getting input from a GPS sensor. On top of that it takes commands from the central unit via I2C; also to communicate back. Based on that idea I extended a design I made a time ago.

Is everything ok enough to switch to Kicad?

During the group assignment we worked with I2C between PCB's so this should work here as well.
I tried the micro-servo before and remembered that Kris (from Finland) suggested to add a capacitor. Because they can create big, sudden current spikes when they move for a fraction of a second. This can lead to: jitter or even the MC resetting because of the power drainage.

Looking at AdaFruit

You can usually cure it by adding a high value capacitor (470uF or greater) between GND and 5V on the breadboard. The capacitor acts as a reservoir of electricity for the motor to use, so that when it starts, it takes charge from the capacitor as well as the Arduino supply. The longer lead of the capacitor is the positive lead and this should be connected to 5V. The negative lead is also often marked with a '-' symbol.

What about the Mosfet?

Well at home I used the book Practical Electronics for inventors to come up with this and according to this source I need to add a pull-down resistor between the GATE and SOURCE of the MOSFET.

alt text

Note

It gave me the idea to have an atonomous home function built-in. If the duck would loose it's connection during more than 5 minutes it would go home to a pre-programmed location.

Week 16

At home, I spend the last part of Wednesday drawing schematics and options of my logic/PCB's etc.

System design

Note

I'm aware that the RP2040 that will run the navigation unit is going to be busy. I was also concerned that it could not do these tasks in parallel (PWM on micro servo, PWM for the motor and reading UART). But a quick search on the internet linked me to a Github repo that enables me to use Hardware-based PWM channels on RP2040-based boards. Again a todo thingie.

Hull design v2

Based on input from the group I struggled with the idea of a tunnel and then attach the battery below that. I also worried more about the possible speed of the duck (meaning not at all ) and what's does it mean to be a RoboDuck then?

Long story short I did a bit of flip thinking. Why not use 2 jets.

alt text

The hatch problem does not get worse or better but sure enough I can now lower the battery like the keel of a sailing boat for more stability. The 2 jets will at least mean more speed than 1.

Regarding steering ... Option: I don't need the micro servo's anymore. To steer I could just have more power on 1 jet and less power on the other. Other option: have a central rudder attached to the micro-servo.

Visualize design hull v2

First I switched to the latest stable version of Solvespace; release 3.2 from March 2026. Good to know they are still enhancing the software.

Before lunch I wanted to print the battery holder. Piece of cake. BUT NO :sad: .. I had a lot of trouble with the boolean operations.

Later that day I just started again; this time with better results.

Then updated my documentation until that moment.

Visual design battery holder

So the holder will be under the bottom and fixated using silicone kit. But if the bottom of the holder brakes the power bank could slip out. So I wanted to enforce the structure by creating two crossbars on the side with a pin going through just for extra safety.

BUT WHERE'S THE BOTTOM OF THE HOLDER??

Visual design hull v3

With my notes/ measurements I went back to SolveSpace to model my hull; specifically the outer parts where the waterjets should be fitted. So a hole in the back and below. This time I described the process in week 16 assignment. To summarize I hgad Some of the images I've duplicated here as well

Week 17

Working on wiring

Then I changed the end of the Grove cable, the one coming from the Grove Vision AI module, to have the same type of 4 connector as the one I already attached to the GPS sensor earlier on

Visual design hull v4

My goal is to design the lid and see where I can put the electronic components. So I first inspected the outcome of the previous design.

Improving this and maintaining the centre of gravity would help me reduce time to create the hull and make it nicer. Like the duck really sitting on top of the hull. Bit let's first start with the lid.

I drew the option of the classic idea of something that could be places on top with some kind of sealing on both sides of the "contour of the hull" .. And to close it and unclose it (to take out the battery etc) I decided to use bolts on the outside. Not everywhere but for instance 3 on both sides and 1 at the back.

Experiment

I did some experiments in SolveSpace how to draw this. That was a good idea as I still mix up the boolean operations; it appeared to be a horrible exercise; took a lot of time. I started with some experiments in a new design

Then I remembered again to start from outside in. So I created the bigger hull first(!) and then subtracted the outer contour from it

Ok now let's add areas for the future bolts to go through

Then I worked from the same idea to have a big area and subtract my design from it. So I first tried this inside my current design.

So I fugured out that this can only be done by making a new design and linking the old one as assembly; then it could be treated with the option difference

alt text

This means however that I will have to copy the contour of the hull at the top and copy it to a new design later on. Because I can't now shift layers in my current design (or at least I can't find that option).

Experiment 2

So I thought to change my current design and then later make the lid; in the way I just described.

But then I exported the contour just for fun and viewed it in PrusaSlice

alt text

I could not lay it down because it was too big, even for a Prusa Core ONE (arggghhh). I can't print it that way. The only way to do that is to make the design smaller like I suggested earlier that day. So I started again with a new design. The big difference this time was that I really tried to WORK FROM OUTSIDE IN

alt text

Remark: I did stop the printer 2 times just before it would start

estimated time is 1h45m; that's 1 hour less than the previous design

It came out like this

alt text

The lid

The next morning I subtracted the design from the extruded contour of the duck itself. Like I tried the day before. I printed this

PrusaSlicer trick

After our group work regarding the use of composite materials I went on with the design of navigation pcb.

Because Remco had some problems this week I discussed his latest settings. Based on this I used a cut depth of 0.004 inch instead of the usual 0.003inch and offset 4 (as usual).

Henk and I discussed how this could have happened but we ended up having no clue. Just try again. Restart the browser. Also Henk mentioned that the top layer was not cut deep enough? Again strange. Henk releveld the bit in the middle of the PCB(!!) using a paper to see if it was bearly holding it. After this i tried again.

Even then the top layer was still not milled properly; much better than the first time though. Henk suggested to mill it again using 0.005inch cut depth.

Both MOSFET's have a surface that needs to be soldered onto the pcb area itself.

In the evening I saw that at least the power line worked

The ESP32S3 (on the left) is powered by a USB cable. From there the RP2040 is powered and from there the GPS sensor

Note

The ESP32S3 could communicate via I2C with the RP2040 so that's good. I then tried to get power out of the MOSFETS. Basically I got something but it is either 12V or nothing. Work in progress.

Design motorholders

Started with a design in my sketchbook after measuring everything. My idea is to have 2 rings: one at the front and one at the back leaving an opening for cooling in the middle

So extended the inner ring diameter and tried again

But before just printing a newer version I want to solve the angle; I managed to do so creating a seperate plane that was skewed and used that to draw the outer and inner circle

After printing this it the inner diameter was still to narrow; why?

alt text

So I printed a new one (again) but still not ok; huh????

alt text

I measured the inner diameter of the last version and found it to be 27.3mm exact as specified in SolveSpace; amazing! But it should be at least 27.35mm as I measured the diameter of the motor again. Well yes that explain a lot. I now changed it to 27.45mm. It is still very tight and if the motor heats a lot it will expand. So I will try another version with 27.55mm inside diameter.

Design Grove AI module holder

Parallel to printing the motor holder I worked on a holder for the Grove AI module v2. As it has the ESP32S3 chip on top with Wifi, I want it as far away as possible from the GPS sensor and a bit elevated from the bottom in case some water comes in.

I iterated through a couple of designs and printed it almost right away; sometimes with the motor holder together.

I printed a 4th version which is now ok.

Lid with magnets

Before working on a 2nd version of the lid I went over the design, got rid of (almost) all degrees of freedom and found that the centre line of the power bank was not exactly the middle.

I found a new way of creating the lid:

Floating experiment

Bringing it all together ...

When I put it in the water ...

Houston we have a problem

So it needs weight .. and I don't want to put in my power bank just yet. It ways around 390gr.

ok no flipping anymore; but it's skewed?

So the cause is most probably a bit of balance and the fact that water was coming in that choose one side to go too

But I have another issue ... the water jet intakes are under water but the nozzles are not. No thrust if it's just throwing out water in the air. I need more weight for now.

Week 18

Back to PWM

So at least it does something; but why again?. To be honest, I'm a bit rusty on explaining Pulse Width Modulation to myself so I looked up the standard Arduino documentation about this subject.

Pulse Width Modulation, or PWM, is a technique for getting analog results with digital means.

So digital control is used to create a square wave = a signal switched between on and off

So in case of PWM frequency is set to 500Hz it means that each green line represents 2msec (2 miliseconds; 1/500). The value I set via analogWrite() basically means that I tell the microcontroller how much of the time I want it to set this cycle to on.

In my case, were I use it in combination with a MOSFET, it will produce an average voltage to run the motors; like with the LED dimming exercise we did a while back.

But what frequency should I use? It doesn't say anything about the frequency that is suitable for DC brushed motors though.

I found this article.

Rotor coil inductance becomes an important factor to consider when using PWM for motor speed control. The motor coil works best when the applied voltage is relatively steady since it needs time for its magnetic field to reach the needed strength. At higher PWM frequencies, the pulses from the motor controller board change too quickly to provide enough energy to spin the motor ... When the PWM frequency is lowered, the motor’s coils extract more energy from the pulsed PWM signal. That means that the motor will start spinning at a lower equivalent voltage and will operate with improved torque at low speeds.

The article even mentions a frequency of 20Hz or, if this leads to too much chatter, use 400Hz. But it also refes to a geared motor.

My take on this:

Higher PWM frequency means that the motor has less time per pulse to build up power to move; lower torque; but smoother operation
Lower PWM frequency means that the motor almost reacts right a way, higher torque but may feel/ sound a bit rough.

So when silence is the thing I want (and I want this) a higher PWM frequency is preferable. But does it have to be 20kHz?

Let's test all of this.

I therefore did a small experiment performing the same loop at different frequencies:

20Khz: fine, spinning start audible around a value of 30
10Khz: smiliar to 20KHz
5000Khz: a distance anoying sound is in my ears which disappears when the value reaches around 200
2500KHz: even worse than 5000Khz
1000Khz: I hear the motor having trouble; it doesn't like it
anything lower than this ended up in a lot of noise and poor performance

So start 20Khz is good enough for now.

Testing the motors

I hooked up one of the motors to the right output and run a small PWM program consisting of

// setting the motor pins as output
pinMode(MOTOR_LEFT, OUTPUT);
pinMode(MOTOR_RIGHT, OUTPUT);

// setting the PWM frequence to 20kHz
analogWriteFreq(20000); 

// then use
analogWrite(MOTOR_LEFT, <number>); // this to increase the duty cycle and therefore increase the load on the motor

I ran a loop increasing from 0 to 255 and have small breaks in between them. Well the good news is that motors actually work/run.

At full speed the motor draws around 0.18A of current at 12V; given that is has no workload at the moment!

Note

When at max they draw each around 0.18A at 12V. I even tried to stop one with my fingers and that was difficult to do but then the load increased to 0.35A. When I really tried to stop it I burned my fingers a bit and the current reached around 0.9A.

Note

I measured the amount of decibels between a frequency of 20kHz and 10kHz. Although the 10kHz sounded/ felt a bit louder it was around the same; between 69-71 decibels.

I then tried to increase the range to 270 but found it didn't matter; a value of 270 gave the same loudness/ result as 255.

Note

Looking up the function analogWrite() this makes sense. The value has a range of [0,255] = the duty cycle: between 0 (always off) and 255 (always on). Any value higher than 255 doesn't make a difference.

Next related function is analogWriteResolution(). Looking it up I found

Its meant to leverage the full range of the DAC and PWM outputs It defaults to 8 bits (values between 0 - 255) for backward compatibility with AVR based boards. The value can range from 1 to 32

The microcontroller is the limiting factor. So if it supports 10bits resolution this means it slices the PWM duty cycle in 1024 steps.

analogWriteResolution(10); // sets the resolution to 10bits
analogWrite(<pin>, map(<value>, 0, 499, 0, 1024)); // given the value has a range between [0,499]

So how about the XIAO RP2040? Time for its datasheet. Paragraph 4.6 mentions:

It has 2 PWM channels A & B GPIO's are attached to either A or B A channel can be set to a certain frequency (paragraph 4.6.2.4. Clock Divider)

Do I need to set different frequencies per motor? No I don't so using the standard analogWriteFreq() is enough. No special libraries needed specifically for the RP2040.

Next I need an idea whether or not the resolution makes a difference. I therefore made some code to experiment with 8 and 10 bits resolution. My conclusion it that you build up more slowly to the amount of power you want to apply BUT the final output stays the same.

Another question is IF, once I set a value via analogWrite() this remains that way until I set another value. The idea is that micro-controller can do other stuff in between.

Power

I also found the my powerbank just stopped when the current stayed below 0.05A during a longer time. For this I also did a small experiment. I set the motors to 20% during 1 minute; this lead to the power bank turning off. Jaiks ...

I therefore connected everything to see if it would draw enough current to keep the powerbank going.

And what if I connect my micro-controller to this same output? So I connected the brain via USB-C to the powerbank and watched it for a while. It kept running. And on a type USB-A output? (reason for this is because I have just one USB-C type of exit on this powerbank). And after 10 minutes it was still running.

Note

Hooking everything up led to the burn-out of my ESP32S3 :sad: ... The only thing I can think of is that it somehow got more power on a pin then it could handle. Because instead of hooking up the ESP32S3 to the USB power directly (as designed) I hooked up the RP2040 instead. I did a test earlier which was not a problem but I guess I must have turned the connector around somehow. Anyway, it was still blinking though; no white smoke or something.

Note

When I hook up the RP2040 to the USB-C directly it throws out 5V to the GPS sensor. According to the specs this should not be a problem. I see it's blinking again so never mind.

Lessons learned - design updated

Lessons learned sofar:

frequency 20kHz
8-bit resolution
connect 12V to the USB-C type of the powerbank to power the brain
power the motors via a seperate 12V source (which I ordered a while ago and just received)
use the cables as designed to power the rest

My final setup will probably look something like this. 12V from a seperate battery and 5V from the USB-C socket to the brain via the powerbank

GPS sensor

Most of my morning on Friday I spent on getting reconnected with my GPS sensor. I measured if it would get power, I revert to very simple code to read it, I read the manual again. But because it already worked again a couple of days ago I was really lost.

I therefore just tried a completely different GPS GT-U7 GPS Module. I soldered the pins onto it and gave it power via a small micro-usb connection. When I started the serial monitor instantly I saw data. I then wrote some code to work on the ESP32C6 and there it worked as well. I then switched to the RP2040 using PlatformIO and just changing a few lines of code it worked there as well.

My guess is that it might be the cable and/or attachment that's not working or I also burned this one to the ground yesterday.

Result ... appearantly one time per second, less than the Grove sensor .. but fine for now

Wifi access point

Henk gave me a new ESP32S3 to which I soldered pins. I then referred to old code I wrote a couple of weeks ago were I made a hand-gesture game using the ESP32S3 as Wifi access point and front-end code that I uploaded via little filesystem. So I spent time on cleaning that code up as a base for my Roboduck3000.

I worked on the code until it was sending every command from the UI to the Wifi server where it showed up in the serial monitor.

Now I want the brain talk to the navigation unit. So I added just a piece of code in the brain's code

    Wire.requestFrom(I2C_NAV_ADDRESS, 6);    // request 6 bytes from peripheral device #8
    while (Wire.available()) { // peripheral may send less than requested
        char c = Wire.read(); // receive a byte as character
        Serial.print(c);         // print the character
    }

I then updated the code for the RP2040 to always respond something (at least 6 characters). This was based on the experiment that I saw the master send a request only once. But of course looking at the loop above this is normal. I would send "" (empty string) so it just waited there.

The brain asks for detection of images from the camera via the AI module. At the same time 123456 means it get's a response from the navigation unit after it asked for an update

My short conclusion is that my PCB is ok. I attached the wires exactly like my PCB and the system is just working.

Back to design of the parts

On Saturday morning I first sat down and started with notes on what I still had todo.

I basically picked these up one by one in SolveSpace.

Motor holders

In between I adjusted the motor holder and printed newer versions using transparent PETG filament (just to see what it would do).

Remark: The filament I used was from a Dutch company Real filament. They provided special config files for their filament which I installed on Prusa slicer according to their manual. Yes I saw a list but as soon as I selected my own 3D printer they were gone. So I choose the Prusa PETG config for now.

Overall length and height of the hull

Back to picking up the changes I also changed the overall length/height of the platform; no reason to have a lot of air inside when it's not needed and it also lowers the centre of gravity. Because I also wanted to test the water proofing my idea was to now print at 0.2mm instead of 0.28 to reduce the width of the holes inside which enable the Dichtol to do it's work. And I like the motors I wanted to use PETG for the hull as well because it would make it lighter.

But just before I pressed start I remembered to also adjust the system by which I close the lid. I want to bolts going from the top from the lid through the lid to the inside of the hull were there are nuts.

Next day I inspected everything more closely again. It needs some tweaks.

on top the holes for the bolts should be a bit wider so theh fall in like the magnets / /the

Again making notes for myself

alt text

Back to design and printing again; making adjustments according to plan

floating anchors? No that's not a good idea

So the result

alt text

And the lid

alt text

Later on I also made a small test object with a lid.

Waterproofing

Converting 12V to 5V

I've to make a decision regarding power.

So 12V it is

So at our Fablab I showed Henk my 'off-the-shelf' solution for the 12V to 5V conversion (and the RP2040 can take 5V as input on it's pin and yes I can store this converter inside the battery holder).

"But Henk, it must be possible to make it smaller right?"

And yes indeed, Henk provided me with a couple of links to so called voltage regulators that are available at our Fablab:

https://www.digikey.com/en/products/detail/diodes-incorporated/AZ1117IH-3-3TRG1/5699682
https://www.digikey.com/en/products/detail/onsemi/NCV1117ST50T3G/1792666
(towards mA) https://www.digikey.com/en/products/detail/texas-instruments/LM3480IM3-5-0-NOPB/270721
https://www.digikey.com/en/products/detail/texas-instruments/LM3480IM3-3-3-NOPB/270720

Remark: the ESP32S3 can have 5v input but only via USB-C; on it's pin it can handle 3.7V.

To focus I need to convert 12V to 5v or 3v3. But what kind of current are we talking about? Well the information about the RP2040 is not very helpfull; basically no info there. But I remember from the tests I did last Thursday (using the Mosfets) it uses around 0.04A = 40mA ... The ESP32S3 uses around 50mA in active state.

So (like Henk suggested) I can use seperate regulators for both the RP2040 and ESP32S3 and I will use one that's in the range of 100mA (because that's enough). This leads me to:

150 mA Low-Noise LDO Regulator converts max 16v to 3v3 for the ESP32S3
LM3480 100-mA, SOT-23, Quasi Low-Dropout Linear Voltage Regulator converts max 30V to 5V for the RP2040

Fixating electronics on the inside of the lid

Regarding fixating several electronic components / Navigation PCB on the inside of the lid Henk mentioned the use of double sided tape and inserts.

3D inserts

I watched this video and learned:

temperature should be set to around 240 degrees Celsius
use a square solder tip if possible (usually soldering tips are conical) because it will otherwise stuck to the nut you just inserted
don't push them all the way in because they leave burn marks around them. Instead leave 1mm and turn it around and put it on a flat surface which will push it all the way in
for inside holes you can use a flat bolt to push it in

Regarding the diameter of the holes in the 3D design they all refer to the specs from the supplier.

Anyway it looks promising.

When using the M2 bolts than I'm dealing with these specs

I therefore created a 3D printed block that contains a lot of different diameters.

On/off switch

My idea of a general on/off switch is to use magenetic pogo pin. It will go through the lid. Part of it will be attached to the duck

Once it clicks, it can act as a switch

Intermediate reflection

I made a couple of decisions sofar:

PETG looks nice but for the hull I'll use PLA (tougher and more smooth)
(optional) Use PETG for the lid as it is more flexible and I can see a bit what's going on inside.
Switch to 1 12v power source BUT use the current battery holder design
Use a pogo pin as a general on/off switch (which is now more easy because of the one power source)
Use inserts to attach the lid to the hull
Use inserts to attach electronic components to holders
Use doublde sided tape to attach the Navigation PCB and the holders to the lid
Use the GPS GT-U7 GPS Module instead of that of Seeedstudio; it's flat and I can solder wires to it (and it worked last time)

Consequences:

Design holders for the electronic components
Experiment with inserts / diameters to see how I should design the space for inserts
Adjust design of the anchors in the hull

Holders for GPS

alt text

What I learned:

enough as a holder for the brain
use double sided tape to fixate the holder
use bolts to fixate the chip itselfs

Holder for AI/brain

alt text

What I learned:

enough as a holder for the brain
use double sided tape to fixate the holder
use bolts to fixate the chip itself

Motor and waterjet fixation

I'm still not happy with the way the waterjet is connected to the hull. And I don't want it to move forward or backward too much.

When I tested it ... on the inside there was a lot of stress because the structure was just to near; so I added just 1mm more space and printed a small portion again to see.

What I learned:

new inner design for motors should be enough to keep them in place
outer design of nozzle with holder should cover it

The lid

I still think it's too difficult to get the lid on the hull. The reason of course being that I take the shape of the hull and perform a boolean difference to get the base shape of the lid. I want to try to scale up the hull a bit to see if the contours of the lid on the inside will just be that looser. If that doesn't work then I can always do some sanding.

But that means I need to extend the hull again? No than I would end up in an endless loop

Next idea is to, whenever I have a new version of the hull (and when the outer rings has changed), to copy it as new version. In that version I will increase the wall thickens from 2.0mm to 2.45mm. That version is then imported into the lid version.

I learned:

use the copy technique
scale the inner wall to 2.45mm thick
use that version to create the inside of the lid

Week 19

Converting 12V to 5V and 3V3 (continued)

Based on Henk's idea I'll convert 12V to 5V and 12V to 3V3 (for the ESP32S3) so that the RP2040 does not have to provide all juice to the GPS sensor and the ESP32S3.

Important: to include a switch like connector so that the pogo-pin can power on/off the whole system

The datasheet for the MIC5205-150mA-Low-Noise-LDO-Regulator shows this info

Leading to an updated schema

alt text

But I have problems with tracing the 12v-3v3 converter.

Now I need pin1 and pin3 because otherwise it won't do anything. I can use a wire etc but that's not prefered. So I tried to see what others did. I found Bowen who mentioned using a 3v3 - 1A converter. It has the same kind of shape as the 12v-5v converter with only 3 pins. And then I started to doubt ... why not just 1A as max ... The grove can be consume together with the ESP32S3 (wifi etc) .. it's a small change I can still make; and why not do the same for the 5V to the RP2040; just in case.

I looked at the lab inventory and found these 2; both can be found in Kicad as SOT223 family

alt text

5v and 3v3 datasheet

So for both I have to add 2 capacitors

alt text

I therefore measured the 10muF as 3.1mm long and 1.5mm wide. According to (for instance) this info I need a footprint that's equal to C_1206

It took a while but I finally managed to create a PCB that wasn't too big

alt text

Milling it with the MDX ...

Second time it didn't go through again. This time Henk centered the bit on the middle of the area and now it was ok.

Experimenting with inserts

What I learned:

heat up around 10-20 degrees more than the printing temperature (in my case PLA 170 so used 190 degrees)
make sure there's room underneath the insert; because plastic has to go somewhere
just insert until 1mm and push the remaining part with another tool or just press it on the table if possible. That way it won't go in too far

Final project journey (all weeks)

Week 01

Swim monitor

Solution

Visuals/ mockups

Non-functionals

Open water buddy

Solution

Visuals/ mockups

Non-functionals

Week 2

UWO

NORMAL MODE

Scenario 01: GUIDE ME

Scenario 02: FOLLOW ME

GAME MODE

Scenario 03: CATH ME IF YOU CAN

Scenario 04: JAWS

WILDLIFE MODE

Non-functionals

System integration

UX

Navigation

Awareness

Imagery

Navigational lights

Central unit

Visuals/ mockups

First 3D model in Solvespace

Week 03

Week 09

Week 10

Week 11

Thoughts/questions

Answers?

Trying out

Week 12/13

Inspiration from others

Radio Controlled Duck

Kit-bashing a duck

How to Build an RC Duck - With Arduino and Wi-Fi

Rene the rubber duck boat with a nice video

How I built the fastest RC Duck boat

Molding and casting

Other parts

Week 14

Design process (again)

SolveSpace

Design proces (again)

Week 14

Week 15

Training AI model

Working on the hull

Working on the hull prototype

Navigation

PCB

Week 16

System design

Hull design v2

Visualize design hull v2

Visual design battery holder

Visual design hull v3

Week 17

Working on wiring

Visual design hull v4

Experiment

Experiment 2

The lid

PrusaSlicer trick

PCB Navigation

Milling the PCB Navigation

Soldering the PCB Navigation

Testing the PCB Navigation

Design motorholders

Design Grove AI module holder

Lid with magnets

Floating experiment

Week 18

Back to PWM

Testing the motors