Jellyfish 2.0 Development Blog

Flight test 12 June 2024

Attempted to takeoff the drone a few times, But the X8R receiver does not seem to be sending the correct signal for PWM to the ESCs. The drone motors only started spinning after the throttle was raised more than 50% of its set range.

Currently the PWM set is from 1100 to 1940.

On one flight Motor 4 stopped spinning mid air, and randomly started running again as it was about to land.

The main symptom seems to come from the comms between the transmitter and the receiver

Potential causes:

1. The flight controller RC IN pin could be faulty, a test with the Durandal will be done to ensure the transmitter and receiver are working fine

2. PID is not tuned properly, the following guide will help https://docs.px4.io/main/en/config/autotune.html#troubleshooting

3. The IMU is not calibrated properly and PX4 controls is reacting badly to the sensors

4. some parameters need to be adjusted to fit the ESC used (Tmotor Alpha 60A, 6S) https://discuss.ardupilot.org/t/throttle-percentage-is-not-matching-with-pwm-out/102515/18 https://discuss.cubepilot.org/t/several-motors-wont-spin/4700/3 https://discuss.px4.io/t/unstable-motors-output-cube-orange-hexarotor-x/27173/5

There is also a whatsapp chat group for general inquiry’s with T motor, will ask them about the motor issue there

Servo power outputs need to be checked The pins used for the ESC PWM need to be assigned as for motors

PX4 flight review logs.

On a good note, the drone is not as haywire in flight as the first crash. Vibration issues also seem to be resolved.

Flight test 13 June 2024

First flight:

• The drone successfully took off, and it could stay in position/altitude when the flight mode was switched for station keeping.

• The Yaw however was completely off as the drone kept rotating when station keeping in altitude flight mode.

• Landing was alright.

Second flight:

• The drone took off in Manual mode and drifted to one side. Wind caused the drone to drift and it eventually hit the tree.

This was due to negligence on my part, the drone was set at a place too near the tree, and the flight mode used to take off was supposed to be altitude flight mode, not Manual flight mode.

Damage:

• 3 drone arms either broke or have a hairline crack.
• The drone shell was completely destroyed
• One battery hull cracked.
• 2 propellers broke during the crash.

All electrical internals, landing gear and frame survived, which is good.

Tran has sent a replacement for the broken shell and battery hull. Spare carbon fiber tubes are in the lab, more have been purchased for replacement.

Things to take note for future flight tests:

1. The drone is to be as far away from any obstacles before take-off
2. Drone is to only take-off in either altitude or positional flight mode
3. Transmitter switches are to be labelled with their functions for the pilot to better switch flight modes when needed

Flight review:

Although the drone did show stable flight initially. The drone still has some worrying symptoms to look into.

2 out of 4 motors did not output as much as the other 2 motors Advice from Brian was vibrational issues again. He recommended to balance the propellers before mounting them He also recommended the flight controller to be mounted directly onto the frame, as the current set up may be making the vibrations experienced by the flight controller worse. Tran to double confirm if this is true.

From PX4 flight review the IMU still experiences quite a lot of noise, tho at least not till it has to compensate by drawing more power to the motors to sustain flight.

Gyro readings also are haywire. Might be a calibration issue, or the onboard gyro is just experiencing too much noise.

Though it does stabilize in positional flight mode

TO DO:

1. SOP for future flight tests.

• This includes pre flight checks, and instructions on how to more safely let the drone take off. Details on the different flight modes will also be included.
• The purpose of this SOP is to inform any future drone pilot on what to look out for before flying the drone. This also serves to avoid anymore negligence during flight tests.

2. Force gauge tests of motors.

• For PID tuning and to check if the motors and ESCs function as intended. The ESC’s will be reflashed with updated firmware as well.

3. While waiting for the new MJF orders for the shell and batt hull, practice on transmitter controls will be done with the IDP drone.

• this also serves to understand PX4’s drone functionalities more

4. Re-solder all requires electronics for spares

• Matek FC hub
• Battery hull XT90 panel mounts
• Panel PCB for battery mating

5. Panel PCB is to be re-fabbed with the ADS1115 for battery monitoring

6. Add telemetry logging of motor data to the pixhawk

The drone has stable flight (yay)

The following flight tests were to do 2 things

1. PID tuning
2. Transmitter controls practice

PID tuning was fairly simple, just need to follow the instructions from the Px4 documentation.

PID tuning - Bumblebee Autonomous Systems

Overall flight:

• The results after tuning was acceptable, however additional tuning would be beneficial for less noise and more stable flight overall.

Motor outputs seem normal, and there is much less noise experienced as compared to all previous flight tests.

Further fine tuning should reduce the vibrations even more.

