MonoBot: Aerial Robotics Project
 

MonoBot is my project that I will be working on next couple of years. I want to utilize MonoPhan tech in aerial robotics, via use of sensors and Arduino.

Below is the first MonoBot unit that I started testing the Baro, GPS, etc with. Its brothers are in the making. The first flight tests went well and I was pleasantly surprised with the first baro altitude hold test. Next steps will be testing the GPS, position hold, return home and autonomous missions.

After that I will go into Arduino with some other sensors and will have some more fun:)

Attached video shows a bootup. The top red light on the I2C shows the 3D GPS lock (triple blinks). I was too lazy to record the first flights but I will be posting some videos as I go along.

Thanks!

https://www.youtube.com/watch?v=oCF-YdKjBWw

https://www.youtube.com/watch?v=oCF-YdKjBWw

It’s been a while since the last time I can pick up the Mono for a test.

When I powered it up, the first thing that I saw was that the GPS reverted to the original code, going back to 9600. I couldn’t resolve this issue. I flash it with the code and save the config (which was the step that I have been missing when I first started) it works at 115200 baud rate, communicating with the I2C board. Then I power it off and if I power it on soon after, no problems. It works. But if it waits for a couple of days, it reverts back to 9600 baud and needs to be re-flashed. If anyone has some useful advice on this I would love to listen.

After re-flashing it and getting the GPS to work, took it up. These days it is very windy and I don’t want to test it in strong wind but I didn’t have an option as this is my only available time. Before the flight, you will see the baro kicking in as I holding it, moving it up and down.

During the flight the baro&GPS combination were activated multiple times. First one minute or so, I am trying to trim the unit to get it to stabilize a little bit. The first baro&GPS activation was at 2:10 minute mark and the unit lost altitude pretty fast, causing me to de-activate them right away. The second activation is at 3 minute mark and a couple of more times after that. You can hear the fan adjusting to compensate when I activate it. However, this test was more challenging than my first one last a couple of weeks ago, as the unit slowly lost altitude this time, with the fan kicking in and out in a rough manner. I didn’t change the settings, but that day there was no wind at all. I believe this is the difference. The sensor is affected by the wind. So, I will need to cover the controller and test it again, to see if it fixes that problem.

When it comes to GPS, I kinda felt some added stability when I activated it but the unit still moved slovly with the wind. So, I will have to make some PID changes on that. I was able to connect to the FC via Bluetooth and my phone, which will make it very convenient to test in the field with various settings.

I would appreciate any tested valuable methodology on how to set the PID for GPS and Baro, as I have never tried those before.

Thank you for checking out. Enjoy the video:)

<a href="https://www.youtube.com/watch?v=GypskvdVBKk"> https://www.youtube.com/watch?v=GypskvdVBKk

The first test was in a calm weather and I didn't experience this BARO problem. So I will cover the flight controller to avoid violent air movements and see.

Before this tho I am working on the GPS to hold the code when unplugged. Looks like the battery that preserves RAM is depleted. I detached the original tiny battery and tried it with another 1.5 V battery no luck but the second test with a 3V battery is more promising. I'll wait a day or two and see if it reverts back to the original code or not.

I believe my solution to the GPS code reverting back to factory default worked. One day after I hooked it up to a 3V external battery, the code is impact. It connected to i2c when I booted it up. I will keep this battery external and replace it as needed, which shouldn't be any sooner than a coupe of years, being 10 times larger than the original that was on the GPS.

Attaching a pic of what I did. Next step is making sure the baro sensor is not impacted with airflow.

http://www.rcuniverse.com/forum/atta...mentid=2157403http://www.rcuniverse.com/forum/atta...mentid=2157404http://www.rcuniverse.com/forum/atta...mentid=2157405http://www.rcuniverse.com/forum/atta...mentid=2157406

This is where I got so far:

• The GPS unit was moved to the middle from the side.

• The tiny internal battery if the GPS was replaced with a 3V larger external battery to preserve the code from reverting to factory default,

• The Bluetooth module was placed under the FC, to be able to adjust PID in the field with my phone.

• The sides, front and back of the FC was covered to stop airflow affecting the BARO. The back was covered with a transparent plastic so I can see what the FC is doing.

Hoping to do a test tomorrow and see what it does…

