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

+ YouTube Video

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

+ YouTube Video

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.

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:)

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

+ YouTube Video

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

+ YouTube Video

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

+ YouTube Video

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

+ YouTube Video

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=kscT...ature=youtu.be

+ YouTube Video

Takeoff videos:

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

+ YouTube Video

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

+ YouTube Video

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…