UN.RCONT.OL

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

UN.RCONT.OL

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

UN.RCONT.OL

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

UN.RCONT.OL

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

UN.RCONT.OL

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

UN.RCONT.OL

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

UN.RCONT.OL

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.

UN.RCONT.OL

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.

UN.RCONT.OL

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.

UN.RCONT.OL

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

UN.RCONT.OL

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.

UN.RCONT.OL

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.

UN.RCONT.OL

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.

SALMONBUG

My Feedback: (1)

I definitly like your project

UN.RCONT.OL

Thank you sir!

UN.RCONT.OL

These flights are to test the arduino mixing for Ardupilot and see if it can handle the job. After a couple of tries and crashes it turned out pretty cool.

UN.RCONT.OL

Re-testing the Ardupilot Arduino hybrid, position hold and RTL on my monobot test unit. Better test, a little drift at the start but as it acquired more satellites all was good.