That Bluetooth gui software completely messed up the controller, to the extent that I had to flash it twice, erasing every little bit of information stored in it. Even the nozzle algorithm was messed up!!!

Below is the video of the second test. I believe the P setup was as follows:
Baro:6.8
Pos:1
Posr:2
Navr:2

Very windy day. You will see me shoot the unit forward and activate the baro/gps combination on the way back a couple of times; at 1:40 and 2:40 minute marks and somewhere towards the end.

No luck. First of all, baro is inconsistent. Sometimes it holds the altitude, sometimes not. Overall it still loses altitude. The GPS didn’t do too much to hold the position either.

Next test will be with the following setup:
Baro:10
Pos:2
Posr:10
Navr:6

I know that it is a big jump up in the values but I want to see the GPS do something, even if it over compensates.

Good news is that the balance problems that I had with the unit are completely resolved. It feels very confident with the GPS tower on it… Fun to fly:)

<a href="https://www.youtube.com/watch?v=vSXgDFBcJFg&amp;feature=youtu.be"> https://www.youtube.com/watch?v=vSXgDFBcJFg&amp;feature=youtu.be

This is my second test after the last video and my first successful GPS and altitude lock with some amazing close-ups! A little shaky but from 1:35 minute mark to the end I didn’t touch pitch/roll/yaw. I was in control of the throttle until 3:32 minute mark. GPS is a little over compensating but the unit was trapped in a 1m circle. Here is the recipe that worked:

Baro:4.8
Pos:1.9
Posr:8
Navr:6

Considering the wind, I am not surprised that it was doing the rotational move. However, I feel the need to ease the P values a little more. I will probably test below next:

Baro:4.0
Pos:1.8-1.7
Posr:7
Navr:6

Thanks!

https://www.youtube.com/watch?v=6j9CyDdNLTs

https://www.youtube.com/watch?v=6j9CyDdNLTs

After the last video I had a rough landing and somehow that GPS got damaged I guess. It continuously lost GPS lock during the flight. It took me a while to figure that the problem was hardware rather than the tuning.

Plugged in another GPS and all good. Eased PID a little, now it moves smoother and isn’t as shaky as before. The GPS&Baro lock at 00:25 and I didn’t touch the controls until 4:40.

You can see how the wind pushes the unit away from me at 4:40, the moment I turn the GPS off. During the GPS and baro lock, it slowly wandered in an area of 10-15m diameter but always ended up where it started. Stable. Kinda weird watch it fly without touching the sticks:)

Good test…

https://www.youtube.com/watch?v=yReF...ature=youtu.be

https://www.youtube.com/watch?v=yReFUKMmnEw&amp;feature=youtu.be

Testing return home:

The code allows me to override the feature with stick inputs which are outside of the deadzone. This lets me to take the unit anywhere in the park without touching the GPS and the moment I release the stick, return home initiates. After returning home, GPS hold initiates.

After 2:40 minute mark the GPS hold, return home, Mag and Baro features are on. Whenever it is moving away from me I am controlling the action. Then I release the stick and it comes back. There was only one occasion where it got too high and I had to bring it down before initiating return home again.

The part that kinda puzzles me is that, even though the code lets me decide the direction the unit faces while returning home, it is not consistent in directions. When I initiated return home at at the west of the home point, it came back tail in first. When I initiated it at the east, it came in with head first. When I booted it up, it was facing west, so I guess that was the reason. Whenever it returned home, it makes sure that it faces the original takeoff direction, which is pretty cool.

This time I used new batteries instead of my old beaten batteries. I flew it for 6:30 minutes and used %73 of the juice, which gives me 9 minutes theoretical and over 8 minutes practical flight time. Pretty good.

Now I will get it in shape in the current format and start working on some IR sensors to do some more fun stuff:)

https://www.youtube.com/watch?v=xPcy...ature=youtu.be

https://www.youtube.com/watch?v=xPcyqSmwiCo&amp;feature=youtu.be

The new face of MonoBot.

I think I figured why it was keeping the original heading when returning home instead of facing towards the waypoint. The GPS hold was active when GPS home was activated. Now I will test it with GPS hold deactivated when returning home and see if it adjusts yaw to face home when returning...

Never ending winds last couple of weeks. I think GPS settings are good at this point.

In this video, return home/baro/mag combination was initiated twice at 1:30 and 3:30, and both times the unit first turned towards home waypoint and proceeded towards home head first, then turned head towards east after returning home, which was the direction of the bootup. Then I had some fun fly towards the end.

