UN.RCONT.OL

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

UN.RCONT.OL

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

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

UN.RCONT.OL

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.

UN.RCONT.OL

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.

UN.RCONT.OL

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…

UN.RCONT.OL

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

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

UN.RCONT.OL

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

UN.RCONT.OL

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&feature=youtu.be

UN.RCONT.OL

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&feature=youtu.be

UN.RCONT.OL

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...

UN.RCONT.OL

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

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

UN.RCONT.OL

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!

UN.RCONT.OL

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

UN.RCONT.OL

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

UN.RCONT.OL

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…

UN.RCONT.OL

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

UN.RCONT.OL

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&spfreload=10

Aeromotion

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

UN.RCONT.OL

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

Aeromotion

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

UN.RCONT.OL

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...

UN.RCONT.OL

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&feature=youtu.be

UN.RCONT.OL

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.

UN.RCONT.OL

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&feature=youtu.be

UN.RCONT.OL

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