lcas / callarobot Goto Github PK

as in new TMuLE version to get rid of proxy requirement and be more flexible.

There seems to be a quite long delay between the GPS and velodyne observations at the moment and there is currently no way of recovering the right timestamp from the GPS observation (the one reported in the NMEA string). This feature would be needed to synchronise the sensors. @marc-hanheide any ideas how to add that to the published messages? Should that replace timestamp (clients local time) or perhaps better to have both of them (e.g. gps_timestamp).

A condition arises whereby the User and actor are different. A call can be made (by a STD device) which works correctly but the log shows a different user made the call and not the device itself. See screenshot. It is correct when only one STD is registered and active but shows up when two STDs are present as can be seen in the top two lines. This does not seem to be affecting anything, the correct device is called - seems to be a web interface issue?

One server should serve different farm/sites. Proposal is a URL prefix.

It appears that the accept button on the web interface at https://lcas.lincoln.ac.uk/car/orders only appears for "new" devices not already known by the system. Screenshot shows new device ending in 710 has an accept button but other STD devices (even if you login in to https://lcas.lincoln.ac.uk/car as that user and make a call) do not

Call-a-robot.py line 103

    if state == 'INIT' or state == 'INIT':

Description of the bug

The variables in the GPS messages are named inconsistently (cf. the various declarations in callarobot/py), specifically this is an issue in the data sent here, as the longitude entry is called "long", which causes issues with my linter because of the identical datatype name.
I think it would be good practice to have all the variables named the same in this file, e.g. "latitude" and "longitude".

Steps To Reproduce

Run pylint on callarobot.py

Additional Information

No response