Pretty happy with the progress and how this beauty flies. Amazingly fast, stable and easy to control, even in these mixed winds. Hard to land!

I may tweak the tuning little more in the future but I am happy as it is for now.

https://www.youtube.com/watch?v=kscTFJ5VZG0&feature=youtu.be

<a href="https://www.youtube.com/watch?v=kscTFJ5VZG0&amp;feature=youtu.be"> https://www.youtube.com/watch?v=kscTFJ5VZG0&amp;feature=youtu.be

Takeoff videos:

https://www.youtube.com/watch?v=cxa3i9M22oI
https://www.youtube.com/watch?v=cxa3i9M22oI Let me know if you need #adruinonano driver… Took me a while to find… Started “trying” to build a code:) Fun stuff!

It’s kinda hard to learn programming after a certain age. I finally had some time to work on the Arduino code, to have some fun with the sensors.

First challenge was to pass the rx signal through Arduino. This had to be achieved because it is the base for all future work. It took a while but in the end, thanks to some code pieces that I found online, I was able to do that. However, I still couldn’t figure the servo jittering. Nothing I tried worked so far. So, I will need to learn further coding to figure that out.

After that I wanted to see if I can change a servo reaction with an IR sensor. I used the keyes sensor which basically creates a binary 1 or 0 signal. And the result is promising. Below video shows the servo changing neutral position with the detection of my hand, while I can still control it with the TX.

Will keep on posting as I progress.

https://www.youtube.com/watch?v=jaasgUV7g7c

https://www.youtube.com/watch?v=jaasgUV7g7c

This is my first code solution to the servo jittering. It helped reduce jittering significantly. None of the electrical solutions seemed to work.

The problem is: the servo signal drops from 1480/90 level to as low as 1410 ish periodically, causing the servo to jitter. My current solution is to read the pulse twice in 20 milliseconds after the first reading. If the second reading is below “first reading – 10”, write the first reading. If not, write the second reading. Here is the part of the code that does that:

val = digitalRead(2); //read ir
ch1p = pulseIn(5, HIGH, 25000);
Serial.print ("ch1p: ");
Serial.println(ch1p);
delay (30);
ch1p1 = pulseIn(5, HIGH, 25000);
Serial.print ("ch1p1: ");
Serial.println(ch1p1);

if (ch1p1 < ch1p-10)
{
ch1c = ch1p;
}
else
{
ch1c = ch1p1;
}


And this is the resulting readings. As you will see, whenever there is a large drop the signal is ignored.
ch1p: First reading
ch1p1: Second reading
Channel 1: The value to be written to the servo


Channel 2:0
Channel 3:0
Channel 4:0
ch1p: 1478
ch1p1: 1429
Channel 1:1478
Channel 2:0
Channel 3:0
Channel 4:0
ch1p: 1488
ch1p1: 1488
Channel 1:1488
Channel 2:0
Channel 3:0
Channel 4:0
ch1p: 1488
ch1p1: 1488
Channel 1:1488
Channel 2:0
Channel 3:0
Channel 4:0
ch1p: 1495
ch1p1: 1494
Channel 1:1494
Channel 2:0
Channel 3:0
Channel 4:0
ch1p: 1473
ch1p1: 1436
Channel 1:1473
Channel 2:0
Channel 3:0
Channel 4:0
ch1p: 1495
ch1p1: 1495
Channel 1:1495
Channel 2:0
Channel 3:0
Channel 4:0
ch1p: 1493
ch1p1: 1495
Channel 1:1495
Channel 2:0
Channel 3:0
Channel 4:0
ch1p: 1488
ch1p1: 1487

It has been a while since the last post. It was a challenging period trying to figure out below Arduino tasks:

1. Read/write PWM signal,
2. Read/write PPM signal,
3. Convert PWM to PPM,
4. Build IR distance sensor,
5. Read IR sensor signal,
6. Mix PWM & IR signals, etc…

Frying 3 Arduino boards along the way and taking it slower than I usually do didn’t help with the delays. I tested many PWM, PPM codes, IR sensor configurations. One of the hardest tasks have been getting the Arduino board communicate with the flight controller. In the end, I kinda came up with a setup that MAY work. No guarantees here, tough task for an amateur like myself.

