Copter-3.6.0-rc7 released for beta testing!

ArduCopter Copter 3.6
,
42

Further to the discussion on the use of compass with F405 boards on small frames, I added a compass to see if I could get my race quad to switch to a gps enabled mode (like loiter). I am pleased to say that adding the compass has worked well. I have since been able to do a position hold autotune and have managed to get the quad flying well. In fact, flying with acro handling characteristics very similar to how it did on betaflight (which I am very pleased about!). I will say that I have done this on a dev build (9th Aug) as the beta wont allow me to arm (bad logging).

The only trouble is that I didn’t want to have to run a compass on my race quad. Given the really limited real estate, I cant fit a compass and gps unit nicely into my quad (it’s just glued on top at the moment and does’t look very good). Additionally after running a compass-motor tune I get a max interference of 170%. The compensation does seem to have worked well as I haven’t had any EKF or AHRS errors yet. So I agree with @iampete that it would be great if we resolved the issue of being able to use gps mode without compass. I think that it is simply an issue of the way the EKF failsafe checks for a compass that needs adapting (i am certainly not sure though). If anybody has any advice I would be happy to try fixing it.

43

Hi,
Just wanted to report, had great flights this morning:

Frame: Iron Man F650 X
Motors: Tarot 4114 320kv
FC: Holybro Pixhawk 4 (FMU_v5)
FW: Copter-3.6.0-rc7
Batt: 6s 16000mah
RX: X8R
AUW: 3250g

Checked the following modes:
Stabilized, AltHold, PosHold, Loiter, RTL and AutoTune.
With out of the box PID defaults flights were really stable.

Only thing though and I’m not sure if its my error or not, when AutoTune was done (it took about 11 minutes) I flipped the RTL and the copter landed and disarmed. I went to my laptop and refreshed the params, however nothing has changed, parameters were not saved.

What am I missing ? did the disarming of the RTL failed to save the AutoTune parameters?

I’m not that good at reading logs but I think I went by the book. Any insight would be very welcome.
Auto tune log

Best Gal

44

At the end of autotune, you have to land, still in autotune (completed) mode.

The wiki you will follow in order to achieve your quest,

Marc

45

Hello Randy,
now I have also ChibiOS on CUAV Pixhack V3.

  • CH12 Opt for relay working
  • internal compass one not detected
  • IMU fast sampling not possible (also on 3.5.5) on Cube IMU 1 and 3 are fast sampling
    can not trigger compass calibration with stick full throttle rudder right with Oneshot enable, esc on AUX - sorry - did another test and now compass calibration works
  • Poshold, RTH, Simple, Supersimple tested and working super as the new Loiter
  • MaxT around 3000
  • did some Autotune but get ATC_ANG_*** values at 18 for the Quad 700 with 700KV Motors (Oneshot125)
    about 20 flights with no issues - great work - thanks :+1:
    3.6.0-RC7_02_manuell-PID.param (14.4 KB)
46

I would also like to know if ESC telemetry is available on the F4 Nano V6. If so I’ll buy the more expensive 4 in 1 for the 130 quad build I’m working on.

Edit: Wait a minute. As there is no logging available on this board what use would ESC telemetry be? OK, I see the telemetry data is selectable in Mission Planner on the Tuning screen.

47

Hi Marc,
So even though AutoTune was engaged, by turning RTL, I was out of AT?

Thanks,
Gal

48

You can still record its values through the telemetry link to MP. And I’m guessing it would be good for compass mot, on a small quad like these.

I’ve already ordered the board, so I’ll let you know how it works out.

49

IMHO when RTL is engaged, AutoTune is disabled.

Marc

50

Thank you Marc for your input, much appreciated
Gal

51

I ordered one also but the Hardware Definition file for this board makes no mention of a UART4. Maybe I’m missing something? It also notes pullup required on I2C but the connection diagram doesn’t indicate that.

52

I noticed that too, but I’m not a programmer and unsure where to go from here.

I was hoping someone would reach out to hwurzburg over on the chat to ask him about it… He was working on the board about a month ago.
I also saw a post by him about the pullups… He was asking to see if it was maybe possible to slow down the i2c bus, so they wouldn’t be necessary, but I don’t think he ever went down that path… Not sure…

