Are previous binaries of beta releases available somewhere? Specifically I would like to load Rover 4.1.0 beta1.
I see recent daily builds at https://firmware.ardupilot.org/ but not sure how to find the specific release that was was “beta1”.
@rmackay9, I’d like a copy of beta1 as well. I was a bit hasty when I upgraded and didn’t keep a backup copy like I should’ve.
We only have beta3 now on the build server but I can re-create beta one if you’d like. Which boards do you use?
Randy, both Yuri and I are using the Cube Orange.
Some background:
I am having weird problems getting GPS for Yaw to work on beta3, but it is probably just something I am doing. I was using the Pixhawk 1 when I got it working in a test environment last week with beta1, so I had never downloaded beta1. So, basically I changed 2 things: processor and firmware. I would like to go back to beta1 just to eliminate it being related to the beta.
Soon, I am going to get back setup to compile myself (changed laptops a while back), so I should be able to generate my own, assuming I can learn what point to go back to in the repository to find the point where beta1 was generated.
Yuri got his working, by the way, so he may or may not need it. And I expect I just am overlooking some Ucenter change I need to make for my way of doing all RTCM3 external to the FC. I know that the beta is not setting all that up, which is fine. I have had limited time this past weekend to work on the project, but will be hard on it starting tomorrow.
All that said, I hate for you to go to the trouble to recreate beta1. But, if you do have time, I’ll take it! 
EDIT: Randy, as a learning experience, I am going to try to create beta1 myself. I think I know how to revert back to a previous point. I just have to figure out what point to revert back to.
1 Like
Ah yes, to get back to beta1 you need to know the git has for the release which is 9e218c9bde9d8c2c227c897754eb1e6b94a636ae. I know this because I recorded it at the time of the release. Without having actually recorded it the only way to have found it would be to dig out an old log, filter by the “MSG” messages and then look for “ArduRvoer V4.1.0-beta (xxxxxx)”. the “xxxxx” would be the git has.
Here’s a link to a zip with Rover-4.1.0-beta1 for CubeOrange.
1 Like
Ah, re setting GPS-for-yaw to work, I guess you’re directly connecting the GPSs? If you were connecting via the autopilot then one key thing is to pick serial ports which have DMA available.
Figuring out which have DMA is difficult but @tridge tells me the answers are in the dma.txt file which can be downloaded from the autopilot using MAVFTP. I’m not yet sure how to decipher this file though.
1 Like
I am so appreciative of these tips and the beta1 zip!
1 Like
@rmackay9,
I was able to get the dev environment up and running under WSL. The instructions were spot on in the docs at Setup the Build Environment on Windows — Dev documentation (ardupilot.org).
I created a fork of the Ardupilot code on Github and then cloned down to my local machine. The hash you gave didn’t work in my fork (I’m guessing that is no surprise), so I used your method of finding the Ardurover 4.1.0-beta1 in the logs and was able to checkout that hash, do a “./waf clean” and then compile successfully. I did a compare of my .apj file to the one you sent me and found that the image line was different. I am hoping that this is expected also due to something embedded in the code as a date or hash or something that would make my binary unique. The file sizes were exactly the same, which would be very unlikely unless the code was the same.
So, I think I know how to do it now! Thanks again.
I’ll be playing around with some of it live tomorrow.
1 Like
Great, very happy to hear the WSL setup instructions worked. I just ran through those a week or two ago for my own new PC and fixed up some errors.
That githash I gave may only exist on the Copter-4.0 branch so you might have to do something like:
git remote add trunk GitHub - ArduPilot/ardupilot: ArduPlane, ArduCopter, ArduRover, ArduSub source
git fetch trunk
git checkout 9e218c9bde9d8c2c227c897754eb1e6b94a636ae
… but I’m not completely sure. This works on my PC but…
In any case, I think you’ve probably go something very close or perhaps exactly the same as -beta1.
1 Like
Just used MAVFTP to download dam.txt - What a nice tool that MAVFTP is! It gave an error in MP but still downloaded the file. But, like you, I can’t interpret the file without more help. I am connected externally for all RTCM3 traffic, however, so maybe it doesn’t matter too much to me, but still seems useful to know about.
For what it’s worth, my GPS modules are connected to the Cube Orange ports labeled GPS1 and GPS2, which, according to the Cube Orange documentation, are UART4 and UART8.
Attached are my dma.txt and uarts.txt files. I’m not entirely sure how to decipher either of them.
I really want to shoot a video documenting my setup (hardware, connections, mechanical linkages, etc), much like one of Kenny’s recent videos. I’ve set up a tripod 3 times now, each time with a different interruption. I will try and knock that out soon.
Yuri, thanks for pointing out that the ports on the Cube Orange for the GPSes are 4 and 8. I found something that showed them as 3 and 4, just like the original Pixhawk. I guess I just thought the doc I found was for the Cube Orange. I see now that it is 4 and 8. Wow.
Wait: to confuse things more, Mission Planner does not show anything higher than Serial6, so it must still be 3 and 4 as far as MP/Ardupilot is concerned, right?
This document The Cube Module Overview - CubePilot labels them UART3 and UART4.
Yes, it turns out that it’s the uarts.txt file (not dma.txt) that is important. This is what my CubeOrange running Rover-4.1.0-beta3 shows.
I know that the little “*” means the UART’s transmit or receive pin has DMA (direct memory access = high speed) and that the base requires both high speed transmit and receive while the base only requires high speed receive.
I might ask if @tridge can add more detail here.
-Randy
Yes, I think that is the correct numbering in the parameters. But I think perhaps uarts.txt uses the numbering I found in the Cube Orange docs. Unconfirmed.
1 Like
Thanks, Randy. I am very familiar with DMA on other processors and understand why it would help the speed. As you mentioned, it may not matter if all the RTCM3 is taking place outside the Flight Controller, although, if we have the update at 100 mSec instead of the usual 200 mSec, maybe it does. If someone discovers we should use something other than the GPS1 and GPS2 ports, let us know.
Right now, I am having great trouble getting GPS Yaw to work on the cube with beta3. I still haven’t tried going back to beta1 or going back to the old Pixhawk which I was using with my earlier experiments, but I guess I am about to do one of those to see what happens. It is frustrating.
1 Like
The only serial ports I’ve used have been SERIAL3 and SERIAL4 (ArduPilot parameter numbering) when configuring GPS-for-yaw. I just checked an old parameter dump, and I was using the same ports with the older Pixhawk board as well as the newer Cube Orange.
If there is a performance gain to be had by changing ports, I’m very interested. However, it’s so far unclear exactly which ports correspond to the numbering in uarts.txt, and I’m hesitant to change what seems to be working.
1 Like
I’m working on fixing the uarts.txt format:
3 Likes
Thanks for that, Andrew!
From the discussion there, the newly formatted uarts.txt for a Cube Orange is:
UARTV1
SERIAL0 OTG1 TX = 15371 RX = 546 TXBD= 17401 RXBD= 618
SERIAL1 UART2 TX*= 177 RX*= 0 TXBD= 200 RXBD= 0
SERIAL2 UART3 TX*= 177 RX*= 0 TXBD= 200 RXBD= 0
SERIAL3 UART4 TX*= 28 RX = 6074 TXBD= 31 RXBD= 6876
SERIAL4 UART8 TX = 0 RX*= 0 TXBD= 0 RXBD= 0
SERIAL5 UART7 TX*= 991 RX*= 0 TXBD= 1121 RXBD= 0
SERIAL6 OTG2 TX = 0 RX = 0 TXBD= 0 RXBD= 0
And from the Cube Orange documentation:
uarts.txt indicates that SERIAL3 only has DMA for TX, and SERIAL4 for RX.
Those are the ports that both Kenny and I are using for GPS1 and GPS2
He confirmed a measure of success with both 4.1.0-beta1 and beta3 last night using external RTCM3 injects to the moving base’s UART2 port with flight controller comms provided on SERIAL3. My own success has been via MAVLink injection on SERIAL3.
Is there value to putting the moving base on SERIAL2 (TELEM2), or is the DMA TX capability on SERIAL3 sufficient?
Of note - SERIAL5 on the Cube series is not easily exposed for general use. If I read correctly, it is dedicated to ADS-B communication and physically connected internally on the carrier board such that it cannot be repurposed.
If the uarts.txt report is correct, it might be good to move the DMA to other channels instead of using them for Serail5 on the CubeOrange because there is actually very little serial traffic from the ADSB sensors.