The latest setup has a DSM2 receiver which is not PPM. So I soldered the receiver to the Arduino digital pins to get rid of the excess cables. I preferred a PWM connection because if I use a PPM connection from the receiver, then I need to decode PPM to PWM, mix it with IR signals and re-code it into PPM to feed into the Multwii board. With PWM, I don’t need to de-code any PPM, instead get the 5 channels and process them separately.

I have 6 homemade IR sensors. I tried some electronic configurations that didn’t quite work, so came up with my own design. They can sense upto 30-35cm, which should be enough for the first tests.

I am using my old flight controller but, which I feed with one PPM cable.

Almost ready to install the new equipment on one of my MonoBots and start testing the sensors and revise the code to fit the unit. I am planning to place 2 of the sensors looking up and down. This way, if successful, it will avoid obstacles in all directions.

Will keep on posting as the project progresses. Thx…

The first test of the IR sensors on the actual unit. I didn’t apply my jitter eliminating code yet (I am hoping that I can) so the servos are a little jittery. The jittering will cause the most problem in throttle control. I have sensors at the top and the bottom, too, which will adjust the throttle. When I tested the throttle, the servo signal anomaly that cause the servo jittering caused the RPM swing in a range. The fan still reacted to the sensors and adjusted the throttle but not in a smooth way…

The first test was pretty good though. The video shows the nozzles react to the IR sensors’ input:

https://www.youtube.com/watch?v=tr-sHlNnzA0

https://www.youtube.com/watch?v=tr-sHlNnzA0

I tweaked the code to overcome the PWM anomaly that caused the servo jitter. The anomaly was causing the throttle to really bounce around and I wasn’t going to be able to fly it that way.

In the current state, the code is performing two separate reads on each channel and comparing those two readings to each other. If one reading is more than X different than the previous reading, then it is allowing it to move up or down only as much as X. And it is performing the reading Y times a second.

X and Y are the variables. In the current state of the variables, the response to stick input has slowed down significantly but I believe I will be able to fix that with playing with the values of X and Y.

This video is the first attempt to see the throttle response to the new code and the sensors. It was encouraging. You can see throttle adjust with input from top and bottom sensors.

https://www.youtube.com/watch?v=CPxF...c&spfreload=10

https://www.youtube.com/watch?v=CPxF4UFmEhc&amp;spfreload=10

Wow. You have done a very good job with the monobot. I am a passionate drone driver and a professional one. I own a Greek company: Aeromotion which i create with a friend so that our hobbies can be job. We create beautiful aerial videos and aerial photos about everything. I have read all your posts and i am expecting the next one. I would like to share a video of my job too.
https://www.youtube.com/watch?v=AH_YUX2osEE

Thanks man! Beautiful aerial video! Just Subscribed to your channel. I love Mediterranean:cool:. Keep in touch.

thank you for the subscription!!! I have subscribe too to yours!

Thanks bud! Planning to do a test flight tomorrow. Let's see if the setup will work in the air as good as it works on the ground...

I made all my preparations to maiden the MonoBot today. Did a short tethered indoors test to see it even hovers. It did, but wasn’t balanced right, so kinda hit the bed and had minor damages. Fixed it and went outside. The first test is the time that you will definitely know if your design is right or wrong. BECAUSE, I made a deal with the universe: When the design is not right, it lets me know by slamming my unit to the groundJ And that happened MANY times. So, the plan was:

1-Test the flight capabilities with the new electronics with IR NOT activated

2-Activate IR in the air and see how it responds

This is the part that hobbyists with IR sensor experience will laugh their butts off: The IR system didn’t respond the same way outside, the way it used to inside. Came in, checked the serial monitor, it works fine. Went outside again, the same problem repeated. Then I guessed that the sunlight is interfering and googled it: bingo. I felt really dumb, dealing with with IR sensors for months now, building them and not knowing this fact!

So, after finding about this, I still decided to test it without activating the IR sensors at all, to see if it flies. I was out at dusk and I realized that the sensors actually started working. But still didn’t activate them during the flight just in case. Below is the video of the first flight. I definitely felt the slow response time, resulting from the signal filtering code. However, considering that I am getting a PWM signal, passing it through Arduino, converting it to PPM and filtering it before feeding it to the flight controller, It was pretty good. However, I still couldn’t eliminate a rough landing due to not being used to these new control characteristics and damaged a servo and some body parts. Took me about 30 min to fix. The irony is that if I activated the IR sensors, considering that they started working at dusk, I would never have the rough landing as the unit would adjust the throttle.

