Does anyone know what would cause a cube to not detect 2 of the 3 internal imus? It seems like all the imus on a specific spi bus are not being detected.
This picture displays what should be detected by the cubes.
I have scrubbed through the parameters trying to find the cause, but I am unable to locate the issue. INS_Enable_mask is set to 127 which was my first thought. My mind goes to a possible manufacturing defect, as these 4 orange cubes were purchased at the same time. All other cubes we have do not have this issue and detect all imus. I guess my question boils down to is there any parameters that could cause spi bus 4 to be inoperable? Or is this more likely a set of defective cubes.
It is also worth noting that other vehicles are running an identical configuration with parameters and hardware but do not have this issue. It is only present in the most recent batch of orange cubes we acquired back in about May of 2021. Any help you can offer would be greatly appreciated. I can attach a param file if it would be helpful or run any suggested tests that might narrow down the cause.
That was one of the first things I tried. I should have mentioned that in the post. Unfortunately that yielded no results. The same IMUs are missing regardless of what type of firmware I run or how many times I reset the parameters. The more I dig, the more I think it must be a batch of defective units. I have just never seen this happen to a cube before and I have worked with a lot of cubes over the years. It is also concerning that all of the cubes that we ordered at the same time have this same issue. All other cubes we have, that were ordered in the same time frame, (within the last year, just as separate orders) are functional. It makes me wonder if there is a batch of cubes out there somewhere that were manufactured with some defects relating to the IMUs.
I believe this batch of orange cubes was purchased from the IRLOCK amazon storefront. I will contact IRLOCK for an RMA request.
I appreciate your input and thanks for your response Alvin!
It interesting you say you are having this issue with your Oranges purchased from IRLock in May 2021. My first Orange I bought had this same issue and was purchased from the same vendor in May, link. It turned out the connector was loose. (Sid helped me diagnose it. But opening it up is no easy feat and they don’t go nicely back together.)
Thank you. This was incredibly helpful and turned out to be the issue. I opened the cube, and the connector for the IMU board was completely disconnected.
I was debating on opening up a cube for the past few days, but didn’t want to complicate any RMA requests. After reading your response, I opened one and sure enough, no connection to the IMU board. I seated the connector, reassembled the cube, and now all sensors are present. My cube reassembled very cleanly. I was just super careful about popping the tabs out on the bottom. I was able to extract the FMU and IMU boards with no damage to the case. It went back together with no visible damage or issues.
It appears that a batch of cubes may have missed having that connector properly seated. Thanks for your response and I appreciate the help.
Also I will likely proceed with the same procedure on the rest of the boards. Next time I will take some pictures.
I am wondering, Is it possible that the act of screwing a bare cube into a carrier board could cause this separation? I am just wondering if maybe the foam packing around the IMU board has enough play to allow the IMU board to separate from the Main FMU board when I mount it on a carrier board if there is some misalignment in the screws.
The only reason I bring this up is because I am realizing that 1 of the 5 boards we purchased is actually operable and not missing the IMUS. I will likely still open it to check on connector seating, but I am wondering if installation could cause this?
Once again thanks to everyone for your help and attention. It is greatly appreciated.
@James_Megariotis You should wait on opening the other Cubes until you receive guidance from the CubePilot staff such as @Alvin.
Just to be clear I wasn’t trying to steer you do that before they said so ;).
“I am wondering, Is it possible that the act of screwing a bare cube into a carrier board could cause this separation?”
I had a similar thought too. Though looking at the design that didn’t seem as likely. But the failure did occur after I reseated it. My connector was just slightly torque upwards when I opened it.
Correct. When you open the bottom, there are chances that the FMU stick too tight with the plastic. This makes the connector actually disconnect due to opening the Cube. In this case, we could not determine whether it was disconnected before opening the Cube.
Therefore, we usually recommended to send it back so that it’s us to open the Cube. If you are clearly understanding what you are doing, you are free to open it.
All cubes have been opened and reassembled without issue. All the orange cubes we ordered from IRlock in May 2021 had the IMU board disconnected from the FMU board on all but 1 orange cube. I will send a picture of all cubes that had the disconnect issue. It seems that the serial numbers on the bottom were all very close to each other, so I assume there may be a batch of them that have this issue in that range of serial numbers.
In regards to the opening of the cube, we have worked extensively with cubes over the years and have had to open them from time to time, so we are well versed in opening them and resealing without damage. But I can understand your concern that an inexperienced user could damage the hardware.
The IMU board was definitely disconnected on all cubes and not inadvertently disconnected on opening the cubes.
In regards to separation of the cable on installation into a carrier board, I figured that was very unlikely also. We install our cubes in custom carrier boards and have never had an issue like this working with many cubes over the years. It seems likely that maybe during a QC check, the IMU board was tested but never plugged back into the FMU board. I am not familiar with the manufacturing and QC of the cubes, but they have always been reliable and fully functional when we receive them, so this was a first for us.
Edit: Also my biggest concern that is on a 4.0.x ArduCopter build, it allows you to fly with no real indication of any issue that could be critical. I noticed on a stock 4.1.x firmware, it gives you a critical warning, but not on older versions. I wound up stumbling onto this problem almost entirely by accident because I could not get more than 1 ekf lane to run on the affected cubes, which is not normal. But these vehicles were flown on a few occasions with no real indicator of such a critical problem. We also experienced a crash due to roll over in flight on one of those vehicles. We assumed some sort of ESC desync issue, but now I wonder if this was related to our crash. We run a slightly modified custom firmware, and this also appears to be another reason (among some desirable upgrades to the position control library) to quickly upgrade into the 4.1 firmware versions.