https://docs.px4.io/main/en/config_mc/pid_tuning_guide_multicopter_basic.html https://docs.px4.io/main/en/config_mc/filter_tuning.html

An attempt was also made to offset the IMU mounting position on the Jellyfish.

This however caused the drone to behave erratically against wind. Thus any offset parameters are not to be changed. The mounting of the flight controller will be shifted more center for better response from PX4’s internal IMU.

Issues discovered:

• Signal strength for both the Telemetry radio and the Receiver was quite bad. Only when standing at a distance of around 5 metres away did the radios communicate properly with one another.

This could be due to interference as we were flying near RSYC, where there are a few radio towers nearby.

A patch antenna will be used to try and improve radio communication.

The receiver having poor signal strength could be accounted to the wrong antennas being used during flight. After changing to the correctly tuned antenna, signal strength between transmitter and receiver in the lab seems stable. This will be tested again in future flight tests.

Since stable flight has been achieved, the drone team can now move on to flight tests with the Orin mounted.

Integration will be done and the first flight test with the SBC will be done on 24th July.

Flight test 24th July 2024

This flight test was to conduct 2 things

1. SBC waypointing
2. PID tuning with the drone fully laden (everything mounted)

With the SBC and ASV radio mounted. PID needed top be tuned again. After basic tuning the drone could fly with little oscillations. Same state as the previous flight tests.

Initially we had issues with GPS lock for its local position, this was due to wires routed over the GPS. This seems to cause the GPS to malfunction. Future mounting of the GPS should not have any wires above it.

SBC testing (offboard mode)

Before testing, the transmitter was tested to be able to take over control of the drone at any point in time of the mission. The flight mode simply changed from offboard mode (SBC control) to positional flightmode (station keeping). This worked properly, thus we then mounted the propellors for the SBC waypointing test.

SBC testing consisted of one waypoint 10 metres above the start point (0,0,0 to 0,0,10) of the local positioning of the drone.

The Drone was turned on near us and was then shifted further away for testing as per the written SOP.

The drone took off and proceeded to the set waypoint which we did not expect to be the location the flight controller was switched on.

Matt tried to revert the drone back to positional flight mode to station keep the drone IMU suddenly experienced some noise and started to oscillate violently before crashing.

This was due to not checking the flight logs to ensure the Gyro readings and IMU readings are stable.

One flight only in positional flight mode, clearly there was noise to be filtered out

Next flight to tune both PID and IMU filter before testing anything with the SBC.

Before any future flights, the flight log is to be reviewed first

To do next flight test:

1. Test all gyro filtering and PID tuning with the IDP drone. The SBC is to be mounted on.

2. Test offset of GPS, compass, IMU on EKF to see how it reacts.

3. Test offboard mode mission once IMU, Gyro and PID are stable (Check flight log after each flight) (Points 1, 2 and 3 are to be tested with the IDP drone for practice)

4. Update SOP for SBC flight testing

5. Fix Jellyfish 2.0

Flight Test 27 Jul 2024

Stuff Done

• Gyro and PID tuning with iDP drone
• Geofence testing
• Check PX4 geomsg convention (NED), odom ref frame, earth fix What happened Tuning:
• Gyro noise not too bad even with SBC on Geofence:

Failsafe set to land mode

• Exceed x, y geofence -> land immediately
• Exceed altitude -> hold mode and try to land. But once within geofence bounds will change back to position mode.
• Problem: Will keep oscillating between land and hold as long as thrust is above 50%.

Failsafe set to hold mode

• When exceeding geofence, will stay on hold until flight mode is changed. No response from joystick but will respond to flight mode change.
• Problem: Cannot land while still in hold flight mode. TODO: Test transmitter switch from failsafe hold mode to land flight mode.
• Matt to label drone transmitter and repair drone before wednesday 31 Jul

Heading:

• North is zero. heading increases clockwise. -pi to pi

Networking issues:

• Even while connecting over internet, poor connection between laptop and drone when far
• TODO: Test long distances outdoor.

Waveshare and Seeed Studio barrel jacks are differently sized

Test hardware fixes in lab.

Flight test 31 July 2024

What we tested with the IDP drone:

• Geofence limit: When the drone flys out of the geofence hold mode is activated. Exceeding geofence removes input from joysticks till flight mode is changed.

• QGC waypointing with transmitter takeover: Changed from mission to position flight mode. Drone will simple change modes accordingly. Thrust joystick will need to be pushed beyond 50% thrust to maintain altitude.

• SBC waypointing based on Local NED frame: In this test only the position (x,y,z) was set relative to local NED positioning. No input to velocity and only one waypoint was set. If a X and Y coordinate was set, the drone will take off diagonally. At one flight it rotated on the spot to fix heading before flying.