Anyway, now will find a way to filter the sunlight so that the sensors work in daylight. Will probably do a second test tomorrow at dusk with the sensors on…

https://www.youtube.com/watch?v=sBPW...ature=youtu.be

https://www.youtube.com/watch?v=sBPWu2jBECU&amp;feature=youtu.be

I tried for a while to make the IR sensor immune to daylight but it was way over me technically. I tried to send and receive the light in a certain frequency but that didn’t work…

It felt more my way, to teach the Arduino about the outside world instead of limiting it to a signal anyway. During my tests I saw that daylight, especially direct sunlight have very strong IR radiation. So, I started working on a code that will recognize the environment and command the unit accordingly.

The code is recognizing the environment by calculating the average value from all 6 sensors and initiating 2 different algorithms accordingly. It also has a control against the effect from the direct sunlight. Otherwise, the unit would give a very strong response to direct sunlight.

I also improved the hardware by covering the back of the sensors and placing them in tubes to minimize environmental effects.

It works fine indoors. I will see how it reacts outdoors tomorrow. When it is ready I will do the first flight test with the IR sensors, hopefully outdoors.

http://www.rcuniverse.com/forum/atta...mentid=2197600http://www.rcuniverse.com/forum/atta...mentid=2197601http://www.rcuniverse.com/forum/atta...mentid=2197602

Focusing on the indestructible Nano recently, I haven’t been able to work on the MonoBot. Having the nanoC resolved, I had a chance to revisit the bot.

Since the maiden flight and realizing that the regular IR sensors are useless in daylight, I worked on a solution which I hope would solve this problem. This solution utilizes the sensors almost like motion sensors and they react to changes in the environment, whether this is an obstacle or a change in the light source, etc… But I never had the chance to test this until a couple of days ago.

This time the problem wasn’t the IR sensors, in fact I could only test them in one occasion during 18 minutes of trying. The servo jitter that I kinda solved with the filtering code and the delay that the code causes were the major problems. So, I tried to control the unit most of the time and didn’t feel comfortable to activate the IR sensors except one occasion and that short video is attached. At 24 second mark you will notice the unit ascend and bounce back with the help of the bottom sensor. However, probably, because of the noise in the signal and the delay caused by the code, the second bounce didn’t happen and the throttle was all over the place during that time.

After experience, I tried hardware solutions one more time, pull down/up resistors, capacitors, different feed voltages, feeding the Arduino board from a separate source, etc… One more time, nothing worked… I believe this is an Arduino nano problem and there are lots of blogs but no real solutions. And I am pretty sure if I used a UNO board I wouldn’t have this problem but that is too large for the unit.

So, I camped in front of the computer for 2 nights to sort this problem with a new code. After many unsuccessful tries I believe I came up with a better solution, which eliminates the jitter COMPLETELY and improves the response time significantly. The second half of the video shows the results. The shaking of the nozzles for a second right after I boot up the unit is because of resonance and has nothing to do with the signal quality. After that one second you will see that the nozzles are as still as rocks, which makes me very happy.

Will adjust the response rate of the sensors and test it again once the weather conditions allow me…

https://www.youtube.com/watch?v=HJ5w...ature=youtu.be

https://www.youtube.com/watch?v=HJ5w-hCxpx8&amp;feature=youtu.be

I had to go back and do everything all over… I couldn’t, for the life of me, achieve a stable flight with the previous setup. Every time I thought I solved the problems, something new came up. The last problem was that the X/Y/Z values have been slightly changing independently based on the values of the other axis. When I was adjusting the yaw, it was impacting roll. So, I could never get the unit to a stable flight where I can test the sensor. I believe the problem was that the PPM signal that I fed into the flight controller was causing the problem and the FC was getting confused, maybe because the signal from the Arduino uno wasn’t all that high quality… And with this flight controller, I couldn’t feed in PWM….

So, the decision was made and I replaced the flight controller with the one that I used on the indestructible Nano. Re-wrote the code to replace PPM with PWM, and fed that into the FC. I took off all sensors, to install new ones in the next stage, if the unit flies well.

