Radio control by location

Hi,
I play with Tricopters, which are a 3x propellor helicopters. I've enjoyed making them and learning to fly, but I don't find it easy, with eyes not like they used to be, I sometimes find I can't see which way round they are. If there's a risk of them flying away, I crash and repair them, which happens quite a lot, when they are high or a distance away.

[I've seen the latest flying machines like the Mavic etc, which I find amazing]

I thought I would try experimenting with sending height and location, instead of the usual RC transmitter method, which would allow me to fly in a more controlled way, and HOLD if nothing was sent.

I hope to build ideas on how to do this here.

Camerart.

In the US, we are rapidly moving to 2 distinct categories of "drone," including fixed wing versions:

1) Those flown by hobbyists for pleasure within visual range and control at ALL times; and
2) Everything else, including commercial, military, and civilian (e.g., search and rescue) and maybe anything with FPV.

It is a hot topic and regulations are evolving rapidly. Incidents, such as this drone hitting a military helicopter are driving that change: The outcome could have been much worse.

Hobbyists like myself see no need to fly out of visual range, and consider FPV is just a gimmick that wears off or can be done without. RC models have been a part of my life for over 65 years. As a group, hobbyists like myself are very concerned that current regulatory exclusions will be eroded and even eliminated by reckless behavior of "lone wolves."

The "everything else" will have increasingly stringent controls and costs. For example, annual licenses, inspections, mandatory flight plans, positive control, and pilot proficiency requirements are likely to happen or have already happened. Many individuals in government would be happy to see the hobbyist exemption disappear and incidents such as above don't help.

The FAA has recently reinstated its requirement that every pilot must register and have that registration information in the drone. Fools, like the individual who hit the helicopter don't do that -- just like some fools drive without a valid driver's license. Unfortunately, drone hobbyists are a very small group compared to non-commercial drivers in the US. While it is unimaginable that the government would require all automobile drivers to follow commercial requirements. The same can't be said for drone flyers. Monetary fines won't help eliminate the trouble makers. The chance of being caught is slim, and when caught, the violator will plead poverty. Thus, there will probably be criminal penalties, but the most effective and probable outcome will be elimination of the hobbyist exemption. Unfortunately, the American Bill of Rights does not include flying drones.

My advice: Don't fly out of visual range. Don't jeopardize a very rewarding past-time for others. Play with the electronics all you want, but always fly with a safety pilot when you might be distracted by some gadget on board the aircraft.

jpanhalt said:

In the US, we are rapidly moving to 2 distinct categories of "drone," including fixed wing versions:

1) Those flown by hobbyists for pleasure within visual range and control at ALL times; and
2) Everything else, including commercial, military, and civilian (e.g., search and rescue) and maybe anything with FPV.

My advice: Don't fly out of visual range. Don't jeopardize a very rewarding past-time for others. Play with the electronics all you want, but always fly with a safety pilot when you might be distracted by some gadget on board the aircraft.

Click to expand...

Hi J2,
I quite understand your concerns, and I have the same ones.
I don't intend to fly out of the legal UK rules, i,e, out of sight.
My problem is, that unlike you I have only recently taken up RC flying, and while I can see a long way, I can't always tell which way round my Tricopter is, so I purposely crash it.
The idea here is not to do anything different to normal RC, but to control the model in a different way.
C.

Sounds like you want a 'return-to-base' function which can be invoked by you or automatically. Some hobby drones already have this.

Off hand, I can imagine a GPS or solid state compass doing what you want. The GPS might be more complicated and less sensitive for the yaw (vertical) axis. Most compasses come with accelerometers in the same plastic IC, In most cases, you can ignore what you done't want. I have experience with the BMC156, MPU9250, and AK8963. The MPU9250 actually incorporates the AK8963 as I recall. It is the most complicated to deal with as it requires both SPI and I2C for the compass.

My personal favorite was the AK8963. It was easy (SPI), sensitive (more than the BMC), and gave fast response. Response time is under user control as you control the number of readings being averaged. My code is Assembly and for an enhanced mid-range PIC (probably the 16F1829). I found its datasheet easier to understand than the BMC's too.

I have attached a zipped file of the MP4. Not sure I can upload MP4 here. Hope it works.

John (aka JP or J1 )

EDIT: I had forgotten that I wrote a short review of those 3 chips:

The InvenSense MPU-9250 device is actually two dies in a single package. One chip provides 6-axis inertial data; the other is an AK8963C, 3-axis magnetometer. The SPI interface with the MPU-9250 is a little more complex than for the other devices, as register numbers for the two included chips overlap. One must enter a pass-through mode to get to the AK8963, which is then operated as an I2C accessory device. As best I can tell, it only allows 14-bit operation of the AK8963. Since I was only interested in the magnetometer function at this point, I did not play with the InvenSense chip further.
The Bosch BMC156 also includes 6-axis inertial data and 3-axis magnetometer data plus a Hall resistance value that can be used for temperature correction. X and Y axis's are limited to 13-bit data and have a stated maximum sensitivity of 0.3 uT/LSB . One nice aspect of the chip is the ability to do multiple readings from 1 to 511 with automatic averaging. I settled on 47 reads for each axis. One can also adjust output data rate from 0 Hz to 30 Hz. A rate of 20 Hz is common and worked well. Compared to the AK8963C, the data from the BMC156 seemed less stable. That stability did not improve noticeably by going to 511 reads. The chip tends to go to a power-down mode. With every read cycle, one must wake it up. That is not a problem once you are aware of the need. Overall, it is an easy to use chip, particularly if you need both inertial and magnetic data.
I ended up selecting the AK8963C for my current project. The interface is just as easy as for the BMC156. It offers two sensitivities: 16-bit (0.15 uT/LSB) and 14-bit (0.6 uT/LSB). One can put it in a permanently on mode. It only offers two read frequencies: 8 Hz and 100 Hz. I used 100 Hz and averaged 16 readings at 16-bit resolution. The difference between 8 and 16 readings was imperceptible. I wish I had a standard magnetic source with which to calibrate it, but the observed values seem reasonable based on my location ( https://geomag.usgs.gov/plots/ location key: https://geomag.usgs.gov/monitoring/observatories/ ).

Click to expand...

alec_t said:

Sounds like you want a 'return-to-base' function which can be invoked by you or automatically. Some hobby drones already have this.

Click to expand...

Hi A,
As mentioned I've seen what Mavic style drones are capable of, and I have such stuff which will return to home.

I am talking about controlling the model by location, where the transmitter would send e,g, instead of THROTTLE being sent with PWM, then an ALT would be sent and the model would go to and stay at that height till it was changed.
C

jpanhalt said:

Off hand, I can imagine a GPS or solid state compass doing what you want. The GPS might be more complicated and less sensitive for the yaw (vertical) axis. Most compasses come with accelerometers in the same plastic IC, In most cases, you can ignore what you done't want. I have experience with the BMC156, MPU9250, and AK8963. The MPU9250 actually incorporates the AK8963 as I recall. It is the most complicated to deal with as it requires both SPI and I2C for the compass.

My personal favorite was the AK8963. It was easy (SPI), sensitive (more than the BMC), and gave fast response. Response time is under user control as you control the number of readings being averaged. My code is Assembly and for an enhanced mid-range PIC (probably the 16F1829). I found its datasheet easier to understand than the BMC's too.

I have attached a zipped file of the MP4. Not sure I can upload MP4 here. Hope it works.

John (aka JP or J1 )

Click to expand...

Hi JP,
I have just ordered some GY-282 HMC5983 compass modules, and will hopefully get them going back on the other thread first.
On my models I use KK2 boards for control.
I'll come back to this message later and look closer, thanks.
C

Musicmanager said:

Hi Cam

I've been toying with the idea of buying a drone for a while, greatly spurred on by the various 'offers' that appeared during the Xmas frenzy. Many of them seem to have a 'Do nothing and stay where you are' control and also a return to controller .. but, to my mind, lots of tech means lots to go wrong. I never did buy anything.

This may be loopy but I recognise the eyesight problem only too well. If you were flying a full size aircraft you would have a red, green and white navigation light system to indicate to others your direction of travel from a distance.

Would that be a relatively easy solution ?

S

Click to expand...

Hi M,
There are many models to choose from. I've seen a Mavic in action and if you are ok to spend hundreds of £sss, I would buy one, they're fantastic.

I have a 'T' of LEDs White at the front, red on the left and blue on the right. As sometimes it is necessary to make a muscle memory fast decision, I found I couldn't, so for the sake of safety etc, I choose to crash, which obviously isn't the best.

With conventional PWM RC if the model has been 'told' to go forward away from me, and I can't see it properly, the situation can soon turn awkward, so I'm trying a different method, to suit me.
C.

Hi,
I received a comment regarding the accuracy of an air pressure controlled model.

I tried a test using a PCB with 18lf4520 PIC and a BMP280 barometer module. I moved up and down to try to keep the READings from the output screen the same, and I had to lift and lower approx 2ft, which gives a first impression of accuracy.

This was indoors, so I wonder what will happen when in windy etc conditions.

For my purposes this accuracy is ok, but I would like it better. Perhaps as it develops, the accuracy can be tightened up a bit.
C.

hi C.
Perhaps I am missing a point.
If the Base station that you are holding has say a GPS NEO module, that will have the Base Altitude value.??
Also why are you sending the Base Alt to a Remote point/station.?

E
NOTE:
If you are doing the Trig maths in the PIC, using the GPS data as Degrees, remember that the String value has Degs and Minutes.
So before converting to a final Single value the Minutes needs to be divided by 60.
This is the way I do it for display on a 5110 LCD

Define SINGLE_DECIMAL_PLACES = 6

Dim strdec As String' String for minutes Decimal value
Dim sinlat As Single
Dim sinlong As Single
Dim sinalt As Single
Dim sindec As Single' Single for Minutes Decimal value

''font1 add this
Case "\"
SPISend 0x06
SPISend 0x09
SPISend 0x09
SPISend 0x06
SPISend 0x00

call get_val

msg1 = "T=" + strtim
Call wr_msg(0, 0, msg1)

msg1 = "N=" + #sinlat + "\" ' using fwd slash as Degree symbol, add it to the Font1 table
Call wr_msg(0, 1, msg1)

msg1 = "W=" + #sinlong + "\"
Call wr_msg(0, 2, msg1)

msg1 = "A=" + #sinalt + "M"
Call wr_msg(0, 3, msg1)

Hserout " T=", strtim, " N=", #sinlat, " W=", #sinlong, " A=", #sinalt, CrLf

...............
get_val:
Select Case csv
Case 1
Case 2
strtim = LeftStr(msg1, 2) + ":" + MidStr(msg1, 3, 2) + ":" + MidStr(msg1, 5, 2) ' Time msg
Case 3
strlat = LeftStr(msg1, 2)
sinlat = StrValS(strlat)
strdec = MidStr(msg1, 3, 6)
sindec = StrValS(strdec) / 60
sinlat = sinlat + sindec
Case 5
strlong = LeftStr(msg1, 3)
sinlong = StrValS(strlong)
strdec = MidStr(msg1, 4, 7)
sindec = StrValS(strdec) / 60
sinlong = sinlong + sindec
Case 12
stralt = msg1
sinalt = StrValS(stralt)

Case Else
EndSelect
msg1 = ""
Return

Hi E,
Regarding the BASE ALT to DRONE question.
I haven't thought it through, but it will be something like:
The BASE and DRN ALT is set to GND, allowing for the GND PRESS to go '-' negative (Below GND) i,e, always a positive NBR.
The BASE transmitter would send an ALT NUMBER 'say' 1Mtr above GND and the DRN would fly 1MTR above GND, until the PRESS changed. The difference at BASE would be added/subtracted from the NBR and re-sent keeping the DRN 1MTR above GND.
NOTE: The DRN NMB would then be converted to PWM to feed to the control panel. I haven't thought this through)

I'm not sure how GPS works out the direction, as I assume it needs to be moving. If there is a way of giving DIR while stationary, let me know.
I have ordered some HMC5983 compass modules for DIR, which may be easier.
Thanks for the calculation.
C.

Hi,
Later I'll be trying to send LOCation DATA from one PIC to a second PIC. I will need to decode the DATA and convert it into most likely PWM or possibly PPM.

Are there any experts out there to give tips please?
C.

camerart said:

Hi,
Later I'll be trying to send LOCation DATA from one PIC to a second PIC. I will need to decode the DATA and convert it into most likely PWM or possibly PPM.

Are there any experts out there to give tips please?
C.

Click to expand...

Exactly what are you trying to do?, if it's transferring data between two PIC's those look to be about the most unsuitable ideas you could find?.

Nigel Goodwin said:

Exactly what are you trying to do?, if it's transferring data between two PIC's those look to be about the most unsuitable ideas you could find?.

Click to expand...

Hi N,
It sounds like I haven't explained well enough.

One component of the LOCation, ALT see #12, would be sent as DATA, between two DATA radios. The RX/PIC would then convert the ALT DATA into PWM to lift the model to the sent ALT.

C.

OK, so you didn't explain it very well - one PIC sends data over a radio link, the other receives the data and controls a motor (or motors).

Nigel Goodwin said:

OK, so you didn't explain it very well - one PIC sends data over a radio link, the other receives the data and controls a motor (or motors).

Click to expand...

Hi N,
That's clearer.
C

Hi,
I've got some HC12 radio modules for TX/RX

I've decided to use PWM, and I'm now looking into PIC timer control.
I have some TMR0 and TMR1 example programs, but they are complicated, and I seem to recall that Oshonsoft has difficulties with it.

Here is an image showing the PWM 20ms cycle with the 'up to 10 channel' 2ms examples. Will this work with one TIMER or does it need a TMR for the 2Ms plus a TMR for the 20Ms.

[I modified a PPM image to make the attached PWM image, will someone double check that it is correct please?]

C.

Hi,
I've just found some of my notes showing this PIC, which looks interesting for this project, also a couple of links of interest.
Using the 18LF4431, it appears that there are 8 PWM pins, but from the links, I read it may not be so. Farther reading needed.
C.
https://www.picbasic.co.uk/forum/showthread.php?p=43820#post43820
https://www.picbasic.co.uk/forum/showthread.php?t=11081
https://ww1.microchip.com/downloads/en/DeviceDoc/39616d.pdf

Hi,
I've found some 18F2431 PICs, that I can use before moving to the 18LF4431.
I've been setting up the 18F2431 PICs and working through the D/S. These are for the RX DATA to PWM program.
Does anyone have tips for their process of setting up PICs please?
Here's where I've got so far:
NOTE: POWER CONTROL PWM MODULE in D/S
C.