(And sorry Dev guys, I swear I’m not a stalker! I’m just trying to keep up on the development of these new small boards)

53

@rmackay9

I followed the steps of the wiki and smoothly brushed the Ardupilot ChibiOS 3.6rc7 version of Heli firmware into the FC of OmnnibusF4 Pro V3. In the MP, follow the familiar steps to debug an antique-class traditional aileron helicopter. The previous steps went smoothly. It includes its own interface definition, Bec power supply, servo connection, receiver connection, accelerometer calibration, transmitter calibration, etc., including custom pwm6 for esc control interface. The ground unlocking and esc output control tests, as well as the servo motion test, looked very smooth and should be able to test flight quickly.

Then, I connected a GPS module with an external compass on Uart6 and prepared to calibrate the external compass according to the previous multiple use. However, on the progress page of the compass calibration, I found that there is no calibration compass on any attempt. Progress bar. No matter whether it is a compass 1, 2 or 3, it does not.

Enter the parameter list, you can see that the ID of the automatically recognized Compass 1 is 466433, but why can’t it be calibrated?

54

Dave,
As I said, I’m not a programmer, but have been looking at the various hardware definitions…

Would it be as simple as changing one line and adding one line?

Change this:

order of UARTs

UART_ORDER OTG1 USART6 USART1

to this:

order of UARTs

UART_ORDER OTG1 USART6 USART1 UART4

and add something like this (According to the manual PA1 is the MCU pin for rx4):

UART4 (ESC sensor)

PA1 UART4_RX UART4

There are other things wrong w/ the definition for the nano board, as it doesn’t actually have analog current input, or analog RSSI input, which are defined in the hwdef

-My other major concern w/ this board is I want to use it w/ 2s, and 1/2 the vendors have it listed as 2s, and 1/2 as 3s input. Airbot’s manual says 3s, but their website says 2s. (Why would they design a nano board that can’t run on 2s?!?) I’m guessing the 8v camera regulator won’t work on 2s, but the 5v regulator will hopefully run down to about 6v or less, as modern regulators usually have a very low drop out voltage.

55

I’m not a programmer either so hopefully someone that is can answer. We may have to check over on the Gitter channel when we get these boards flashed and running. I would like to use that UART for either ESC telemetry or Frsky passthough. My plan is to use a ESP8266 for general telemetry (I use them on PicRacers) and it doesn’t have enough ports for all 3 of those options.

The board I bought says 2S-6S, but that’s a good point about the 8V output on 2S.I’ll be using 4S.

56

Best way to make correct hwdef file is to get original schematics of the board from manufacturer and double check each pin assigment. I suspect the only one more or less properly done was matek f405 wing and a lot of other hwdef files had copies of its content.
So one needs to check with schematics what pins factually exist, how they mapped and how they wired.
Like, u can use regular pwm pin for ALARM out but it will not be loud enough if used agains ground - u want a buzzer inverted pin to use with 5v for sound, but that buzzer pin has to be mappable agains some timer for that to work - if you look into my fork of arducopter, i have a hwdef file for kakute f7 AIO in it with a lot of commented out combinations - it should give an idea of how to do it. Some stuff works, some doesn’t.

Ps. If u can’t find original schematics - next best source is the github for betaflight - fork it and search in it for your board name. They have in there more or less correct pin lists, but, as i saw for kakute f7 - not very complete nor exactly accurate.

57

Successfully flashed the bootloader then the 3.7-dev version from the current “Latest”. I’ll start with that and work forward.

58

Paul, thanks for the reply. I do have the manual for the omnibus nano, which lists the pin assignments. (I can verify them w/ a multimeter)

One thing I don’t understand is the order of uarts. You mentioned in your hwdef that they aren’t sequential in order to match the silkscreen on the pcb. But, if uarts are later in the hwdef defined by the pins they are attached to, what does the order of uarts line do? (If uart 4 rx is pin PA1, wouldn’t it always be that way?)
This might not be the place for this conversation, and my question might not even be apm specific (like I said, i’m new to this(I have a history of EE, but it’s all pre-microprocessor… I designed things like tube amplifiers and analog synthesizers)). But if you can point me in the correct direction (if documentation exists) let me know. My google and ardupilot searches didn’t tell me much.