It worked. At last I passed the signal through the Arduino and achieved a stable flight. There is a slight headwind during this flight so I need to manipulate the unit to beat that. I am really happy with the result. I still have the jitter avoidance code working at the background and causing a little delay but, it didn’t impact the flight, except the landing, where the throttle cutoff was slow and caused the unit to flip, which is nothing new:).

Now the signal is ready to be mixed with the IR sensor inputs. But this time I will be testing some obstacle avoidance sensors instead of my old home made distance sensors. The new sensors create a signal which is either 0 or 1 but the code is capable of softening this and adjusting the output based on the length of the signal. According to my tests, they are also immune to daylight, not 100% but maybe 90-95% (direct sunlight may cause issues). If the unit gets out of control I will disable the sensors with the 5th channel. First I will test only 1 or 2 sensors to see how the unit reacts.

https://www.youtube.com/watch?v=tSshTTb0cJI

https://www.youtube.com/watch?v=tSshTTb0cJI

AT LAST!!! The first time that I could really test the IR sensors during the flight. Currently have two sensors, one at the front and one at the back. I used my right hand as the obstacle to activate the sensors, whenever I felt comfortable enough to take my hand of the stick. The unit gently moved to opposite direction each time:) Really cool!

I will increase the impact of the sensors a little bit to make the unit react faster and will add 4 more sensors in all directions.

https://www.youtube.com/watch?v=CfyT2EHt3JM

https://www.youtube.com/watch?v=CfyT2EHt3JM

http://www.rcuniverse.com/forum/atta...mentid=2206621

I decided to go with the hard one again… Will use what I learned to try building a GPSless position hold system via a GY-521 sensor board + Arduino. This is a pretty cool little board which has accelerometers and gyros. Below data is from my serial monitor… Need to build a solid algorithm using the accelerometer data. Hmmm…

AcX = -2200 | AcY = -68 | AcZ = 17424 | Tmp = 31.82 | GyX = -501 | GyY = -38 | GyZ = 249
AcX = -2244 | AcY = -36 | AcZ = 17292 | Tmp = 31.97 | GyX = -444 | GyY = -22 | GyZ = 173
AcX = -2224 | AcY = -52 | AcZ = 17328 | Tmp = 31.87 | GyX = -450 | GyY = -64 | GyZ = 258
AcX = -2260 | AcY = -204 | AcZ = 17236 | Tmp = 31.92 | GyX = -432 | GyY = -59 | GyZ = 231
AcX = -2192 | AcY = -36 | AcZ = 17232 | Tmp = 31.92 | GyX = -436 | GyY = -51 | GyZ = 167
AcX = -2308 | AcY = -44 | AcZ = 17268 | Tmp = 32.01 | GyX = -513 | GyY = -15 | GyZ = 267
AcX = -2232 | AcY = -216 | AcZ = 17264 | Tmp = 31.97 | GyX = -472 | GyY = -2166 | GyZ = 252
AcX = -2108 | AcY = -2012 | AcZ = 15580 | Tmp = 31.82 | GyX = 96 | GyY = -935 | GyZ = 5553
AcX = -1040 | AcY = -2932 | AcZ = 18424 | Tmp = 31.87 | GyX = -2685 | GyY = 4202 | GyZ = 3258
AcX = -3316 | AcY = -284 | AcZ = 19688 | Tmp = 31.92 | GyX = 633 | GyY = -435 | GyZ = -1965

Implementation of what I learned with this project to my indestructible Mono.

https://www.youtube.com/watch?v=Mg87r9ec-X4

https://www.youtube.com/watch?v=Mg87r9ec-X4

The new indestructible MonoBot. No more replacing servos, fixing landing gears, etc…. This unit is extremely durable and light and will be the new base for my ongoing Arduino tests. Flies like a charm!


https://www.youtube.com/watch?v=JQ3f...ature=youtu.be

This is my new carbon fiber unit that I will use for testing and experimenting sensors and position hold systems, as a part of my ongoing arduino project. This is the maiden of this unit. After seeing that it flies in the first couple of seconds, I felt comfortable enough to immediately test the GPS. I tweaked the code earlier to make the GPS to refresh the position hold position as the point where the stick is released. In the old version, when the stick was released, the GPS would take the unit where the GPS hold was originally initiated. However, with the change, I could successfully re-assign the new position hold coordinates as the point where the stick is released. This will be very useful in many projects. I call it the crawl mode. thx

