Feature Request: Additional CAN Data Streams

general
,
1

It’d be a nice QOL improvement to be able to access to pendant state and dashboard settings with a similar gRPC API to motor states. I understand this is already probably doable using the /raw_messages and /can_message topics together with manual unpacking/CANOpen messaging (like here) but it’d be very nice to have that handled by the Amiga’s libraries behind the scenes like is already being done with twist and motor state.

Dom

2

Hi @DomC,

Thank you for the feedback. I will capture this as feature request(s), and ensure that everything is available through the farm-ng-amiga library to accomplish this.

For the pendant state:

It is unlikely we will unpack and stream the pendant state directly from the canbus service, as that would add overhead to the service for something that is used by very few users (but we will discuss / consider this internally). You are right that it is available through /raw_messages and I will make sure it is straightforward to unpack the messages by adding the class to farm-ng-amiga - packet.py as a mirror of that available in amiga-dev-kit - packet.py. (link to the PR to follow.)

For the dashboard settings:

Can you please clarify what you are looking for regarding “dashboard settings” and what it is you want to accomplish? If you are referring to the list of configurable settings in the dashboard UI (wheel radius, pendant flipped, etc.), these are not yet exposed to the brain. This will take more work behind the scenes, but we can aim to add it for the next release of Amiga OS v2.3. If you mean something else by “dashboard settings” please be very explicit.

Thank you.
– Kyle

3

Hi @kylecoble, thanks for the info!

Pendant:
Let me expand a bit on the use-case I’m looking at. We’re developing a semi-autonomous application to capture images within field rows to train ML models. We’ve written some guidance code to keep the amiga laterally centered within the rows using some secondary sensors, but don’t have a good way yet to allow users to control forward/backward movement. I’d like to use the pendant’s dpad to control constant-velocity movement along rows and one of the secondary buttons as a camera shutter. Of course this functionality is all possible with the brain’s touchscreen, but trying to operate that while the amiga is moving would be challenging.

Having the protos in the main amiga repo will be very helpful in getting that done (Thanks!) but I’m still of the opinion that a separate stream in the same vein as motor_state would be a great value-add. I’m not concerned with update rate or getting every CAN packet from the pendant - 10-30hz would be enough for what I’m looking for - so hopefully there are some ways to work around the overhead implications. Maybe the service could unpack sdo messages at a decreased rate? Or be opt-in?

Dashboard:
I’m looking to read values from the dashboard settings menu exactly as you say. We’re developing guidance software so being able to access - for example - the amiga’s set track width and max set speed could be important. Duplicating these settings in our app isn’t something we want to do b/c of the likelihood of forgetting to update one or the other. We’re not looking to write these values whatsoever, only read.

Thanks!
Dom

4

Thank you for the context @DomC ,

We will discuss this internally and get back to you soon about how we will enable what you need to do (which are definitely things we want to make sure developers can do!) and when you can expect to see the results of these feature requests.

– Kyle

5

Hello @DomC ,

We have added the pendant state stream, and it will be included in the upcoming v2.3 release. An example is (soon to be) available at:

https://amiga.farm-ng.com/docs/examples/pendant_state/

Please be cautioned that:

  1. The function of each button on the pendant may change in future firmware releases. The buttons you choose to trigger actions may become critical for other functions on the brain or dashboard, and you will need to update your app accordingly. Any such changes will be documented in the relevant firmware release notes.
  2. You should not expect to see 0.0 values from the joystick. From the example documentation:

This is the raw output of the pendant, so you should not expect to see x == 0.0 or y == 0.0 when the joystick is “centered”, as there is inherent noise in the reading of a joystick axis.

The dashboard filters these values out for vehicle control based on the pendant calibration, but that is not represented in the PendantState.

We intend to also include the settings in the upcoming release, but have not yet started that implementation.

Best,
Kyle

6

Awesome, great to hear! I’ll be sure to try it out as soon as we upgrade!

Thanks,
Dom