As the title says…
-
Do you notice any differences?
-
Any other changes required before running the RVC version?
1 Like
I am using it. Difference is there, but mostly because IMU is mounted far closer to ground, as wires can be longer for uart. If you leave IMU on pcb there is little change if any.
There are some traces that must be cut and some soldered for AiO.
As Radmuffins said, the main advantage is being able to relocate the IMU to a more favorable location. The AIO firmware still has to implement a wait state to allow the GPS running at 10Hz to sync with a data packet from the IMU running at 100Hz. Remote IMU is being considered for the AIO v5.0 board. There is an open pin in 35 pin connector that can be used for RS-232 RX data and the MAX 3232 on the AIO board has an open channel. Also, some work on a small board for the BNO085 with a MAX3232 RS-232 chip and voltage regulator for use as the remote IMU.
I tried putting the IMU on the CAN bus using a TTL-CAN adapter. It did work. However, due to the CAN prioritization scheme, a chatty device like the Keya motor can make it hard for other devices on the bus to get “air time”. Since the Keya is performing a critical realtime function, one probably does not want it to be delayed. The AIO v5.0 board does have 3 CAN buses so the Keya could have its own bus.
Lastly, there was also talk about an RS-232 daughter card for the BNO slot in the pre-v5.0 boards.
The 100Hz alpha firmware is on Matts repo. There is a header file for the v4.x boards. GitHub - m-elias/AOG-AiO-RVC-100hz: 100hz RVC firmware for AOG-AiO v4.x & v5.0a
I’m curious what advantages you’re seeing by lower down… Less side to side acceleration?
Running RVC and find it more stable, the BNO data is always there at the right time. No hangups requesting data, then waiting for a response. Good system.
1 Like
Real Voice Cloning?
Robot vacuum cleaner. It’s one of the BNO’s operational modes.
1 Like
Yes, BNO overreact on bumps so lower it is less effect side acceleration has on it. It is located in center of tractor basically at pivot point ~65cm away from ground. Placing it there without RVC mode would be far more challenging.
1 Like
Plus with RVC code there is a 100hz control loop instead of 40hz. The non RVC firmware can achieve 100hz with a little doing though. 100hz vs 40hz probably isn’t really noticeable but it should be ever so slightly snappier.
So there is probably little to no advantage to using the RVC version if there’s no cab suspension or any other need for IMU relocation?
Correct this if wrong:
-
RVC allows for different wiring which makes remote mounting possible. This is only necessary with cab suspension?
-
RVC runs the BNO at 100hz instead of 40hz currently
-
RVC requires board modifications…?
Add #4 No I2C connection issues. Some people’s BNO will randomly not initialize at boot up.
#1 Not necessarily a cab suspension issue. An open station tractor with the board / IMU mounted on top of the roll bar, fender or hood can have issues. The further the IMU is mounted above the axle or roll axis, the greater the linear acceleration during movement. This linear acceleration can cause errors in the IMU reading.
#2 Yes on RVC mode sampling at 100Hz. Not necessarily on the 40Hz. The i2c polling rate depends on the firmware and microcontroller.
#3 Maybe or maybe not depends on the board.
I should also clarify that the BNO data is only sent to AOG whenever data from the F9P comes in, in our case 10hz. In RVC mode the BNO spits data out at 100hz but only every tenths message is used. In the old firmware it was just polled at 10hz. It is the control loop between the steering motor/valve and the WAS that runs at 40hz or 100hz. The main limitations on this was I2C polling which is eliminated in RVC firmwares.
So the RVC firmware boosts the control loop from 40hz to 100hz with essentially the same data being used at 10hz?
If I’m thinking of the process right, RVC simply allows AOG to have the BNO data available instantly without the need for polling or any I2C issues…
Are we concerned about garbage data or no filtering of the 100hz BNO data?
The BNO is spec’d to run at 100Hz. The protocol includes a CRC check to ensure the data has arrived uncorrupted.
There is concern about inaccurate data hence the use of RVC to move the IMU as close to the roll axis as possible.
1 Like
Yes Exactly
The BNO is constantly streaming its data on a dedicated UART to the teensy. The RVC packets contain less junk data that we do not use too.
RVC streams fast enough that the teensy just pulls the last reading, when it needs the the data to be timed with PANDA. 0 chance of missing a request, or sending data late. Its sitting their waiting to be used.
Ive done lots of hours with i2C and it works allright, RVC is just a tad more stable.
2 Likes