• Switching between offboard and non-offboard flight modes: In offboard mode the drone was set to move to (0,0,5). The flight mode was then switched to positional flight mode and moved to another coordinate with the transmitter. Offboard mode was then switched back, the drone simply moved back to the coordinate published by the SBC. As no velocity was input, the drone executed its own controls, which was a little rough.

Flight review:

Issues from today:

1. Network is horrible through tailscale. SBC currently gets internet over wifi from USB dongle. The network was too slow so Matt phone was strapped on, which made it faster. Tailscale seems to have a radius limit. to test next flight test.

2. Barometer keeps offsetting itself after each flight. The drone is always way off at the z axix. Accuraccy of waypoints depends on how much the barometer drifts. Calibration of level horizon and gyroscope, along with a reboot of the flight conroller seems to zero the drone properly.

To test next flight tests:

When testing waypoints, place aruco board at (0,0,0) to test how much the GPS drifts.

1. Changing home position on QGC to see if it changes the Local NED coordinates
2. Move drone away while connected via tailscale. (To see if tailscale is radius limited)
3. Add lidar for more accurate altitude readings
4. set yaw offset ( set south while drone pointed north)
5. Setting yaw and velocity in setpoint message

We only move on if test no. 5 works fine.

6. Test point 4 in mission planner (drone correct yaw on its own)
7. Waypointing with mission planner
8. Lat long with mission planner

Things to add to SOP:

1. When switching out of offboard mode. Change to hold first, then immediately shift thrust joysitck above 50% to maintain altitude. Drone will immediately change from hold to position when joystick is touched. Ensure the flight mode switch is set to positional.

Once we finish test No.7, we repeat everything for Jellyfish 2.0 and test radio.

To plan for radio testing this Friday.

Flight test 2 Aug 2024

What we tested today:

Software:

• Setpoints with velocity, accel, yaw and yaw speed 0s are default, if we set a param to 0, we let the drone do its own calc for its speed vel: 0, 0, 1 accel: 0, 0, 1 Only care about accel if you need to reach velocity within a certain time

• if trajectory setpoint: position: (0.5,0.5, (any height)) yaw: half pi yaw speed: 1.0 The drone will spin to the correct pose, but the parameters set is too small to see the entire movement

• Mission planner: Is able to conduct basic flight. It will start from positional flight mode to offboard, arm, conduct mission, then land. Z axis will drift a lot. Drift is random. A threshold check if its at the correct pose is set, but due to the drift it fails even if it hovers for some time.

Trying to figure out a fix.

The drift might be changing as it flies.

Might have not accounted for the offset at the point of publishing the point with respect to the start.

How it works:

• We publish a pose w.r.t to the baselink of the drone body e.g. 0,0,5 wrt baselink_enu

This pose would go through some transforms to be calculate wrt to the frame of the odom_ned (the frame where we publish our traj setpoint in)

While the drone moves to the setpoint, we have a threshold check to ensure that the drone stops when it hits a certain x,y,z threshold from the target pose.

Apparently the velocity set is a threshold and not the set velocity for the drone

To do:

• Check ros bags to check the body frame and Local NED x,y,z. And compare if the offset implemented by the ENU maintains

• If the offsets during flight, its a sensor problem.

Hardware:

• Telemetry with multiple drones.

• One radio pair works fine. However when more radios are added it becomes very hard to maintain telemetry.

• PX4 allows us to set an ID to each drone, and a COMM link for each radio.

• For today one laptop had one ground station radio. Thus 2 systems were trying to see telemetry data from 2 drones each.

• This might prove to be an issue at RobotX where other teams are also using the same SIK radios for their drones.

• Could be a case where only one laptop (one ground station) is to be connected to all the radios through a USB hub.

To try in lab and at the next flight test.

Jellyfish 2.0 tuning:

• Calibration and tuning was smooth. To check flight review again if more tuning to the sensors and PID is required.

Flight test 5 August

What we tested today:

Software:

1. Aruco tag detection: works ok but sometimes encounter reflections from the board Can stream both cameras with large and small fov (same model but with diff lens) Compression needs to be quite high
2. Mission planner: Same test as last week, go up and go down with velocity send traj setpoints with velocity, when hit threshold, send one last setpoint without velocity param
3. Geofence with offboard working, goes to hold mode
4. Tried building the docker for jellyfish but it took too much time
5. lat lon unable to echo topic Issues:
6. Z still drifting -> look at the flight log and see what we can do
7. Camera glare issue, compression issue
8. Lat lon topic cannot echo
9. Flash new image on jellyfish2 sbc, seed studio bsp so need to look into how to change the kernel config Fixes: 1.Stick to one sbc so that there’s less time wasted pulling and building

Next flight test:

1. check whether x,y is drifting
2. test lat lon waypointing
3. test detections