This will be my IR radar if I can successfully read the IR sensor at certain angles. I will be able to read theoretically infinite (in reality 8) angles with only 2 sensors. These are very good sensors with over 1 meter range and they are immune to daylight. https://www.youtube.com/watch?v=uEnV...ature=youtu.be

A very ambitious project for an Arduino nano and me for sure… The code turned out to be quite hard to pull out for a rookie like myself. I am having to run the cycle size at 300, which means that the board loops 300 times at every full turn of the IR scanner. This is slowing things down a little bit, because I am limited with the speed of the servo. When, at last, I got the scanner to work, it took me a while to get the correct readings from the IR sensors at the correct angles. In the end I got it to work at a reasonable functionality level… The good side if I can install a super fast servo, I can speed things up significantly and make the unit more responsive (if I can find one). Another hurdle is that I need to modify the servo to cover a 315 degree range, so I can get away with using only one IR sensor on the scanner instead of the two that I currently have. In the video, you will see the nozzles react differently when I activate the sensors at different angles, showing that the scanner is working fine. The goal is to make the unit completely autonomous indoors. Takeoff, navigation and the landing will be handled automatically. After the first flight tests, if successful, I will install a GPS for outdoors tests.

Trying to maiden the unit to test the sensors… Crap load of unforeseen problems. The pitch compensation being reverse for some weird reason caused the first crash… Then the ESC failed. At last I was able to test the throttle sensors. They worked good. Except the reaction was a little slow for one of the fast descends and the unit hit the ground before I could activate the IR scanner. Only lost the impeller and the ESC cable snapped. Easy fixes. I edited the crash out of the footage. The sensors work very well when you approach at a reasonable speed as seen in the video but are slow to respond when the descend speed is a little high.Possible solutions: 1: sensor with a longer range which will react earlier. The problem with this solution is that the as range of the sensor extends, so does the blind zone for close by obstacles. I may consider a sonar instead of an IR sensor for throttle. 2: Implement a precision barometric sensor to regulate the approach speed. 3: Somehow find a solution in the code to speed up the response. The code solution is a tough one considering the scanner is limited to the speed of the servo.

Looks similar but completely different and better setup.
1- Modified the servo to be continuous rotation. I also did the necessary modification to be able to read the shaft position via potentiometer. I have a 180 degree sweep instead of the previous 120 degrees.2- Revised the code to accommodate the new servo. In the new setup, I don’t need to write the servo value 300 times every cycle to drive the servo. All I am doing is reading the shaft position and reversing the direction whenever the shaft hits 800 value on the top and 200 on the bottom. I am reading the sensors at certain positions based on the potentiometer readings.3- Added GPS.These changes made the unit way more responsive as the code is not jammed like before. With the new GPS, I will not have to intervene all the time. In the first flights, I will activate the GPS right after takeoff and test the sensors. I will look into getting a sonar for the altitude hold. The only problem is that I am using all digital ports in the current setup. So, I will need to find an analog sonar if it exists.I also ordered a barometric sensor to modulate the approach speed and enable altitude hold for higher altitudes.Hoping the test the current setup in flight soon.

I never thought building an altitude hold system with a sonar would be this hard… I wanted to build the “simple” sonar altitude hold to be able to test the “hard” IR scanner better. I ended up crashing the unit 10 times and found out that I need a much better setup to achieve this.

Problems:
1- High speed air out of the nozzle is impacting the sonar performance.
2- I believe the grass as a sound reflector is not doing a good job because the sonar is utterly inconsistent in reaction. AND this is a relatively expensive sonar at $30.
3- The codes I came up with are not even close to do the job. The code has to incorporate approach speed and a fully automated throttle control. I will re-visit this in the future, and maybe implement a high precision BARO instead of the sonar for higher altitude hold and try another type of sensor for landing, because of sonar’s poor performance, probably due to nozzle air.

So, I decided to go ahead and test the IR scanner before totaling the unit. My concerns regarding the scanner making the unit unstable were proven wrong. It worked perfectly:) You can see it spin at the top of the unit for the first time, doing a great job. The unit clearly reacted to my hand and body and rushed the other direction when approached. The plan was to test it during GPS hold but the GPS hold was not stable. I probably damaged it during the last crash which was nasty. So I deactivated the GPS during this test.