I’m going to start getting everything installed so I can try modifying the hwdef and compile arducopter. My OS is opensuse. I should know enough to translate the few difference from ubuntu to opensuse, in getting everything installed.

59

Great! I’m still waiting on my board… Ordered from rtfq, and just looked up their faq, and it says orders can take over a week before they ship! It’s been over a week, and no shipment yet. I can’t wait to start playing.

60

so, depending upon the board you have you need to look up the possible list of assignments per each pin in the corresponding mapping document.
the original document for F745 is here:


and mapping you need starts on page 76.

now, all this info was converted into the arducopter source files - the file that controls possible assigments of pins to functions is here:
/git/ardupilot/libraries/AP_HAL_ChibiOS/hwdef/scripts/STM32F745xx.py - i found some errors there but i think most were fixed. now, like, if you look for the pin PA1 - you go into that file and you will see this:
“PA1:ETH_MII_RX_CLK” : 11,
“PA1:ETH_RMII_REF_CLK” : 11,
“PA1:EVENTOUT” : 15,
“PA1:LCD_R2” : 14,
“PA1:QUADSPI_BK1_IO3” : 9,
“PA1:SAI2_MCK_B” : 10,
“PA1:TIM2_CH2” : 1,
“PA1:TIM5_CH2” : 2,
“PA1:UART4_RX” : 8,
“PA1:USART2_RTS” : 7,

that should give you an idea that you have here option to use this pin for RX on the UART4, or you can use it for RCIN using either TIM2_CH2 or TIM5_CH2. Or it may be set as the usart2_rts, but, here you need to look at the boards schematics file to see if this pin is actually set for input or output only cascade.

STM32 F4 and F7 pins models are not the same, naturally, you`ll need to look at the document for an appropriate module.

going back to your PA1-
PA1 UART4_RX UART4 NODMA
works.

PA1 TIM5_CH2 TIM5 RCININT PULLDOWN LOW

will work in the case if TIM5 - timer 5 - is not used for any of outputs assigned to PWMs - like you can see in my case

Motors

PB0 TIM3_CH3 TIM3 PWM(4) GPIO(53)
PB1 TIM1_CH3N TIM1 PWM(1) GPIO(50)
PE9 TIM1_CH1 TIM1 PWM(2) GPIO(51)
PE11 TIM1_CH2 TIM1 PWM(3) GPIO(52)
PC9 TIM3_CH4 TIM3 PWM(5) GPIO(54)
#PD12 TIM4_CH1 TIM4 PWM(6) GPIO(55)
PA3 TIM5_CH4 TIM5 PWM(6) GPIO(55)

it is not going to work as PA3 is used for PWM 6 and used TIM5. If PA3 in the sheet would have an alternative timer - it could be moved around to avoid conflict. in case if you use temiers like ‘TIM1_CH3N’ - make sure file in the end has a pragma:
define STM32_PWM_USE_ADVANCED TRUE

other than that it is not excessively complex. only challenging part is to find what was actually done by the board`s maker and what pins are factually used. a lot of boards come with conflicts by default that prevent some functions to work properly.

PS. hwdef file with those experiments is here:

61

order of uarts i did not bother to fully understand myself.

i presumed that if it is set as:
UART_ORDER OTG1 USART3 USART1 USART2 UART4 UART7 USART6

then OTG1 becomes USB, and USART3 should be SERIAL 1 in mission planner according to this logic - but it is not so on last test kakute i play with now, as USART1 is serial 1 and it goes fine for 1 - 1, 2 - 2, 3 - 3, 4 - 4, BUT! UART7 is the Serial 5. and USART6 is serial 6.

frankly i did not care to look into code much to figure out why it is so, it takes not long enough to see what gets mapped where.

as of compilation bench i went into a path of a least resistance and got it installed on vmware from a vanilla image from ubuntu site - i am actually on ubuntu 18.04 ‘bionic beaver’ that somebody was saying is not making working binaries - not sure, works for me, may be as i know linux systems well enough to install it correctly without thinking much of what i do… and i use eclipse photon with GIT plugin to sync with my fork on github. everything was pretty much plug and play to setup.