https://www.youtube.com/watch?v=9VhlexQbljQ

New project for the MonoBot test unit. I took off all sensors, sonars, etc… to pursue this idea that I had for a long time, to see if I can create an independent indoors/outdoors position hold and cruise control system which doesn't have any external dependencies like satellites, vision, etc… I want the system to capture the tiny acceleration changes and correct the unit.



I am using a single 3 axis accelerometer to sense the directional accelerations. The MAJOR problem is that the sensor senses the change in the angle and the change in the direction exactly the same way and create the same signal. I thought for days and days until my brain burned to figure how I can distinguish between the two and filter out the angle changes. I need the sensor to correct for the directional input but not the angle of the unit.



It took me weeks to put the code together and put everything on the unit. The first tests were not good. Most of the time the unit chose a direction and just kept going. Sometimes I had something close to a position hold in like 10m diameter but then again it just chose a direction and go. Once the impeller imploded and I crashed the unit, had to replace all servos and some other parts. The variables that I need to tune are below:



- The dead zone band range to filter out the noise.

- Two moving averages.

- The rate of impact of the signal to the servos.

- The max allowed impact allowed, to impact the flight in X and Y axis.



I continuously played with these variables and tested but the flight tests proved to give very inconsistent results. Then I realized that the impeller vibration would be impacting the sensor to generate some weird signals. I placed the sensor on a vibration damper, balanced the new impeller and tested again. The unit responded much better. In the video there was a part of the flight where it really looked like holding the position just like a GPS. However, then the wind picked up and the unit drifted away. The position hold system is only allowed to use 1/3 of the stick range, and the wind was much stronger than this could handle. I will test again in a calmer weather and try to tune the variables.

Here is the latest status:



I tested the unit again after installing the vibration dampener. The test didn’t go well. Again, the unit chose a different direction every time I initiated the system and took off. I adjusted the dead band zone during the flight but no luck.



So, I decided that I need to change the position of the accelerometer and place it closer to the center of gravity, to reduce the physical sideways impact of the tilting and tested again. The unit reacted better but it didn’t really hold position. It kind of drifted away. But this made me feel like I am getting closer to the solution.



Here is one of the things with this concept. Because of the way the accelerometers work, when I activate the system, it should basically keep the current speed. So, if it is still when the system is activated, then it should stay still. But if it is in motion at 1m/s for example it should hold that. And you cannot change that with the stick input because it conflicts with the sensor input and the unit gets out of control (I tried this). So, I decided to change the stick input logic when the system is activated. Now, if the unit is moving backwards when the system is activated, when I push the stick forward, it inputs a constant in the output equation to slow the unit down and finally stop it, instead of fighting the equation.



Also, I spent 5 hours to test every variable one by one at home, hand simulating the flight back and forth. I found the combination which I think works the best in the serial monitor, looking at the system output. When doing this, you need to test all combinations, including the ones that doesn’t make sense at all. Many times, you will find that the one doesn’t make sense is the working combination. Which actually was the case in this one. I found a combination which works ten times better than the other combinations that I tested (which I still think make lots of sense).



I took the unit out just before sun down and tested. I think the unit response is way better in terms of “trying to hold the position”. I initiated the system twice, once right in the beginning of the video and once right after the half of the video. The unit reacted erratically because the compensation which seemed normal before is way high with the new setup. Now I assigned the 5th channel to the sensor compensation and will test again to find the right compensation rate with the new setting. You never know but I feel like I am getting close.

A much better test at last. The 5th channel is assigned to the compensation, which is the level of impact from the sensor to the nozzles.



No wind this afternoon. So, the purpose of the test is to see the reaction of the unit at lower compensation level and increase the compensation to the level where the unit over compensates. This way I want to set a reasonable compensation range and keep the unit in that.



I activated the system multiple times during the flight. It responded much better and I felt like it really contributed to the stability this time until I increased the compensation to unreasonable levels. The unit tended to keep the velocity that it was travelling at when the system was activated. I made some corrections while the system was active, to slow down the velocity closer to zero. As I explained in the previous post, when the system is initiated, the sticks are acting different than normal, throwing in a constant value to the servo output calculation, to fool the unit to slow down.



I think I am getting there but need to test it when there is some wind and see how it reacts.

I definitly like your project

Thank you sir!